Mixxx crash with opus file (win)

[Sébastien BLAISOT]

Having the following file, taken from Mixxx test cases, in the library causes Mixxx to crash on library rescan or at launch if it was previously scanned : https://github.com/mixxxdj/mixxx/blob/1.12/src/test/id3-test-data/cover-test.opus

Mixxx 1.12 beta r5451 64 bits under Win seven ultimate SP1 64 bits

steps to reproduce :
1. Start mixxx with an empty preferences folder (fresh start)
2. select a library directory with this file in it
3. CRASH

[Tuukka Pasanen (pasanen-tuukka)]

What is your version of libopus?

[Sébastien BLAISOT (sblaisot)]

I'm using Mixxx under windows, so I suppose I use libopus version embedded within Mixxx.

I personnally didn't install anything related to libopus before installing Mixxx.

If this can help, in the Mixxx installation folder, I have a libvorbis, libFLAC, libogg, but no libopus.

[Sébastien BLAISOT (sblaisot)]

Hi,

Here a some additionnal informations :

* I have it also with last build 1.12 r5463

* I have the problem on one computer, but not on another one (same windows and mixxx version).

* When crashing, the console is showing :
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 12372.0x2990]
0x0000000140278103 in mixxx!??4RubberBandStretcher@RubberBand@@QEAAAEAV01@AEBV01

* attached is a backtrace (but I think it's incomplete and miss symbols). maybe it can help.

[Sébastien BLAISOT (sblaisot)]

another backtrace with a debug build 1.12 r5407

[Daniel Schürmann (daschuer)]

An interesting line is:

"Backtrace stopped: previous frame identical to this frame (corrupt stack?)"

One possible assumption is that some pointers are twisted and the crash is only a follow up effect happens
due to destroyed memory regions. Scary!

How big is the used memory just before the crash?
Does the --developer flag make any difference? Bug #1448630

Does the debugger work before this happens?
Are you able to break at any other position without the corrupt stack?
Do you have an own build environment? Is the backtrace form a buildserver build or from your own?

[Sébastien BLAISOT (sblaisot)]

I'll try to aswer all your questions:

> How big is the used memory just before the crash?

Mixxx uses 173Mb at crash. No memory grow just before crashing.

> Does the --developer flag make any difference? Bug #1448630

I had this without the --developper flag.
adding the developper flag doesn't make any difference with this crash except it uses 790+Mb of memory (a lot more).

>Does the debugger work before this happens?

I followed the instructions on http://mixxx.org/wiki/doku.php/creating_backtraces so Mixxx was launched by gdb.
Using gdb or not doesn't make any difference with this crash happening.

>Are you able to break at any other position without the corrupt stack?

Can you give me more instructions on this please, as I'm not a gdb expert, and i'll try it

>Do you have an own build environment? Is the backtrace form a buildserver build or from your own?

I don't have a build environnement.

I reproduced this with
- release build http://downloads.mixxx.org/builds/1.12/release/mixxx-1.12.0-beta1-1.12-git5463-release-x64.exe
- debug build http://downloads.mixxx.org/builds/1.12/debug/mixxx-1.12.0-beta1-1.12-git5407-debug-x64.exe

[Sébastien BLAISOT (sblaisot)]

of course memory is in MB, not Mb ;)

[Daniel Schürmann (daschuer)]

Unfortunately we have not debug symbols for our windows build. (Pending Bug #1456107)
But some are there. You can watch them from the gdb command prompt by

> info functions

> break opus_decoder_init

installs the break point

Load an opus file and check if the calls stack is valid.

[Sébastien BLAISOT (sblaisot)]

sorry, I'm not able to set breakpoint :

(gdb) break opus_decoder_init
Breakpoint 1 at 0x1403be624
(gdb) run
Starting program: C:\Program Files\Mixxx\mixxx.exe
[New Thread 11396.0xeb0]
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1403be5c0

I've run cmd as administrator, but it isn't sufficient.

[Sébastien BLAISOT (sblaisot)]

I tried today with Mixxx 1.12 r5575 and it doesn't crash anymore, so this seems fixed.

probably this bug can be closed.

[Swiftb0y (swiftb0y)]

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