mixxx crash when i load an other tracks

[Bozoo]

Hi, i use mixxx beta 3 in linux, to day i just load a tracks and mixxx crash :

Debug: Load to player1: "/home/johan/Bureau/test.wav" /
Debug: file length 17357842 i
Erreur de segmentation

After i just turn on again mixxx and load this tracks but not crash ... sometimes when i load a tracks mixxx crash)

johan@johan-laptop:~$ uname-a Linux johan-laptop 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 GNU/Linux

johan@johan-laptop:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.04
Release: 8.04
Codename: hardy

[olo (zulumantee)]

hi i experience the same problem with the beta3 version. i can also reproduce the crash

my system is a laptop with 2GB ram

$ uname -a
> Linux localhost 2.6.24.4.tex3 #1 SMP Sat Mar 29 16:07:20 CDT 2008 i686 Intel(R) Pentium(R) M processor 2.13GHz GNU/Linux
$ lsb_release -a
> LSB Version:
sb-3.1-ia32:lsb-3.1-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:cxx-3.0-ia32:cxx-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:lsb-3.0-ia32:lsb-3.0-noarch
Distributor ID: MandrivaLinux
Description: PCLinuxOS
Release: 2007
Codename: PCLinuxOS

i dont use a realtime kernel but I run jackd via QJackCtl with the following settings
jackd runs with nice -19

JACK_RELEASE = 0-111-5
JACK_VERSION = 0.111.5
JACK_PROTOCOL_VERSION = 23
JACK_SO_VERSION = 0:28:0

realtime ON
soft mode ON
priority 75
frames 256
buffer 4
lactency 21.2ms
hardware alesis io2

some other libs

qt version 4.4.0
libvorbisfile version 1.2.0-1
libvorbis version 1.2.0
libsndfile version 1.0.18-0
libalsa2 version 1.0.16-1

mixxx, jack, qt and other libs are manually compiled

gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007)

i collected some informations with gdb and the normal logging.
this is the debug logging and backtrace from gdb

[New Thread -1333044320 (LWP 5046)]
[Thread -1333044320 (LWP 5046) exited]
Debug: Midi OK (Workaround not required)
Debug: setupMappings( "/usr/local//share/mixxx/midi/Evolution_Xsession.midi.xml" )
Debug: slotApply crossfader: 1 "SlowFade"
Debug: Load to player2: "/home/olodumare/Documents/audio/remix/mochipet_contest_may_2008/35 - 099_lazyday_kflay_voxx.wav"
Debug: file length 18816000 i
Debug: WaveSummary generation successful for "35 - 099_lazyday_kflay_voxx.wav"
Debug: BPM detection failed, setting to 0.
Debug: Load to player2: "/home/olodumare/Documents/audio/remix/mochipet_contest_may_2008/37 - 108_do_what_you_feel_voxx.wav"
Debug: file length 16856000 i
Debug: WaveSummary generation successful for "37 - 108_do_what_you_feel_voxx.wav"
Debug: BPM detection successful for "37 - 108_do_what_you_feel_voxx.wav"
Debug: BPM 75.8267
Debug: Load to player1: "/home/olodumare/Documents/audio/traxx/Death_to_the_Fascist_Pigs_6.ogg"
Debug: file length 20869726 i
Debug: WaveSummary generation successful for "Death_to_the_Fascist_Pigs_6.ogg"

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1324651616 (LWP 5038)]
SoundSourceOggVorbis::read (this=0x882e8c0, size=8192, destination=0xb10b22f4)
    at src/soundsourceoggvorbis.cpp:129
129 dest[index] = 0;

(gdb) bt
#0 SoundSourceOggVorbis::read (this=0x882e8c0, size=8192, destination=0xb10b22f4)
    at src/soundsourceoggvorbis.cpp:129
#1 0x0816e6a2 in BpmDetector::run (this=0x85477c0) at src/bpmdetector.cpp:198
#2 0xb6e5a512 in QThreadPrivate::start (arg=0x85477c0) at thread/qthread_unix.cpp:190
#3 0xb6bfe562 in start_thread () from /lib/i686/libpthread.so.0
#4 0xb66994de in clone () from /lib/i686/libc.so.6

(gdb) bt full
#0 SoundSourceOggVorbis::read (this=0x882e8c0, size=8192, destination=0xb10b22f4)
    at src/soundsourceoggvorbis.cpp:129
No locals.
#1 0x0816e6a2 ...

[olo (zulumantee)]

also made a backtrace with (gdb) thread apply all bt
its there as an attachement.

pz olo

[olo (zulumantee)]

and the last info for tonite
I examined the variables in SoundSourceOggVorbis::read

(gdb) print index
$1 = 9404
(gdb) print dest
$2 = (SAMPLE *) 0xb10b22f4
(gdb) print *dest
$3 = 0
(gdb) print dest[1]
$4 = 0
(gdb) print dest[2]
$5 = 0
(gdb) print dest[8191]
$6 = 0
(gdb) print dest[8192]
$7 = -24512
(gdb) print ret
$8 = 0
(gdb) print dest
$9 = (SAMPLE *) 0xb10b22f4
(gdb) print needed
$10 = 6980
(gdb) print size
$11 = 8192
(gdb) print 2*size
$12 = 16384
(gdb) print 2*size-index
$13 = 6980
(gdb)

seems that the number of samples is too high in the variable "needed". its gets set to the nummber of channels times the buffer size or something
peaz olo

[Albert Santoni (gamegod)]

I just reproduced this crash, but I don't have time at the moment to debug it further:

Debug: Load to player1: "02-118-0_-_Interpol_-_Wrecking_Ball.ogg"
Debug: file length 24104472 i
Debug: DropEvent
file.c:353: free(0x87eaf58) memory not allocated
Debug: FIXME: repaintEverything switches table model and shouldn't do that when viewing the playlist model in src/wtracktableview.cpp: 216
[New Thread 0xae573b90 (LWP 21516)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xae573b90 (LWP 21536)]
0x080f0ab3 in SoundSourceOggVorbis::read (this=0x87b42b0, size=8192, destination=0xae56f1b0)
    at src/soundsourceoggvorbis.cpp:129
129 dest[index] = 0;
(gdb) bt
#0 0x080f0ab3 in SoundSourceOggVorbis::read (this=0x87b42b0, size=8192, destination=0xae56f1b0)
    at src/soundsourceoggvorbis.cpp:129
#1 0x08142d45 in SoundSourceProxy::read (this=0x8777e68, size=8192, p=0xae56f1b0)
    at src/soundsourceproxy.cpp:95
#2 0x0813e8b6 in BpmDetector::run (this=0x0) at src/bpmdetector.cpp:198
#3 0x00000000 in ?? ()

[olo (zulumantee)]

he people, i made a fix for this problem and i am going to test some mono and stereo ogg vorbis files in order to verify that everything still works.
i will post the patch then later today.

the problem was that the "index" variable used in "SoundSourceOggVorbis::read" is supposed to be the byte index for the "destination"
buffer which means that in can address 2*size bytes because the destination buffer holds size*16bit values.

when the read loop reaches the end of the file, the "destination" buffer is normally not filled completely and one tries to fill the remaining
space with zeros. in this case, the "index" variable is used again but to address the single 16bit value in the buffer. now index becomes too
large and exceeds the "size" value which causes the segmentation fault.

the reasons for that is that the "fill with zero" loop runs until the variable "needed" becomes zero. "needed" defines the remaining bytes to
put in the buffer and addresses 2*size bytes as well. in every loop run, index gets increased by one and finally exceeds the "size" of the
destination buffer.

i have two versions of the fix, one that still fills the buffer with zeros when the end of the file is reached and one that skips this part because the
amount of read samples is always returned to the "BpmDetector::run" function, from which "read" is called, and only that amount of samples is used
there further.

anyway, i will post the two versions of the patch soon today. peace olo

[ironstorm (ironstorm-gmail)]

Nice investigative work olo!

[olo (zulumantee)]

hi there, here are the two earlier mentioned versions of the patch.
what I have done in general is

soundsourceoggvorbis.h

- add a "char* pRead" member to the class "SoundSourceOggVorbis"

soundsourceoggvorbis.cpp

- initialised pointer members with zero in constructor
- used "pRead" pointer to read from the ogg vorbis file instead of the "dest" pointer
- the read loop now also stops when ov_read returns an error code. according to the documentation, ov_read
  can return three error codes which have all a negative number
- in the original version, problems could occure when an error code is returned by ov_read because that return value
  gets added and substracted to "index" and "needed". negative return values could cause infinte loops as "needed"
  would never reach zero. that is fixed by interchanging the order of the ov_read and the variable increment/decrement calls

only in version 1 of the patch

- removed the code that fills the "destination" buffer with zeros

only in version 2 of the patch

- the buffer gets filled with zeros when the end of the file is reached by using the pRead pointer instead of the dest pointer

feel free to check this out and tell me if I missed something or could hve done something in a different way.

greetzz, olo

[olo (zulumantee)]

patch version 1

[olo (zulumantee)]

patch version 2

[Albert Santoni (gamegod)]

Thank you very much for the patches olo!

I took a quick peek at them, and I find the first patch easier to understand. Which one would you recommend using?

I'll try to apply + commit your fix tonight.

Thanks again,
Albert

[olo (zulumantee)]

hey albert,

i like the first one also more coz it is cleaner but if u want the same behavior with filling the remaining buffer with zeros when the eof is reached then the second version is better.

hope everything worxx good! and nice to have the possibility to help u people. if i find something more i will take a look for sure but now its play time :)
greetings olo

[Albert Santoni (gamegod)]

Hey olo,

I ended up applying the first patch in order to preserve the behaviour that was there before (to zero out the buffer). I didn't want to take any chances in case patch #2 was going to have any side effects.

In any case, good job fixing this bug! If you email me your name (asantoni [at] uwo [dot] ca), I'd like to add you to Mixxx's credits.

Thanks again!

[Albert Santoni (gamegod)]

Fixed by olo!

[Swiftb0y (swiftb0y)]

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