Protege Desktop 5.6.7 crashing on MacOS

[jclerman]

I recently upgraded from Protege 5.6.4 to 5.6.7. I am using it to edit a small (to me) ontology - about 5K classes, 168 object properties, 65K total axioms, of which about 11.5K are logical axioms.

Under 5.6.4, Protege was very stable. I have it configured to use up to 16GB of RAM but in practice i see it reporting usage (under 5.6.7) of far less - closer to 160MB.

I am running MacOS 15.6, on an M4 Max MBP with 36GB of RAM.

With the update to 5.6.7, Protege has become much less stable (sadly, since I really like the BioRegistry integration!). However, I am finding that after clicking on a few classes, running a text-search or two, maybe running the ELK reasoner (which classifies the ontology quickly, in under a second or two), Protege stops responding, after a few seconds I get the "spinning beachball" and I need to force-quit. I let MacOS collect a report after one such force-quit; near the top of the report there is a trace of the "heaviest stack for the main thread of the target process", which I include here in the hopes that it's helpful; I can provide other snippets from the report if those would be helpful (the whole thing is over 100K lines so I won't dump it all here).

Heaviest stack for the main thread of the target process:
  16  start + 6076 (dyld + 27544) [0x185f7ab98]
  16  main + 160 (protege + 9032) [0x100e2a348]
  16  start_java + 180 (protege + 12088) [0x100e2af38]
  16  CFRunLoopRun + 64 (CoreFoundation + 1000788) [0x18647e554]
  16  CFRunLoopRunSpecific + 572 (CoreFoundation + 502424) [0x186404a98]
  16  __CFRunLoopRun + 840 (CoreFoundation + 504936) [0x186405468]
  16  __CFRunLoopDoSources0 + 232 (CoreFoundation + 509972) [0x186406814]
  16  __CFRunLoopDoSource0 + 172 (CoreFoundation + 510632) [0x186406aa8]
  16  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 (CoreFoundation + 510740) [0x186406b14]
  16  __NSThreadPerformPerform + 264 (Foundation + 491380) [0x1879f2f74]
  16  +[ThreadUtilities invokeBlockCopy:] + 28 (libosxapp.dylib + 19760) [0x101bc8d30]
  16  +[AWTStarter starter:headless:] + 380 (libawt_lwawt.dylib + 352476) [0x140c560dc]
  16  +[NSApplicationAWT runAWTLoopWithApp:] + 132 (libosxapp.dylib + 13608) [0x101bc7528]
  16  -[NSApplication run] + 480 (AppKit + 187364) [0x18a31cbe4]
  16  -[NSApplicationAWT nextEventMatchingMask:untilDate:inMode:dequeue:] + 136 (libosxapp.dylib + 14088) [0x101bc7708]
  16  -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688 (AppKit + 10328384) [0x18acc8940]
  16  _DPSNextEvent + 684 (AppKit + 240180) [0x18a329a34]
  16  _BlockUntilNextEventMatchingListInModeWithFilter + 76 (HIToolbox + 2430084) [0x192035484]
  16  ReceiveNextEventCommon + 676 (HIToolbox + 812264) [0x191eaa4e8]
  16  RunCurrentEventLoopInMode + 324 (HIToolbox + 799356) [0x191ea727c]
  16  CFRunLoopRunSpecific + 572 (CoreFoundation + 502424) [0x186404a98]
  16  __CFRunLoopRun + 2200 (CoreFoundation + 506296) [0x1864059b8]
  16  __CFRunLoopDoSource1 + 508 (CoreFoundation + 511928) [0x186406fb8]
  16  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 60 (CoreFoundation + 512144) [0x186407090]
  16  mshMIGPerform + 208 (HIServices + 32760) [0x18d16cff8]
  16  _XCopyAttributeValue + 400 (HIServices + 294996) [0x18d1ad054]
  16  _AXXMIGCopyAttributeValue + 484 (HIServices + 162428) [0x18d18ca7c]
  16  CopyAttributeValue + 176 (AppKit + 5897936) [0x18a88eed0]
  16  CopyAppKitUIElementAttributeValueNoCatch + 92 (AppKit + 5911460) [0x18a8923a4]
  16  -[NSApplication(NSApplicationAccessibility) _accessibilityValueForAttribute:clientError:] + 60 (AppKit + 6175104) [0x18a8d2980]
  16  -[NSObject(NSAccessibilityInternal) _accessibilityValueForAttribute:clientError:] + 272 (AppKit + 5887240) [0x18a88c508]
  16  _NSAccessibilityEntryPointValueForAttribute + 224 (AppKit + 2640148) [0x18a573914]
  16  NSAccessibilityPerformEntryPointObject + 44 (AppKit + 8648372) [0x18ab2e6b4]
  16  ___NSAccessibilityEntryPointValueForAttribute_block_invoke.770 + 1520 (AppKit + 8665844) [0x18ab32af4]
  16  -[NSAccessibilityAttributeAccessorInfo getAttributeValue:forObject:] + 60 (AppKit + 750436) [0x18a3a6364]
  16  NSAccessibilityGetObjectValueForAttribute + 1576 (AppKit + 753132) [0x18a3a6dec]
  16  NSAccessibilityGetObjectForAttributeUsingLegacyAPI + 280 (AppKit + 755516) [0x18a3a773c]
  16  -[NSWindow(NSWindowAccessibility) accessibilityFocusedUIElement] + 88 (AppKit + 12115876) [0x18ae7cfa4]
  16  -[AWTView accessibilityFocusedUIElement] + 124 (libawt_lwawt.dylib + 35900) [0x140c08c3c]
  16  -[JavaComponentAccessibility accessibilityFocusedUIElement] + 552 (libawt_lwawt.dylib + 323996) [0x140c4f19c]
  16  jni_CallStaticObjectMethod + 252 (libjvm.dylib + 3629148) [0x102da205c]
  16  jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, Thread*) + 256 (libjvm.dylib + 3627484) [0x102da19dc]
  16  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) + 732 (libjvm.dylib + 3324604) [0x102d57abc]
  16  ??? [0x109118144]
  16  ??? [0x10911eee0]
  16  ??? [0x10911eee0]
  16  ??? [0x10911f19c]
  16  ??? [0x10911f19c]
  16  ??? [0x10911f19c]
  16  ??? [0x109123bfc]
  16  Java_sun_lwawt_macosx_LWCToolkit_doAWTRunLoopImpl + 252 (libawt_lwawt.dylib + 355328) [0x140c56c00]
  16  -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212 (Foundation + 367736) [0x1879d4c78]
  16  CFRunLoopRunSpecific + 572 (CoreFoundation + 502424) [0x186404a98]
  16  __CFRunLoopRun + 1208 (CoreFoundation + 505304) [0x1864055d8]
  16  __CFRunLoopServiceMachPort + 160 (CoreFoundation + 511164) [0x186406cbc]
  16  mach_msg + 24 (libsystem_kernel.dylib + 4008) [0x1862d9fa8]
  16  mach_msg_overwrite + 484 (libsystem_kernel.dylib + 38756) [0x1862e2764]
  16  mach_msg2_trap + 8 (libsystem_kernel.dylib + 3124) [0x1862d9c34]
 *16  ??? (kernel.release.t6041 + 199252) [0xfffffe00087a4a54]

I will need to roll back, probably to 5.6.4. Anything I can do to stabilize Protege 5.6.7, or to provide more info?

[gouttegd]

Anything I can do to stabilize Protege 5.6.7, or to provide more info?

I don’t think there’s anything you can do on your side, but you may be able to help figure out what the problem is within Protégé.

(1) Any chance you could share that ontology you are working on? Is it publicly available somewhere? I don’t think there is anything wrong with it (and it’s certainly not large enough to cause any issues), but it may contain something that triggers a particular bug in Protégé.

(2) Any chance you could test with Protégé 5.6.5 and Protégé 5.6.6? That could help me to pinpoint when the bug was introduced.

[gouttegd]

I have a possible explanation, and if it is correct a possible fix, for the bug.

Can you try using the following 5.6.8-beta1 version (signature) with your ontology, and check if you still observe the crash?

[jclerman]

Unfortunately I can't share the ontology; it's not publicly available. I can answer questions about the types of axioms, content, etc though.

I can test with 5.6.5 and 5.6.6, but first I'll try with the beta version you shared - thanks for looking into this!

[jclerman]

OK, just tried with 5.6.8 beta1 - that does seem to work! I was unable to reproduce the hang/crash, even after a lot of clicking on various classes/properties and after running the ELK reasoner. I did notice occasional pauses of about a second when clicking on a class for the first time - that's new since 5.6.4. Maybe that's related to network calls to BioRegistry? With 5.6.7, after a pause like that, Protege never recovers and I get the hang; with 5.6.8-beta1, it recovers fine.

If I'm right about the network calls (I realize I could be completely off-base): Would it make sense/be feasible to scan the ontology for prefixes upon initial load, and pre-warm any cache of BioRegistry results for all prefixes found?

[gouttegd]

Unfortunately I can't share the ontology; it's not publicly available.

No worries, I understand.

OK, just tried with 5.6.8 beta1 - that does seem to work! I was unable to reproduce the hang/crash, even after a lot of clicking on various classes/properties and after running the ELK reasoner.

Great! No need to bother trying the 5.6.5 and 5.6.6, then. Thanks for trying the beta.

I did notice occasional pauses of about a second when clicking on a class for the first time - that's new since 5.6.4. Maybe that's related to network calls to BioRegistry?

It may not be the only reason, but that’s a possible one, yes.

Would it make sense/be feasible to scan the ontology for prefixes upon initial load, and pre-warm any cache of BioRegistry results for all prefixes found?

That’d be feasible, yes.

There are at least two other options I am considering:

• Instead of querying the Bioregistry for every new prefix encountered, get once and for all the complete list of known prefixes – similar to what you’re suggesting (in that we make only one single request), except that we don’t bother scanning the ontology for prefixes, we take everything the Bioregistry has.
• We bundle a copy of the Bioregistry prefixes data (not the entire Bioregistry – just the associations prefix → URL) directly within Protégé, so that we never need any network call at all at runtime (I’d need to check with the Bioregistry folks if they are fine with that).

Not sure yet about the most sensible approach, I’ll have to make some tests.