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:
https://bugs.swift.org/browse/SR-6422
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!
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:
https://bugs.swift.org/browse/SR-6422
https://bugs.swift.org/browse/SR-6398We’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
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:https://bugs.swift.org/browse/SR-6422
https://bugs.swift.org/browse/SR-6398We’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
I see a couple of places that are suspicious there:
Description:
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 <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:
https://bugs.swift.org/browse/SR-6422
https://bugs.swift.org/browse/SR-6398We’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
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`:
https://github.com/pointfreeco/swift-web/pull/79/files#diff-293b73a926ba418bd9511ef735fc947cL147
And in another my colleague Stephen Celis discovered that duplicate keys in
a query string can cause this to crash:
https://github.com/pointfreeco/swift-web/pull/80
He was able to come up with a minimal test case to demonstrate this:
https://github.com/pointfreeco/swift-web/commit/cfa9b519a829f1c1627620521326f0877c2d023a
And you can see the failure in this Travis CI report:
https://travis-ci.org/pointfreeco/swift-web/builds/309316418
<https://travis-ci.org/pointfreeco/swift-web/builds/309316418?utm_source=email&utm_medium=notification>
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:
And the nameString / valueString constants in the copy query items
function: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:https://bugs.swift.org/browse/SR-6422
https://bugs.swift.org/browse/SR-6398We’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
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`:
https://github.com/pointfreeco/swift-web/pull/79/files#diff-293b73a926ba418bd9511ef735fc947cL147
And in another my colleague Stephen Celis discovered that duplicate keys in a query string can cause this to crash:
https://github.com/pointfreeco/swift-web/pull/80
He was able to come up with a minimal test case to demonstrate this:
https://github.com/pointfreeco/swift-web/commit/cfa9b519a829f1c1627620521326f0877c2d023a
And you can see the failure in this Travis CI report:
https://travis-ci.org/pointfreeco/swift-web/builds/309316418
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:
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#L1158Do 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:
https://bugs.swift.org/browse/SR-6422
https://bugs.swift.org/browse/SR-6398We’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
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:
https://github.com/apple/swift-corelibs-foundation/pull/1351
- 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`:
https://github.com/pointfreeco/swift-web/pull/79/files#diff-293b73a926ba418bd9511ef735fc947cL147
And in another my colleague Stephen Celis discovered that duplicate keys in a query string can cause this to crash:
https://github.com/pointfreeco/swift-web/pull/80
He was able to come up with a minimal test case to demonstrate this:
https://github.com/pointfreeco/swift-web/commit/cfa9b519a829f1c1627620521326f0877c2d023a
And you can see the failure in this Travis CI report:
https://travis-ci.org/pointfreeco/swift-web/builds/309316418 <https://travis-ci.org/pointfreeco/swift-web/builds/309316418?utm_source=email&utm_medium=notification>
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:
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#L1158Do 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:
https://bugs.swift.org/browse/SR-6422
https://bugs.swift.org/browse/SR-6398We’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