Crash when closing an organ

[willeke1234]

Every now and then closing an organ causes a crash or strange behavior. The strange behaviour could be something like creating a cache while caching is off or pressing a key when a stop is pulled. The crash occurs more often if the organ uses a lot of memory, but it can also occur with smaller organs. Steps to reproduce:

Load or open an organ Close Repeat

GO version: 3.13.0

Crash Reports.zip

[oleg68]

Is it a standard GO build from github or it is a custom build? If it is a custom build, could you reproduce this issue with the standard build (x86_64)?

[oleg68]

Do you have any warnings like Freeing non-empty memory pool in the log window before the crash?

[willeke1234]

It is an ARM build, the x86_64 standard build also crashes.

The log window doesn't appear

Version 3.7 on my old Mac has the same or a similar problem, but only with organ packages.

[willeke1234]

I don't know if it's related but if I start GO, load an organ (Friesach) and press the Panic button many times then GO hangs.

Sample of GrandOrgue v3.13.0.zip

[oleg68]

@willeke1234 could you try a fix of closing an organ from https://github.com/oleg68/GrandOrgue-official/actions/runs/6755745068 (the source code in https://github.com/oleg68/GrandOrgue-official/tree/bugfix/macos-close)?

[willeke1234]

@oleg68 I tried the downloaded X86 build and an ARM build, both still crash.

[oleg68]

@oleg68 I tried the downloaded X86 build and an ARM build, both still crash.

Could you post here the crash report from the new version?

[willeke1234]

More crash reports: Crash Reports 2.zip

[oleg68]

Was the organ cached or not?

[willeke1234]

Caching is off.

[oleg68]

Because I cann't reproduce this issue, the only way of discovering this problem is to make some debugging changes in GO, to compile it on your environment, to run it and to post here the debug output and crash reports.

@willeke1234, do you agree to do in this way?

[oleg68]

@willeke1234 If you are ready to participate in debugging, please

1. Take the sources from https://github.com/oleg68/GrandOrgue-official/tree/bugfix/macos-close
2. Compile on m1
3. Run GrandOrgue from a terminal window
4. Do File->Debug Close
5. Do File->Close
6. Post here the terminal output
7. If a crash occured, post here the crash report

[willeke1234]

@oleg68

Terminal output:

GOMemoryPool::AllocatePool: before mmap: 12884901888
GOMemoryPool::AllocatePool: after mmap: 0x280000000
GOFrame::OnMenuDebugClose: before allocating the pool
GOMemoryPool::AllocatePool: before mmap: 12884901888
GOMemoryPool::AllocatePool: after mmap: 0x580000000
GOFrame::OnMenuDebugClose: allocated the pool, 12884901888 bytes
GOMemoryPool::FreePool: before munmap: 0x580000000 12884901888
GOMemoryPool::FreePool: after munmap
GOFrame::OnMenuDebugClose: after dellocating the pool
libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
zsh: abort      
grandorgue@Virtuele-machine-van-GrandOrgue GrandOrgueBuild % 

Crash report: Crash Report.txt.zip

I did some debugging and put a breakpoint on GOSoundTouchWorkItem::~GOSoundTouchWorkItem(). It's hit before the crash in GOSoundTouchWorkItem::Run(GOSoundThread*). If I can help with more debugging, please let me know.

[nanoufo]

I managed to cause SIGSEGV when closing GrandOrgue on ubuntu by adding sleep() after retrieving a work item in GOSoundThread. Also I made a fix: link,

I hope the same fix works for that issue. @willeke1234 Could you compile it and see if the problem remains?

[willeke1234]

The fix works, GO reloaded 50 times and no crashes.