std::bad_alloc crash on macOS

[vidoma]

Process: mixxx [928]
Path: /Applications/mixxx.app/Contents/MacOS/mixxx
Identifier: org.mixxx.mixxx
Version: 2.3.1 (2.3.1)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: mixxx [928]
User ID: 501

Date/Time: 2021-10-27 18:32:29.872 +0200
OS Version: macOS 11.6 (20G165)
Report Version: 12
Bridge OS Version: 6.0 (19P50284g)
Anonymous UUID: DB838A04-26C4-3269-C824-BDB84B166332

Please read the attachment file.

Time Awake Since Boot: 7600 seconds

System Integrity Protection: enabled

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

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

Application Specific Information:
abort() called
terminating with uncaught exception of type std::bad_alloc: std::bad_alloc

[Daniel Schürmann (daschuer)]

Can you remember what you was trying to do when the crash happens? Was this only a single occourance or did this happen more often.
Do you have an idea what could be caused the issue?

This one might be related: https://bugs.launchpad.net/mixxx/+bug/1944512

std::alloc is a hint for an out of memory situation or a memory fault.
Does Mixxx continuously require more memory? Please compare the memory consumption using Activity Monitor. After restart Mixxx and after let's say one hour usage.
Is there a significant difference?

[vidoma (massiccio)]

Thank you for your concern. Mixxx often crashes when I load a track on the dock. Mixxx crashes even after 20 minutes of use. My Mac has 16gb of memory (ram). Mix has never crashed on an old PC with Ubuntu and 8gb of memory. I have no idea why it happens.

[Foss-4 (foss-4)]

Does the development snapshot from https://mixxx.org/download/ crash for you on macOS 11.6.1?

Does mixxx also crash if you use it with pre-loaded tracks from a folder already known to mixxx?

[vidoma (massiccio)]

Mixxx also crashes if I use it with pre-loaded and known tracks by mixxx.
Mixxx just crashed a few minutes ago.
Next is the new log

[vidoma (massiccio)]

new log

[Foss-4 (foss-4)]

Please send logs in txt file format (you can simply copy to TextEdit). docx will have to be downloaded and then opened with an office application which is extremely inconvenient while txt can just be read in the browser.

The new crash log is still from 11.6 (not 11.6.1) and 2.3.1 (not main build).

[vidoma (massiccio)]

Yesterday I have uploaded my Mac to new version of Os and today Mixxx crashes again.
I report the new log.

[Foss-4 (foss-4)]

#9 log is macOS 12.0.1, mixxx 2.3.1

You can find the latest main build here: https://downloads.mixxx.org/snapshots/main/mixxx-2.4-alpha-969-gc09332ba10-macosintel.dmg

[vidoma (massiccio)]

Thank you very much. Do you thing it's better than old version?

[vidoma (massiccio)]

I have just dowloaded. Tomorrow I'll try it

[vidoma (massiccio)]

I have just tried the beta version 2.4. and crashed after 5100 sec. I don't know what I have to do.
I post the new log

[Owen Williams (ywwg)]

Here is the relevant part of the crash log:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 mixxx 0x10412423e QVector<QLineF>::reallocData(int, int, QFlags<QArrayData::AllocationOption>) + 142
1 mixxx 0x1038813d7 WaveformRenderBeat::draw(QPainter*, QPaintEvent*) + 887

[Owen Williams (ywwg)]

It looks like it might be crashing when we call m_beats.resize(m_beats.size() * 2);

[Owen Williams (ywwg)]

The other backtrace is different and seems to be entirely QT internals.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff2050492e __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff205335bd pthread_kill + 263
2 libsystem_c.dylib 0x00007fff20488406 abort + 125
3 libc++abi.dylib 0x00007fff204f6ef2 abort_message + 241
4 libc++abi.dylib 0x00007fff204e85e5 demangling_terminate_handler() + 242
5 libobjc.A.dylib 0x00007fff203e1595 _objc_terminate() + 104
6 libc++abi.dylib 0x00007fff204f6307 std::__terminate(void (*)()) + 8
7 libc++abi.dylib 0x00007fff204f8dd1 __cxa_rethrow + 99
8 libobjc.A.dylib 0x00007fff203df110 objc_exception_rethrow + 37
9 com.apple.AppKit 0x00007fff22e22cb2 -[NSApplication run] + 659
10 libqcocoa.dylib 0x000000010f7bba03 QCocoaEventDispatcher::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) + 3011
11 org.qt-project.QtCore 0x000000010d01ca3e QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) + 430
12 org.qt-project.QtCore 0x000000010d021b32 QCoreApplication::exec() + 130
13 org.mixxx.mixxx 0x000000010a05a209 main + 1513

Do any other programs crash on your machine? The code around these crashes don't look like we're doing anything wrong.

[vidoma (massiccio)]

Other programs don't crash. all is all right. Mixxx is the best program I have tried. What Have I do now?
Best regards.

[Owen Williams (ywwg)]

Can you run Apple Diagnostics just in case? https://support.apple.com/en-us/HT202731

[Daniel Schürmann (daschuer)]

Did you do the memory consumption check using "Activity Monitor"?

https://cdn-60c35131c1ac185aa47dd21e.closte.com//wp-content/uploads/2019/10/activity-monitor-columns.png

Please report the memory value after starting Mixxx and after 10 min of normal usage.
Is there a significant difference?

[vidoma (massiccio)]

I run apple diagnostic and It doesn't find any error, then I have checked the usage of memory. Massimum value 823 and minimum value 574. After 30 minutes 779, but after 40 minutes of recording when I load a track on the first deck (I use four deck) Mixxx try to crash and I press control command canc together and Mixxx doesn't stop, but after 130 minutes of usage and 100 minutes of recording Mixxx crash when I load a track on the first deck.
I post the new log.

[Owen Williams (ywwg)]

Another crash resizing the beat render vector. Does it always crash when you load that track? I don't know what you mean by a memory value of "823". Megabytes? Gigabytes? Can you post a screenshot of the activity monitor while mixxx is running?

I'm afraid without a set of predictable steps to reproduce we can't do anything to help -- the crashes are in low-level OS-related calls, not seemingly anything that mixxx is doing. I don't think we use m_beats from multiple threads so I don't think it's a race on that object.

And it looks like you're on an intel mac so it's not an M1 issue.

[vidoma (massiccio)]

Mixxx crashes only when I load a track on the first deck. The memory value is megabyte. I post the screenshoot of the activity monitor while mixxx is running.

[vidoma (massiccio)]

I Have played three times without using the first deck and I haven't had any problem, so I'm almost sure Mixxx crashes because there is an error on the first deck.

[vidoma (massiccio)]

I found the solution to analyze all the new songs at once.

Change interface and choose Shade - summer;

Upload a song to the first track;

Click on analyze;

Select the songs to analyze;

Click on analyze.

It works.

Now you have to understand why Mixxx crashes.

[Uwe Klotz (uklotzde-deactivatedaccount)]

Crashes can only be analyzed once someone is able to reproduce them.

[vidoma (massiccio)]

ranslated Report (Full Report Below)
-------------------------------------

Process: mixxx [688]
Path: /Applications/mixxx.app/Contents/MacOS/mixxx
Identifier: org.mixxx.mixxx
Version: 2.4.0 (2.4.0)
Code Type: X86-64 (Native)
Parent Process: launchd [1]
User ID: 501

Date/Time: 2022-02-02 17:17:26.7814 +0100
OS Version: macOS 12.1 (21C52)
Report Version: 12
Bridge OS Version: 6.1 (19P647)
Anonymous UUID: DB838A04-26C4-3269-C824-BDB84B166332

Time Awake Since Boot: 4200 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 0x0000000000000004
Exception Codes: 0x0000000000000001, 0x0000000000000004
Exception Note: EXC_CORPSE_NOTIFY

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

VM Region Info: 0x4 is not in any region. Bytes before following region: 4304146428
      REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL
      UNUSED SPACE AT START
--->
      __TEXT 1008c1000-103fed000 [ 55.2M] r-x/r-x SM=COW ...s/MacOS/mixxx

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 mixxx 0x10169fcde QVector<QLineF>::reallocData(int, int, QFlags<QArrayData::AllocationOption>) + 142
1 mixxx 0x100e75ba7 WaveformRenderBeat::draw(QPainter*, QPaintEvent*) + 887

Thread 1:: com.apple.NSEventThread
0 libsystem_kernel.dylib 0x7ff812b27aba mach_msg_trap + 10
1 libsystem_kernel.dylib 0x7ff812b27e2b mach_msg + 59
2 CoreFoundation 0x7ff812c2baf2 __CFRunLoopServiceMachPort + 319
3 CoreFoundation 0x7ff812c2a1cb __CFRunLoopRun + 1325
4 CoreFoundation 0x7ff812c295dd CFRunLoopRunSpecific + 563
5 AppKit 0x7ff8157c6d98 _NSEventThread + 132
6 libsystem_pthread.dylib 0x7ff812b644f4 _pthread_start + 125
7 libsystem_pthread.dylib 0x7ff812b6000f thread_start + 15

Thread 2:: EngineWorkerScheduler
0 libsystem_kernel.dylib 0x7ff812b2a506 __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff812b64a69 _pthread_cond_wait + 1224
2 mixxx 0x102cfbb4b QWaitConditionPrivate::wait(QDeadlineTimer) + 59
3 mixxx 0x102cfbae4 QWaitCondition::wait(QMutex*, QDeadlineTimer) + 100
4 mixxx 0x100a89de8 EngineWorkerScheduler::run() + 200

Thread 3:: EngineSideChain
0 libsystem_kernel.dylib 0x7ff812b2a506 __psynch_cvwait + 10
1 libsystem_pthread.dylib 0x7ff812b64a69 _pthread_cond_wait + 1224
2 mixxx 0x102cfbb4b QWaitConditionPrivate::wait(QDeadlineTimer) + 59
3 mixxx 0x102cfbae4 QWaitCondition::wait(QMutex*, QDeadlineTimer) + 100
4 mixx...

[vidoma (massiccio)]

Logical CPU: 0
Error Code: 0x00000006 (no mapping for user data write)
Trap Number: 14

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/10591