EXC_BAD_ACCESS on NameMap init #1014
Comments
|
This sounds a little like #1013. But without a repo case, it is sorta hard to tell what is happening. Can you make a isolated sample that shows it? |
Thanks for the quick reply! I can definitely work on isolating this with a minimal example. Just to mention this is happening under debug configuration. Just to highlight a difference from issue you referenced. I have not yet tried it on a release configuration. Enabling address sanitizer makes it work as expected. Also tried with latest Xcode and OS version and same crash happens which also differs from the description on the referenced issue. |
|
What version of Mojave are you on? Are you fully up to date? I think it was 10.14.4 that Apple changed around handing the the Swift runtime (shipping it with the OS), so if you're in an odd state where the Xcode tooling expects it to be handled differently from what your OS version does, it could lead to odd crashes. |
|
I'm particularly on 10.14.6, but as I said this was also tested using latest tooling available leading to the same crash. |
|
Ok, just wanted to check since I realized I'd hit issues trying to use old Xcode versions to recheck things. In any case, a repo case would be great, especially since you say you can get it on current versions. |
|
thanks for hanging in there! I'm running latest on all fronts now. SwiftProtobuf is at 1.9.0, protoc is 3.12.3, running everything on Mac OS 10.15.5 and using Xcode 11.5. The crash still comes from a EXC_BAD_ACCESS on this line: The call to that code comes from here: In particular, this line: The source proto is: While PDFDocumentAnalysis proto looks like this: Important point to highlight is that it only crashes when the decoding is being done on a background thread. If I run it on the main thread, it just works. Here's the complete backtrace of this run: I know not having a self-contained example that can trigger this makes debugging difficult. I'm working on getting that done, but in the mean time, any thoughts/ideas around where this may be coming from? Thanks! |
That suggests a possible issue regarding threading. If you can get a run with Thread Sanitizer turned on it'd be a good idea to start there, as it's possible this is a threading issue in your code. If not, I think the traceback is very strange. We're in the middle of a bunch of type metadata gathering for the generic call to |
|
Thanks @Lukasa. Enabling thread sanitiser makes the app crash on the same place I reported this issue for the first time. Does that tell anything about this issue? On the other hand, enabling address sanitiser makes the app NOT to crash. I doubt there's a threading issue that our code is introducing since I'm isolating the code by loading the data from a file and triggering the decoding process on app delegate's did finish launching like this: I changed the above to use DispatchQueue.main then it works as expected. Also if I remove the problematic data from the JSON it also works as expected even when dispatched on a background thread. |
This, combined with the amount of recursion in the backtrace, makes me think that you're hitting the stack size limit for background threads, which is much smaller than the main thread (512KB vs. 8MB). https://developer.apple.com/library/archive/qa/qa1419/_index.html We've run into the similar problems in swift-format with very deep syntax trees. I'm not aware of any way to control the stack size of threads created by Dispatch, unfortunately; but Foundation's A quick and dirty test you could try would be to have your dispatch task immediately start a |
|
@allevato you were spot on! stackSize = 8192 * 8 fails, but stackSize = 8192 * 9 works! One thing that I do find strange though is that I don't think our tree is that complex though: May that be a sign that something else is going on? |
|
Btw I have the project where this is isolated ready to be shared. I just would like a way to share it privately so our protos aren't exposed publicly. Would you be able to take a look at it? |
|
Since this seems to be the Swift runtime and stack usage thing, it likely makes sense to open a Swift bug. I think you can also open a feedback with Apple and post your code to that so it remains private (just have the public issue reference the feedback number to help Apple folks connect the dots). |
|
Just to clarify one detail: I presume this is in a debug build? Does it still crash in a release (optimized) build? (I would expect a release build to optimize away some of the generic operations that are getting invoked here. I suspect that this would result in an optimized build requiring less stack space in this particular case.) |
|
Once you do file a feedback and/or open a Swift issue, please link it here so it can be referenced if needed. Thanks. |
thomasvl
added a commit
to thomasvl/swift-protobuf
that referenced
this issue
Aug 17, 2020
Look at the recursive cost of message fields also, so a nesting of messages all just under the limit doesn't result in a top level message over the limit. This also addresses some of the issues from apple#1034 and hopefully from apple#1014. This is also work on apple#735
|
@nanocba have you gotten a chance to see if the mentioned changes help your case out? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our app is crashing while trying to convert from JSON with an EXC_BAD_ACCESS on one of the _protobuf_nameMap of our protos.
It crashes for a specific proto (others work just fine). At first we thought the JSON may be off, our swift protos were off, but we discarded that after double checking everything looked good on that front.
Then I enabled the address sanitizer diagnostic tool and surprinsingly leaving it enabled makes the app to stop crashing which lead us to believe this is not strictly related to the parsing of our models, but instead a memory related issue.
This is the proto where the app crashes:
This is the model we are trying to convert from, specifically where the status field lives:
The EXC_BAD_ACCESS crash happens on the initializer of the NameMap struct:
Here's full stack trace:
I'm developing on MacOS Mojave using 1.8.0. Tried also with Xcode 11.5, Catalina OS and 1.9.0 and it crashes in the same place.
The text was updated successfully, but these errors were encountered: