Mixxx crash with opus file (win)

Bug #1458380 reported by Sébastien BLAISOT
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Undecided
Unassigned

Bug Description

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

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :
Revision history for this message
Tuukka Pasanen (pasanen-tuukka) wrote :

What is your version of libopus?

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :

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.

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :

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.

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :

another backtrace with a debug build 1.12 r5407

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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?

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :

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

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :

of course memory is in MB, not Mb ;)

Revision history for this message
Daniel Schürmann (daschuer) wrote :

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.

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :

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.

Revision history for this message
Sébastien BLAISOT (sblaisot) wrote :

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

probably this bug can be closed.

Changed in mixxx:
status: New → Fix Committed
RJ Skerry-Ryan (rryan)
Changed in mixxx:
status: Fix Committed → Fix Released
RJ Skerry-Ryan (rryan)
Changed in mixxx:
milestone: none → 2.0.0
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.