EXC_BAD_ACCESS NameMap.init

[Turacbey]

The app is crashing while converting data to json string.

It crashes only on watch 3 series and WatchOS 7.0+. (haven't tried below of OS 7.0 ).

SwiftProtobuf version 1.14.0 is used.

Here is the crash log;

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x00000064

VM Region Info: 0x64 is not in any region.  Bytes before following region: 2408348
      REGION TYPE                START - END     [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                     24c000-570000   [ 3216K] r-x/r-x SM=COW  watch extension 

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [292]
Triggered by Thread:  0

Thread 0 Crashed
0  0x49df4e36 static _DictionaryStorage.resize(original:capacity:move:) + 6 (<compiler-generated>:0)
1   0x004c00d0 _NameMap.init(dictionaryLiteral:) + 14 (__hidden#422_:0)
2   0x00288964 globalinit_33_515866062A0CD3DA0C125022DB3203BD_func35 + 964 (MessageInfo.swift:6904)
3   0x5050b07c _dispatch_client_callout + 6 (object.m:559)
4  0x5050c100 _dispatch_once_callout + 14 (once.c:52)
5   0x49fe4d2a swift_once + 26 (once.h:111)
6  0x0028c280 _protobuf_nameMap.get + 14 (MessageInfo.swift:6904)
7  0x0028c280 protocol witness for static _ProtoNameProviding._protobuf_nameMap.getter in conformance Proto_MessageInfo + 96 (<compiler-generated>:6904)
8  	0x004b030e _hidden#51_ + 90 (__hidden#5009_:39)
9  .	0x004b7be4 __hidden#472_ + 26 (__hidden#422_:0)
10 	0x004b7be4 Message.jsonUTF8Data(options:) + 304 (__hidden#5346_:55)
11  0x004b7a52 Message.jsonString(options:) + 254 (__hidden#5346_:34)

[thomasvl]

Does this only fail in debug or does it also fail in release?

This sounds some what like some past issues (#779, #1034). The swift compiler ends up generating code that uses a lot of memory in non optimized cases, we've done some changes to try and work around things, but watchOS might have smaller limits that are causing this to happen. Can you share any details about your proto file(s) so we can see if there is something we can change in code generation to try and help reduce things?

[Turacbey]

@thomasvl

It fails on real devices. I can't catch it with simulator. But the key point is, this appears only on watch series 3. Series 5, 6 or se work great with no crash.

Can I user your email address that is on your GitHub profile to send the proto file?

[thomasvl]

It fails on real devices. I can't catch it with simulator. But the key point is, this appears only on watch series 3. Series 5, 6 or se work great with no crash.

Is that a debug build or a release build when it fails?

Can I user your email address that is on your GitHub profile to send the proto file?

Sure.

[Turacbey]

@thomasvl

It is a release build.

I sent you the proto file.

[thomasvl]

The raw .proto file is the most useful (I can always regenerate), but it makes it a little easier to see your structure quickly. :)

[Turacbey]

oh yes, let me check. :)

[thomasvl]

Recording some quick notes from a quick glance -

• The enums aren't that big, nothing over 100 cases, they do encode for init as .same cases.
• There is nesting of messages within other messages, but no oneofs, so the past issues where we had stack explosions is likely less of an issue.
• Since it fails in a release build, this and the stack trace said thread 1, we may just be generally screwed. Unless we can find some other way to enable the runtime info to initialized outside of a message parse it will be easy to run into some of the additive stack usage on the first parse/serialization.

Random ideas:

• For compact enums (where all the cases are serial from zero), it might be possible to do a different init that doesn't need to take a dictionary literal and instead could take a base (which should mostly be zero) and just an array. That might take less to pass in?
• Likewise, when all the enum cases are using a single enum mode to initialize, maybe pass a marker and then a straight array of the strings?
• When things are either of the above, maybe the capturing could be done as runs so when there are smaller outliners they can be passed to the init in chunks to reduce the memory needed during initialization?

[thomasvl]

Calling this an enhancement for the moment, because nothing we're doing is wrong, it's just a side effect of how Swift does some things that is resulting in the stack issues.

[Turacbey]

@thomasvl

Thank you very much for your feedback. These are so valuable. I will check it out.
If I had a watch series 3, everything could be easier. I have to find one :) or do you have a solution for testing without it, I would love to hear.

Thank you again!

[tkafka]

Hello, this is happening to me as well on an Apple Watch 3, when decoding protobuf JSON for the first time.

[Turacbey]

@tkafka If you find a solution or a way, can you let me know too?

I have been suffering from this problem for months. My app doesn't support watch3 Series because of the crash.

[tkafka]

@Turacbey I just changed the app to use binary protobuf format everywhere, instead of json.

[Turacbey]

@tkafka Thank for your answer. It needs too much effort for my project to do that.

I hope there will be a solution for the crash.