LOGOS 9.1 frequently crashing on Mac when trying to play hebrew bible audio

OS X Catalina 10.15.7

Logos 9.1

It looks like an assertion is failing in the app controller code.

I have been trying to listen to hebrew words, so my workflow is to look for a lemma, find it's occurrences, then look in the LHB, say Proverbs 20.27, then look in the Hebrew audio (which, infuriatingly, only contains chapter and not verse milestones). Once I get to Proverbs 20, I don't want to listen to the whole chapter until I get to verse 27, so I click on the timeline towards the end. This is when the audio resource freezes and I crash, always with the same stack trace. If I just press "play" and listen to all 26 verses, it doesn't crash. When I try to click past the middle of the play line it crashes often. Not 100% of the time, but enough to cause dozens of crashes in a single listening session.

Needless to say, this is significantly hurting my productivity as I attempt to listen to all the hebrew lemmas I'm trying to learn.

stack trace:

Process: Logos [64171]
Path: /Applications/Logos.app/Contents/MacOS/Logos
Identifier: com.logos.Logos
Version: 9.1.0.18 (62001.0.18)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Logos [64171]
User ID: 501

Date/Time: 2021-01-01 01:26:56.784 -0700
OS Version: Mac OS X 10.15.7 (19H114)
Report Version: 12
Bridge OS Version: 5.1 (18P3030)
Anonymous UUID: 08633468-A2A3-B1F9-BDF5-45182F732503

Sleep/Wake UUID: 38F21BCB-9F44-4CB7-A88C-5E40607927F4

Time Awake Since Boot: 790000 seconds
Time Since Wake: 7000 seconds

System Integrity Protection: enabled

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

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Application Specific Information:
/Volumes/Code/Jenkins/workspace/Logos-Desktop-Mac-Beta-Ship/LogosDesktop/src/macintosh/Logos4/AppController/OurAppController.m:1146: failed assertion `System.OverflowException: TimeSpan overflowed because the duration is too long.
at System.TimeSpan.Interval (System.Double value, System.Int32 scale) [0x00051] in <09c753df1c0d482692e4ce59c68ea8da>:0
at System.TimeSpan.FromMilliseconds (System.Double value) [0x00000] in <09c753df1c0d482692e4ce59c68ea8da>:0
at Libronix.DigitalLibrary.Resources.Media.Display.AudioVideoPlayerView.set_MediaPositionMilliseconds (System.Double value) [0x00000] in /Volumes/Code/Jenkins/workspace/DigitalLibrary-NuGet-Mac-Dev/DigitalLibrary/src/Libronix.DigitalLibrary.Resources/Media/Display/AudioVideoPlayerView.cs:198
at Bootstrap.AudioVideoPlayerViewHelpers.set_MediaPositionMilliseconds (Libronix.DigitalLibrary.Resources.Media.Display.AudioVideoPlayerView self, System.Double value) [0x00000] in <f74c6f188e724432b9dffca20cba1651>:0
at (wrapper native-to-managed) Bootstrap.AudioVideoPlayerViewHelpers.set_MediaPositionMilliseconds(Libronix.DigitalLibrary.Resources.Media.Display.AudioVideoPlayerView,double,System.Exception&)'

Thread 0 Crashed:: tid_307 Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff6da1933a __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff6dad5e60 pthread_kill + 430
2 libsystem_c.dylib 0x00007fff6d9a0808 abort + 120
3 libmonosgen-2.0.1.dylib 0x0000000108dd973e mono_post_native_crash_handler + 14
4 libmonosgen-2.0.1.dylib 0x0000000108d757bb mono_handle_native_crash + 475
5 libmonosgen-2.0.1.dylib 0x0000000108dd893b sigabrt_signal_handler + 171
6 libsystem_platform.dylib 0x00007fff6daca5fd _sigtramp + 29
7 ??? 0x000000010835b290 0 + 4432704144
8 libsystem_c.dylib 0x00007fff6d9a0808 abort + 120
9 libsystem_c.dylib 0x00007fff6d99fac6 __assert_rtn + 314
10 com.logos.ApplicationBundle 0x0000000107ee0469 -[OurAppController exceptionHandler:shouldHandleException:mask:].cold.1 + 137
11 com.logos.ApplicationBundle 0x00000001078f0b6d -[OurAppController exceptionHandler:shouldHandleException:mask:] + 12
12 com.apple.ExceptionHandling 0x00007fff35d11071 -[NSExceptionHandler _handleException] + 380
13 com.apple.ExceptionHandling 0x00007fff35d10d88 NSExceptionHandlerUncaughtExceptionHandler + 247
14 com.apple.CoreFoundation 0x00007fff3392f93c __handleUncaughtException + 726
15 libobjc.A.dylib 0x00007fff6c72b5a3 _objc_terminate() + 90
16 libc++abi.dylib 0x00007fff6ac00887 std::__terminate(void (*)()) + 8
17 libc++abi.dylib 0x00007fff6ac00829 std::terminate() + 41
18 libdispatch.dylib 0x00007fff6d87866c _dispatch_client_callout + 28
19 libdispatch.dylib 0x00007fff6d883cab _dispatch_main_queue_callback_4CF + 936
20 com.apple.CoreFoundation 0x00007fff33879e81 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
21 com.apple.CoreFoundation 0x00007fff33839c87 __CFRunLoopRun + 2028
22 com.apple.CoreFoundation 0x00007fff33838e3e CFRunLoopRunSpecific + 462
23 com.apple.HIToolbox 0x00007fff32465abd RunCurrentEventLoopInMode + 292
24 com.apple.HIToolbox 0x00007fff324657d5 ReceiveNextEventCommon + 584
25 com.apple.HIToolbox 0x00007fff32465579 _BlockUntilNextEventMatchingListInModeWithFilter + 64
26 com.apple.AppKit 0x00007fff30aab039 _DPSNextEvent + 883
27 com.apple.AppKit 0x00007fff30aa9880 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352
28 com.apple.AppKit 0x00007fff30a9b58e -[NSApplication run] + 658
29 com.logos.Logos 0x0000000105528aee DesktopApplicationMain + 1426
30 com.logos.Logos 0x0000000105528bea main + 9
31 libdyld.dylib 0x00007fff6d8d1cc9 start + 1

Find more posts tagged with

Desktop App

Comments

Robert Sussland

One thing that this might be related to -- I know it sounds crazy -- but the entire Logos package is extremely buggy when it comes to any sort of screen scaling. Things jump around and resize. I need to often manually adjust fonts that look gargantuan, and if I just touch the font magnification bar they snap back to normal. Now, I know no sane developer would calculate some pixel offset from the start button and convert that to a time to feed into an audio player, so that if there is some problem with screen scaling, you'd be feeding possibly negative or overlong values. I mean, you wouldn't use that type of a calculation to compute a time for an audio file, would you? You'd first check to see where the play click was registered on the timeline, confirm its on the timeline, and only *then* make a time calculation so that no asserts would fail. So this is probably totally unrelated to the constant crashing and scaling problems, but it might be worth a double check.

Mike Binks

Greeting Robert

I guess the techy volunteers will ask you to attach logs using the paper clip.

Long printout of reports are hard to analyse.

See my signature line if you need help.

Hope you get this sorted out and can have a successful new year.

Kevin A

https://community.logos.com/discussion/comment/1145820#Comment_1145820

You could test your theory by resetting your scaling to 100%.

Keep Smiling 4 Jesus :)

I have been trying to listen to hebrew words, so my workflow is to look for a lemma, find it's occurrences, then look in the LHB, say Proverbs 20.27, then look in the Hebrew audio (which, infuriatingly, only contains chapter and not verse milestones). Once I get to Proverbs 20, I don't want to listen to the whole chapter until I get to verse 27, so I click on the timeline towards the end. This is when the audio resource freezes and I crash, always with the same stack trace. If I just press "play" and listen to all 26 verses, it doesn't crash. When I try to click past the middle of the play line it crashes often. Not 100% of the time, but enough to cause dozens of crashes in a single listening session.

Repeatable description of crash is helpful. Apologies for not being unable to repeat this Hebrew Audio crash using Logos 9.2 Beta 2 on macOS 10.15.7 Catalina with Logos Content & Program Scaling set to 100% while macOS System Preferences has Display scaled for everything:

Imagine Faithlife developers would like to look at Logos Diagnostic Logs (for more crash context). Logos Wiki has => Diagnostic Logging

In 2016, Apple changed operating system name from OS X to macOS with 10.12 Sierra release. Last OS X was 10.11 El Capitan.

Keep Smiling [:)]

Robert Sussland

https://community.logos.com/discussion/comment/1145867#Comment_1145867

Setting something to scale at 100% isn't exactly considered scaling, now, is it? The issue is with Logos wonky scaling, but then I think we all know that.

Anyways, I induced another crash and attached logs3125.LogosLogs.rsussland.20210101-112314.zip

Dave Hooton

https://community.logos.com/discussion/comment/1145915#Comment_1145915

The log indicates that the time interval you skip is too long. It may be a bug, but use smaller intervals.

this is significantly hurting my productivity as I attempt to listen to all the hebrew lemmas I'm trying to learn

But why don't you use the Pronunciations tool, or Bible Word Study, or compile a Word List, all of which allow pronunciation of lemmas?

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1145915#Comment_1145915

Setting something to scale at 100% isn't exactly considered scaling, now, is it? The issue is with Logos wonky scaling, but then I think we all know that.

Changing macOS display scaling allows Logos (& Verbum) to use 100% resolution with macOS displaying scaled results for user interaction (along with macOS sending back "scaled" click locations to application). A number of forum threads describe Logos & Verbum application scaling having some display and interaction issues so one troubleshooting step is changing application scaling back to 100% when trying to repeat issue.

Keep Smiling [:)]