Xojo.Core.Dictionary.HasKey crash

I’m getting a frustrating crash in a 32-bit Mac console app that I cannot reproduce outside my project.

I have a Xojo.Core.Dictionary property that was created by parsing JSON text. The dictionary has two items. When I use HasKey on a key that doesn’t exist, I crash (see partial log below).

The code is very simple:

dim dict as Xojo.Core.Dictionary = Claim // <-- Definitely not nil

dim key as auto = kKeyNotBefore // is "nbf" as Text
dim hasKey as boolean = dict.HasKey( key ) // <-- BOOM!

Any ideas before I file Feedback?

Process:               dragonc.debug [80036]
Path:                  /Users/USER/Documents/*/dragonc.debug
Identifier:            dragonc.debug
Version:               ???
Code Type:             X86 (Native)
Parent Process:        bash [80005]
Responsible:           dragonc.debug [80036]
User ID:               501

Date/Time:             2017-11-16 12:04:30.981 -0500
OS Version:            Mac OS X 10.12.6 (16G1036)
Report Version:        12
Anonymous UUID:        BCF7AA30-5988-FF2B-1E54-791B51FF135B

Sleep/Wake UUID:       4A7B4D87-9958-48C3-A018-9023942CA9F7

Time Awake Since Boot: 250000 seconds
Time Since Wake:       94000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000034
Exception Note:        EXC_CORPSE_NOTIFY

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

VM Regions Near 0x34:
--> 
    __TEXT                 0000000000001000-0000000001100000 [ 17.0M] r-x/rwx SM=COW  /Users/USER/Documents/*/*.debug

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   rbframework.dylib             	0x01310678 ClassDeclBase::FindEventHandler(RuntimeObject*, EventDecl const&) + 88
1   rbframework.dylib             	0x01414f5a AutoLessThan::operator()(RBAuto const&, RBAuto const&) const + 48
2   rbframework.dylib             	0x0141677b 0x12d0000 + 1337211
3   rbframework.dylib             	0x014150e5 Xojo_DictionaryContainsKey + 127
4   dragonc.debug                 	0x0001f966 Xojo.Core.Dictionary.HasKey%b%o<Xojo.Core.Dictionary>x + 52
5   dragonc.debug                 	0x007eb3b9 JSONWebToken_MTC.NotBeforeDate.Get%o<Xojo.Core.Date>%o<JSONWebToken_MTC>i4 + 346
6   dragonc.debug                 	0x007ea706 JSONWebToken_MTC.IsCurrent.Get%b%o<JSONWebToken_MTC>i4 + 445
7   dragonc.debug                 	0x009f9d44 JSONWebTokenTests.CreateTest%%o<JSONWebTokenTests> + 964
8   dragonc.debug                 	0x001111e4 Introspection.Invoke%% + 104
9   rbframework.dylib             	0x0136456f Introspection_GenericInvoker + 121
10  dragonc.debug                 	0x0001b96e Xojo.Introspection.MethodInfo.Invoke%x%o<Xojo.Introspection.MethodInfo>o<Object>A1x + 1091
11  dragonc.debug                 	0x0001b452 Xojo.Introspection.MethodInfo.Invoke%%o<Xojo.Introspection.MethodInfo>o<Object>A1x + 134
12  dragonc.debug                 	0x001d7351 TestGroup.RunTestsTimer_Action%%o<TestGroup>o<Xojo.Core.Timer> + 4124
13  dragonc.debug                 	0x0018b986 Delegate.IM_Invoke%%o<Xojo.Core.Timer> + 83
14  dragonc.debug                 	0x0014ac32 AddHandler.Stub.0%% + 51
15  rbframework.dylib             	0x012fa365 TimerImpCF::FireTimerAction() + 69
16  rbframework.dylib             	0x012fa427 TimerImpCF::TimerCallback() + 89
17  rbframework.dylib             	0x012fa31a 0x12d0000 + 172826
18  com.apple.CoreFoundation      	0x9426c996 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
19  com.apple.CoreFoundation      	0x9426c4ad __CFRunLoopDoTimer + 1213
20  com.apple.CoreFoundation      	0x9426bf4e __CFRunLoopDoTimers + 350
21  com.apple.CoreFoundation      	0x94263910 __CFRunLoopRun + 2192
22  com.apple.CoreFoundation      	0x94262e1a CFRunLoopRunSpecific + 506
23  com.apple.CoreFoundation      	0x94262c0b CFRunLoopRunInMode + 123
24  rbframework.dylib             	0x013bf12f 0x12d0000 + 979247
25  rbframework.dylib             	0x013bf0eb ModalEvents(unsigned char) + 36
26  rbframework.dylib             	0x013d2295 RuntimeDoEvents + 18
27  dragonc.debug                 	0x00057cec ConsoleApplication.DoEvents%%o<ConsoleApplication>i4 + 44
28  dragonc.debug                 	0x0097f387 UnitTestApp.Event_Execute%i4%o<UnitTestApp>o<OptionParserModule.OptionParser> + 4844
29  dragonc.debug                 	0x00332108 SubApplication.Run%i4%o<SubApplication>o<OptionParserModule.OptionParser> + 174
30  dragonc.debug                 	0x002dfca6 App.LaunchSubApp%i4%o<App>A1s + 1794
31  dragonc.debug                 	0x002dac90 App.Event_Run%i4%o<App>A1s + 8072
32  rbframework.dylib             	0x012efe87 CallConsoleApplicationRunEventHelper() + 374
33  dragonc.debug                 	0x001320d3 Delegate.Invoke%% + 34
34  dragonc.debug                 	0x00057f99 ConsoleApplication._CallFunctionWithExceptionHandling%%o<ConsoleApplication>p + 248
35  rbframework.dylib             	0x013bf096 CallFunctionWithExceptionHandling(void (*)()) + 322
36  rbframework.dylib             	0x0135c035 RuntimeRun + 58
37  dragonc.debug                 	0x0010febd REALbasic._RuntimeRun + 34
38  dragonc.debug                 	0x01058647 _Main + 295
39  dragonc.debug                 	0x01058090 main + 36
40  dragonc.debug                 	0x01060a6d start + 53

Purely out of curiosity: what do you get when you dump the dictionary object to a json string? Any crashing? Is the key in the dictionary? Can you call .hasKey on any of the keys that are in the json?

Good questions.

Generating JSON is fine:

{"exp":1510853065,"iat":1510853035}

The crash happens when I try “iat” too.

If I take the generated JSON and create a new Dictionary from it, HasKey works fine, but then I crash later on a call to Lookup. :confused:

This makes me very curious about the original source JSON. Any funky formatting / nonstandard stuff going on in it?
Can you share that source JSON here?

The source JSON was created from a Dictionary originally. This code appears in a unit test.

{"exp":1510853721,"iat":1510853691}

You are referencing something that does not exist which is why you get the EXC_CORPSE_NOTIFY statement in the crash report.

I am trying this code in a console app:

[code]Do

dim dict as New Xojo.Core.Dictionary // = Claim // <-- Definitely not nil

dim key as auto = “nbf” // kKeyNotBefore // is “nbf” as Text
dim hasKey as boolean = dict.HasKey( key ) // <-- BOOM!

DoEvents(200)

Loop[/code]

It runs without crashing so the “HasKey” method is not the problem.

Is kKeyNotBefore an object? You say it is “nbf” as Text but it seems like you are trying to reference a non-existent object.

The actual values differ because they are relative to the date/time it was created (SecondsFrom1970).

Just spitballing here: any chance there is something related to integer vs. double going on for those values? Could they be overflowing integers?

kKeyNotBefore is a text constant. I’ve confirmed the values of each element in the debugger and, as mentioned, if I create a new Dictionary from the JSON generated from the original, it works.

Then I should be able to reproduce the crash in a standalone project, no?

I can’t get it to crash here.
ClassDeclBase::FindEventHandler sounds like there is an overloaded convert operator involved.

Sounds like the obvious stuff to check has been checked and double checked. Time to file a feedback report.

I have one more idea to reproduce it externally. I’ll report after I get back.

Try
Dim Key As Text instead of Auto.

I’ve tried both.

“Good” news. If I move my class to a smaller project, I can get it to crash. If anyone else wants to look:

https://www.dropbox.com/s/mnkcsi8eve7s8kh/Dict%20Bug.xojo_binary_project?dl=0

Interestingly, if you change:

dim dict as Xojo.Core.Dictionary = Claim

To:

dim dict as Xojo.Core.Dictionary = Claim.Clone

Then you get different results each time you run the application.
It either works, gets a seg fault, or a runtime error.

I tried that too and it consistently crashed, but that’s on a Mac. A friend on Windows is getting results similar to what you reported. Which are you on?

<https://xojo.com/issue/50429>

Kem - OS X (El Capitan Here) - Tested on Xojo 2017r1.1, 2017r2.1

I’m getting three results intermixed:

It’s an object
It’s current

It’s an object
Segmentation fault: 11

It’s an object
Runtime Error
Please report what caused this error along with the information below.
Common/ObjectGlue.cpp: 167
Failure Condition: object->eventTable
Abort trap: 6

Can’t find any rhyme or reason to why it works/fails.

Anthony