Encountering "Constant strings cannot be deallocated" in Linux foundation

mbrandonw · November 29, 2017, 9:34pm

Hello all!

We’ve been encountering this runtime error quite a bit recently, and we
have no idea why. We’ve filed a bug and there’s one other on JIRA related
to this, but both without any comments:

github.com/apple/swift-corelibs-foundation

[SR-6422] Encountering "Constant strings cannot be deallocated" in Linux foundation

opened 05:28PM - 17 Nov 17 UTC

closed 10:30PM - 01 Dec 17 UTC

mbrandonw

bug Foundation RunTimeCrash

| | | |------------------|-----------------|… |Previous ID | SR-6422 | |Radar | None | |Original Reporter | @mbrandonw | |Type | Bug | |Status | Resolved | |Resolution | Duplicate | <details> <summary>Additional Detail from JIRA</summary> | | | |------------------|-----------------| |Votes | 0 | |Component/s | Foundation | |Labels | Bug, RunTimeCrash | |Assignee | None | |Priority | Medium | md5: 591e29ee8530d7b357e7037d4dee4824 </details> **duplicates**: * [SR-6398](https://bugs.swift.org/browse/SR-6398) Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118 **Issue Description:** Hello! I have a test case that when run on Linux somehow encounters the "Constant strings cannot be deallocated” fatal error thrown in NSCFString.swift, as seen here: <https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCFString.swift#L118> The test that does it is here: <https://github.com/pointfreeco/swift-web/blob/5f19a0264be5d369ee0438da8599e3c478a6573b/Tests/ApplicativeRouterTests/SyntaxRouterTests.swift#L88-L93> Now there’s a lot to unravel here and I haven’t been able to find a minimal test case yet, but I thought I would at least file this for now and can update if I find the minimal test case. I have also raised this issue not he corelibs-dev mailing list: <https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20171113/001351.html> Thanks!

https://bugs.swift.org/browse/SR-6398

We’re curious if others are aware of this and or has more info? Is it a red
herring for some other problem?

Any info would be helpful!

Tony_Parker · November 29, 2017, 9:43pm

Hi Brandon,

This is probably a bug in the CoreFoundation C sources part of swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. Probably there is a constant string returned from CF function, then the Swift runtime assumes it can release it, and bam we wind up with an overrelease.

We’ll have to track down which function is getting called, which probably just requires stepping through that test case with a debugger…

- Tony

···

On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hello all!

We’ve been encountering this runtime error quite a bit recently, and we have no idea why. We’ve filed a bug and there’s one other on JIRA related to this, but both without any comments:

[SR-6422] Encountering "Constant strings cannot be deallocated" in Linux foundation · Issue #3785 · apple/swift-corelibs-foundation · GitHub
[SR-6398] Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118 · Issue #4053 · apple/swift-corelibs-foundation · GitHub

We’re curious if others are aware of this and or has more info? Is it a red herring for some other problem?

Any info would be helpful!
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

mbrandonw · November 29, 2017, 10:06pm

Thanks for the info!

FWIW, most of the places I have encountered this so far have made use of
`URLComponents`, and have even been able to eliminate the crash by getting
rid of that code in a few places. The other JIRA bug on this topic also
mentions URLComponents in their repro case. Seems to be the culprit.

Also worth noting that in the above cases dealing with URLComponents the
crash only happens in DEBUG compilations, not RELEASE.

However, I do have another one of these crashes that _does_ happen on
RELEASE builds that I haven’t yet been able to reduce.

···

On Wed, Nov 29, 2017 at 4:43 PM Tony Parker <anthony.parker@apple.com> wrote:

Hi Brandon,

This is probably a bug in the CoreFoundation C sources part of
swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the
CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. Probably
there is a constant string returned from CF function, then the Swift
runtime assumes it can release it, and bam we wind up with an overrelease.

We’ll have to track down which function is getting called, which probably
just requires stepping through that test case with a debugger…

- Tony

On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote:

Hello all!

We’ve been encountering this runtime error quite a bit recently, and we
have no idea why. We’ve filed a bug and there’s one other on JIRA related
to this, but both without any comments:

[SR-6422] Encountering "Constant strings cannot be deallocated" in Linux foundation · Issue #3785 · apple/swift-corelibs-foundation · GitHub
[SR-6398] Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118 · Issue #4053 · apple/swift-corelibs-foundation · GitHub

We’re curious if others are aware of this and or has more info? Is it a
red herring for some other problem?

Any info would be helpful!

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Tony_Parker · November 29, 2017, 10:59pm

I see a couple of places that are suspicious there:

Description:

github.com

apple/swift-corelibs-foundation/blob/main/CoreFoundation/URL.subproj/CFURLComponents.c#L66


      
          
          static Boolean __CFURLComponentsEqual(CFTypeRef left, CFTypeRef right);
          static CFHashCode __CFURLComponentsHash(CFTypeRef cf);
          
          static CFStringRef __CFURLComponentsCopyDescription(CFTypeRef cf) {
              CFURLComponentsRef components = (CFURLComponentsRef)cf;
              CFStringRef scheme = _CFURLComponentsCopyScheme(components);
              CFStringRef percentEncodedUser = _CFURLComponentsCopyPercentEncodedUser(components);
              CFStringRef percentEncodedPassword = _CFURLComponentsCopyPercentEncodedPassword(components);
              CFStringRef percentEncodedHost = _CFURLComponentsCopyPercentEncodedHost(components);
              CFNumberRef port = _CFURLComponentsCopyPort(components);
              CFStringRef percentEncodedPath = _CFURLComponentsCopyPercentEncodedPath(components);
              CFStringRef percentEncodedQuery = _CFURLComponentsCopyPercentEncodedQuery(components);
              CFStringRef percentEncodedFragment = _CFURLComponentsCopyPercentEncodedFragment(components);
              CFStringRef result = CFStringCreateWithFormat(kCFAllocatorSystemDefault, NULL, CFSTR("<URLComponents %p> {scheme = %@, user = %@, password = %@, host = %@, port = %@, path = %@, query = %@, fragment = %@}"), cf, scheme, percentEncodedUser, percentEncodedPassword, percentEncodedHost, port, percentEncodedPath, percentEncodedQuery, percentEncodedFragment);
              if ( scheme ) CFRelease(scheme);
              if ( percentEncodedUser ) CFRelease(percentEncodedUser);
              if ( percentEncodedPassword ) CFRelease(percentEncodedPassword);
              if ( percentEncodedHost ) CFRelease(percentEncodedHost);
              if ( port ) CFRelease(port);
              if ( percentEncodedPath ) CFRelease(percentEncodedPath);

And the nameString / valueString constants in the copy query items function:

github.com

apple/swift-corelibs-foundation/blob/main/CoreFoundation/URL.subproj/CFURLComponents.c#L1057


      
          
          CF_EXPORT CFRange _CFURLComponentsGetRangeOfScheme(CFURLComponentsRef components) {
              struct _URIParseInfo stringParseInfo;
              struct _URIParseInfo *theParseInfo;
              if ( _CFURLComponentsParseInfoIsValid(components) ) {
                  // use the range info in _URIParseInfo is valid
                  theParseInfo = &components->_parseInfo;
              }
              else {
                  // we need to get the current string, parse it, and use its range info
                  theParseInfo = &stringParseInfo;
                  CFStringRef str = _CFURLComponentsCopyString(components);
                  _CFURIParserParseURIReference(str, theParseInfo);
                  CFRelease(str);
              }
              return ( _CFURIParserGetSchemeRange(theParseInfo, false) );
          }
          
          CF_EXPORT CFRange _CFURLComponentsGetRangeOfUser(CFURLComponentsRef components) {
              struct _URIParseInfo stringParseInfo;
              struct _URIParseInfo *theParseInfo;

github.com

apple/swift-corelibs-foundation/blob/main/CoreFoundation/URL.subproj/CFURLComponents.c#L1079


      
                  // use the range info in _URIParseInfo is valid
                  theParseInfo = &components->_parseInfo;
              }
              else {
                  // we need to get the current string, parse it, and use its range info
                  theParseInfo = &stringParseInfo;
                  CFStringRef str = _CFURLComponentsCopyString(components);
                  _CFURIParserParseURIReference(str, theParseInfo);
                  CFRelease(str);
              }
              return ( _CFURIParserGetUserinfoNameRange(theParseInfo, false) );
          }
          
          CF_EXPORT CFRange _CFURLComponentsGetRangeOfPassword(CFURLComponentsRef components) {
              struct _URIParseInfo stringParseInfo;
              struct _URIParseInfo *theParseInfo;
              if ( _CFURLComponentsParseInfoIsValid(components) ) {
                  // use the range info in _URIParseInfo is valid
                  theParseInfo = &components->_parseInfo;
              }
              else {

github.com

apple/swift-corelibs-foundation/blob/main/CoreFoundation/URL.subproj/CFURLComponents.c#L1104


      
                  CFRelease(str);
              }
              return ( _CFURIParserGetUserinfoPasswordRange(theParseInfo, false) );
          }
          
          CF_EXPORT CFRange _CFURLComponentsGetRangeOfHost(CFURLComponentsRef components) {
              struct _URIParseInfo stringParseInfo;
              struct _URIParseInfo *theParseInfo;
              if ( _CFURLComponentsParseInfoIsValid(components) ) {
                  // use the range info in _URIParseInfo is valid
                  theParseInfo = &components->_parseInfo;
              }
              else {
                  // we need to get the current string, parse it, and use its range info
                  theParseInfo = &stringParseInfo;
                  CFStringRef str = _CFURLComponentsCopyString(components);
                  _CFURIParserParseURIReference(str, theParseInfo);
                  CFRelease(str);
              }
              return ( _CFURIParserGetHostRange(theParseInfo, false) );
          }

github.com

apple/swift-corelibs-foundation/blob/main/CoreFoundation/URL.subproj/CFURLComponents.c#L1134


      
                  // we need to get the current string, parse it, and use its range info
                  theParseInfo = &stringParseInfo;
                  CFStringRef str = _CFURLComponentsCopyString(components);
                  _CFURIParserParseURIReference(str, theParseInfo);
                  CFRelease(str);
              }
              return ( _CFURIParserGetPortRange(theParseInfo, false) );
          }
          
          CF_EXPORT CFRange _CFURLComponentsGetRangeOfPath(CFURLComponentsRef components) {
              struct _URIParseInfo stringParseInfo;
              struct _URIParseInfo *theParseInfo;
              if ( _CFURLComponentsParseInfoIsValid(components) ) {
                  // use the range info in _URIParseInfo is valid
                  theParseInfo = &components->_parseInfo;
              }
              else {
                  // we need to get the current string, parse it, and use its range info
                  theParseInfo = &stringParseInfo;
                  CFStringRef str = _CFURLComponentsCopyString(components);
                  _CFURIParserParseURIReference(str, theParseInfo);

github.com

apple/swift-corelibs-foundation/blob/main/CoreFoundation/URL.subproj/CFURLComponents.c#L1158


      
          }
          
          CF_EXPORT CFRange _CFURLComponentsGetRangeOfQuery(CFURLComponentsRef components) {
              struct _URIParseInfo stringParseInfo;
              struct _URIParseInfo *theParseInfo;
              if ( _CFURLComponentsParseInfoIsValid(components) ) {
                  // use the range info in _URIParseInfo is valid
                  theParseInfo = &components->_parseInfo;
              }
              else {
                  // we need to get the current string, parse it, and use its range info
                  theParseInfo = &stringParseInfo;
                  CFStringRef str = _CFURLComponentsCopyString(components);
                  _CFURIParserParseURIReference(str, theParseInfo);
                  CFRelease(str);
              }
              return ( _CFURIParserGetQueryRange(theParseInfo, false) );
          }
          
          CF_EXPORT CFRange _CFURLComponentsGetRangeOfFragment(CFURLComponentsRef components) {
              struct _URIParseInfo stringParseInfo;

Do you have the ability to re-build swift-corelibs-foundation and run a test? I suspect if you replace those with CFRetain(CFSTR(…)) then it will fix your crash.

- Tony

···

On Nov 29, 2017, at 2:06 PM, Brandon Williams <mbw234@gmail.com> wrote:

Thanks for the info!

FWIW, most of the places I have encountered this so far have made use of `URLComponents`, and have even been able to eliminate the crash by getting rid of that code in a few places. The other JIRA bug on this topic also mentions URLComponents in their repro case. Seems to be the culprit.

Also worth noting that in the above cases dealing with URLComponents the crash only happens in DEBUG compilations, not RELEASE.

However, I do have another one of these crashes that _does_ happen on RELEASE builds that I haven’t yet been able to reduce.

On Wed, Nov 29, 2017 at 4:43 PM Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:
Hi Brandon,

This is probably a bug in the CoreFoundation C sources part of swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. Probably there is a constant string returned from CF function, then the Swift runtime assumes it can release it, and bam we wind up with an overrelease.

We’ll have to track down which function is getting called, which probably just requires stepping through that test case with a debugger…

- Tony

On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hello all!

We’ve been encountering this runtime error quite a bit recently, and we have no idea why. We’ve filed a bug and there’s one other on JIRA related to this, but both without any comments:

[SR-6422] Encountering "Constant strings cannot be deallocated" in Linux foundation · Issue #3785 · apple/swift-corelibs-foundation · GitHub
[SR-6398] Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118 · Issue #4053 · apple/swift-corelibs-foundation · GitHub

We’re curious if others are aware of this and or has more info? Is it a red herring for some other problem?

Any info would be helpful!

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

mbrandonw · November 30, 2017, 3:55am

Hey Tony,

We were able to fix our crashes by avoiding our uses of `URLQueryItem`s. In
one place I had to completely remove the use of `URLQueryItem`:

And in another my colleague Stephen Celis discovered that duplicate keys in
a query string can cause this to crash:

github.com/pointfreeco/swift-web

Fix another crash around URLComponents/URLQueryItem

pointfreeco:master ← pointfreeco:another-urlcomponents-crash-fix

opened 03:28AM - 30 Nov 17 UTC

stephencelis

+10 -6

This one took awhile to track down! It appears that Linux Foundation has some is…sues with URLComponents and URLs that contain the same query key twice. Let's avoid URLComponents for now, and have a coupla action items: 1. Change it so our GitHub response code string is optional (to avoid the double query, which is kinda undefined behavior). 2. Get a failing test case over to Apple.

He was able to come up with a minimal test case to demonstrate this:

And you can see the failure in this Travis CI report:

<Travis CI - Test and Deploy with Confidence;

At the bottom you’ll find:

```fatal error: Constant strings cannot be deallocated: file
Foundation/NSCFString.swift, line 118```

So definitely seems to be in that area!

Now, as far as rebuilding swift-corelibs-foundation, I’m down to try but I
dont really know much about how to do that. With some instructions I could
give it a shot.

Thanks for the help!

···

On Wed, Nov 29, 2017 at 5:59 PM Tony Parker <anthony.parker@apple.com> wrote:

I see a couple of places that are suspicious there:

Description:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L66

And the nameString / valueString constants in the copy query items
function:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1057

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1079

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1104

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1134

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1158

Do you have the ability to re-build swift-corelibs-foundation and run a
test? I suspect if you replace those with CFRetain(CFSTR(…)) then it will
fix your crash.

- Tony

On Nov 29, 2017, at 2:06 PM, Brandon Williams <mbw234@gmail.com> wrote:

Thanks for the info!

FWIW, most of the places I have encountered this so far have made use of
`URLComponents`, and have even been able to eliminate the crash by getting
rid of that code in a few places. The other JIRA bug on this topic also
mentions URLComponents in their repro case. Seems to be the culprit.

Also worth noting that in the above cases dealing with URLComponents the
crash only happens in DEBUG compilations, not RELEASE.

However, I do have another one of these crashes that _does_ happen on
RELEASE builds that I haven’t yet been able to reduce.

On Wed, Nov 29, 2017 at 4:43 PM Tony Parker <anthony.parker@apple.com> > wrote:

Hi Brandon,

This is probably a bug in the CoreFoundation C sources part of
swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the
CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. Probably
there is a constant string returned from CF function, then the Swift
runtime assumes it can release it, and bam we wind up with an overrelease.

We’ll have to track down which function is getting called, which probably
just requires stepping through that test case with a debugger…

- Tony

On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev < >> swift-corelibs-dev@swift.org> wrote:

Hello all!

We’ve been encountering this runtime error quite a bit recently, and we
have no idea why. We’ve filed a bug and there’s one other on JIRA related
to this, but both without any comments:

[SR-6422] Encountering "Constant strings cannot be deallocated" in Linux foundation · Issue #3785 · apple/swift-corelibs-foundation · GitHub
[SR-6398] Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118 · Issue #4053 · apple/swift-corelibs-foundation · GitHub

We’re curious if others are aware of this and or has more info? Is it a
red herring for some other problem?

Any info would be helpful!

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Philippe_Hausler · November 30, 2017, 4:31am

I think that perhaps we have a problem with the retain count flags in the definition of CFSTR. Previously the pinned reference would prevent the deallocation. This may have gotten clobbered with the latest CF import.

···

Sent from my iPhone

On Nov 29, 2017, at 7:55 PM, Brandon Williams via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hey Tony,

We were able to fix our crashes by avoiding our uses of `URLQueryItem`s. In one place I had to completely remove the use of `URLQueryItem`:

Fix crashes in URLComponents by mbrandonw · Pull Request #79 · pointfreeco/swift-web · GitHub

And in another my colleague Stephen Celis discovered that duplicate keys in a query string can cause this to crash:

Fix another crash around URLComponents/URLQueryItem by stephencelis · Pull Request #80 · pointfreeco/swift-web · GitHub

He was able to come up with a minimal test case to demonstrate this:

Minimal test-case for https://bugs.swift.org/browse/SR-6422 · pointfreeco/swift-web@cfa9b51 · GitHub

And you can see the failure in this Travis CI report:

Travis CI - Test and Deploy with Confidence

At the bottom you’ll find:

```fatal error: Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118```

So definitely seems to be in that area!

Now, as far as rebuilding swift-corelibs-foundation, I’m down to try but I dont really know much about how to do that. With some instructions I could give it a shot.

Thanks for the help!

On Wed, Nov 29, 2017 at 5:59 PM Tony Parker <anthony.parker@apple.com> wrote:
I see a couple of places that are suspicious there:

Description:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L66

And the nameString / valueString constants in the copy query items function:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1057
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1079
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1104
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1134
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1158

Do you have the ability to re-build swift-corelibs-foundation and run a test? I suspect if you replace those with CFRetain(CFSTR(…)) then it will fix your crash.

- Tony

On Nov 29, 2017, at 2:06 PM, Brandon Williams <mbw234@gmail.com> wrote:

Thanks for the info!

FWIW, most of the places I have encountered this so far have made use of `URLComponents`, and have even been able to eliminate the crash by getting rid of that code in a few places. The other JIRA bug on this topic also mentions URLComponents in their repro case. Seems to be the culprit.

Also worth noting that in the above cases dealing with URLComponents the crash only happens in DEBUG compilations, not RELEASE.

However, I do have another one of these crashes that _does_ happen on RELEASE builds that I haven’t yet been able to reduce.

On Wed, Nov 29, 2017 at 4:43 PM Tony Parker <anthony.parker@apple.com> wrote:
Hi Brandon,

This is probably a bug in the CoreFoundation C sources part of swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. Probably there is a constant string returned from CF function, then the Swift runtime assumes it can release it, and bam we wind up with an overrelease.

We’ll have to track down which function is getting called, which probably just requires stepping through that test case with a debugger…

- Tony

On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hello all!

We’ve been encountering this runtime error quite a bit recently, and we have no idea why. We’ve filed a bug and there’s one other on JIRA related to this, but both without any comments:

[SR-6422] Encountering "Constant strings cannot be deallocated" in Linux foundation · Issue #3785 · apple/swift-corelibs-foundation · GitHub
[SR-6398] Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118 · Issue #4053 · apple/swift-corelibs-foundation · GitHub

We’re curious if others are aware of this and or has more info? Is it a red herring for some other problem?

Any info would be helpful!

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Tony_Parker · December 1, 2017, 10:32pm

This isn’t it, because we always call through to swift_release in CFRelease on Linux, because the CFString is a swift type under the hood.

We may be able to change this to check for a CF specific hack of some kind, but in the meantime adding the retain works.

PR here:

- Tony

···

On Nov 29, 2017, at 8:31 PM, Philippe Hausler <phausler@apple.com> wrote:

I think that perhaps we have a problem with the retain count flags in the definition of CFSTR. Previously the pinned reference would prevent the deallocation. This may have gotten clobbered with the latest CF import.

Sent from my iPhone

On Nov 29, 2017, at 7:55 PM, Brandon Williams via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hey Tony,

We were able to fix our crashes by avoiding our uses of `URLQueryItem`s. In one place I had to completely remove the use of `URLQueryItem`:

Fix crashes in URLComponents by mbrandonw · Pull Request #79 · pointfreeco/swift-web · GitHub

And in another my colleague Stephen Celis discovered that duplicate keys in a query string can cause this to crash:

Fix another crash around URLComponents/URLQueryItem by stephencelis · Pull Request #80 · pointfreeco/swift-web · GitHub

He was able to come up with a minimal test case to demonstrate this:

Minimal test-case for https://bugs.swift.org/browse/SR-6422 · pointfreeco/swift-web@cfa9b51 · GitHub

And you can see the failure in this Travis CI report:

Travis CI - Test and Deploy with Confidence <Travis CI - Test and Deploy with Confidence;

At the bottom you’ll find:

```fatal error: Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118```

So definitely seems to be in that area!

Now, as far as rebuilding swift-corelibs-foundation, I’m down to try but I dont really know much about how to do that. With some instructions I could give it a shot.

Thanks for the help!

On Wed, Nov 29, 2017 at 5:59 PM Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:
I see a couple of places that are suspicious there:

Description:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L66

And the nameString / valueString constants in the copy query items function:

https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1057
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1079
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1104
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1134
https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/URL.subproj/CFURLComponents.c#L1158

Do you have the ability to re-build swift-corelibs-foundation and run a test? I suspect if you replace those with CFRetain(CFSTR(…)) then it will fix your crash.

- Tony

On Nov 29, 2017, at 2:06 PM, Brandon Williams <mbw234@gmail.com <mailto:mbw234@gmail.com>> wrote:

Thanks for the info!

FWIW, most of the places I have encountered this so far have made use of `URLComponents`, and have even been able to eliminate the crash by getting rid of that code in a few places. The other JIRA bug on this topic also mentions URLComponents in their repro case. Seems to be the culprit.

Also worth noting that in the above cases dealing with URLComponents the crash only happens in DEBUG compilations, not RELEASE.

However, I do have another one of these crashes that _does_ happen on RELEASE builds that I haven’t yet been able to reduce.

On Wed, Nov 29, 2017 at 4:43 PM Tony Parker <anthony.parker@apple.com <mailto:anthony.parker@apple.com>> wrote:
Hi Brandon,

This is probably a bug in the CoreFoundation C sources part of swift-corelibs-foundation. Unlike Darwin platforms, we can’t make the CFSTR(“”) macro produce a CFStringRef that cannot be overreleased. Probably there is a constant string returned from CF function, then the Swift runtime assumes it can release it, and bam we wind up with an overrelease.

We’ll have to track down which function is getting called, which probably just requires stepping through that test case with a debugger…

- Tony

On Nov 29, 2017, at 1:34 PM, Brandon Williams via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:

Hello all!

We’ve been encountering this runtime error quite a bit recently, and we have no idea why. We’ve filed a bug and there’s one other on JIRA related to this, but both without any comments:

[SR-6422] Encountering "Constant strings cannot be deallocated" in Linux foundation · Issue #3785 · apple/swift-corelibs-foundation · GitHub
[SR-6398] Constant strings cannot be deallocated: file Foundation/NSCFString.swift, line 118 · Issue #4053 · apple/swift-corelibs-foundation · GitHub

We’re curious if others are aware of this and or has more info? Is it a red herring for some other problem?

Any info would be helpful!

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev