Script Engine Crash

[gimmeapill]

Some intermitent crashes with Mixxx 1.7.1 (full system information is in the attached file).
I cannot find a reliable way to reproduce, the problem seems to be completely random and happens more or less once per hour.

Here is the gdb log/backtrace:

Debug: [Main]: Load to player2: "/home/extra/Musik/cadenza/[cadenza 009] luciano & salif keita - salif keita remix/01 - Luciano & Salif Keita - Yamore (Luciano Remix).mp3"
Debug: [Reader 2]: file length 65889792 i
Debug: [AnalyserQueue 1]: AnalyserWaveform: f 44100 samplesPerDownsample: 110 downsamples 598998 from 65889792
Debug: [Main]: Received waveform from track

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb1ae1b70 (LWP 5545)]
0xb68a0c1c in ?? () from /lib/i686/cmov/libc.so.6
(gdb) bt
#0 0xb68a0c1c in ?? () from /lib/i686/cmov/libc.so.6
#1 0xb68a317e in malloc () from /lib/i686/cmov/libc.so.6
#2 0xb6c0fe1d in qMalloc(unsigned int) () from /usr/lib/libQtCore.so.4
#3 0xb6c5bcd9 in QString::realloc(int) () from /usr/lib/libQtCore.so.4
#4 0xb6e7ee7e in ?? () from /usr/lib/libQtScript.so.4
#5 0xb6e81856 in ?? () from /usr/lib/libQtScript.so.4
#6 0xb6e772ca in ?? () from /usr/lib/libQtScript.so.4
#7 0xb6e81856 in ?? () from /usr/lib/libQtScript.so.4
#8 0xb6e968cb in ?? () from /usr/lib/libQtScript.so.4
#9 0xb6ed1e67 in QScriptValue::call(QScriptValue const&, QList<QScriptValue> const&) () from /usr/lib/libQtScript.so.4
#10 0x081cbe2d in ?? ()
#11 0x081cbfa9 in ?? ()
#12 0x080e3112 in ?? ()
#13 0x081d3240 in ?? ()
#14 0xb6c155e2 in ?? () from /usr/lib/libQtCore.so.4
#15 0xb6ab4585 in start_thread () from /lib/i686/cmov/libpthread.so.0
#16 0xb69022be in clone () from /lib/i686/cmov/libc.so.6

[Wesley Werner (wesley-werner)]

Greetings.
I'm not sure if our crashes are related, they seem to fail at the same point, but I get different error, are you running a compiled version perhaps?. I'm using Mixxx 1.7.1 from the download page, running on Ubuntu Karmic, kernel 2.6.31-15.

Note I'm aware of the PortAudio issue for Ubuntu 9.04, but uncertain of it's status in 9.10. The crash happens before I play any audio, for ALSA, OSS or even when None device is selected.

I can recreate this crash by loading a specific file into "Player 1" (from a fresh Mixx startup, nothing playing). The file has 0 BPM and loads the waveform display for a split second, and then it bombs out. Most of the other files load fine.

Let me know if there's any way I can provide more info, willing to compile if needed.

Attached is the backtrace.

[Albert Santoni (gamegod)]

Wesley: Can you try to reproduce the crash while running Mixxx under gdb?

A backtrace including information for all of our threads would be very
helpful, and we have instructions for getting that here:
http://mixxx.org/wiki/doku.php/creating_backtraces

I have the feeling Mixxx is bombing in the BPM detection algorithm in
both of your cases. Can you check to see if there's specific files
that are causing reproducible crashes?

Thanks,
Albert

On Tue, Dec 8, 2009 at 1:34 PM, Wesley Werner <email address hidden> wrote:
> Greetings.
> I'm not sure if our crashes are related, they seem to fail at the same point, but I get different error, are you running a compiled version perhaps?. I'm using Mixxx 1.7.1 from the download page, running on Ubuntu Karmic, kernel 2.6.31-15.
>
> Note I'm aware of the PortAudio issue for Ubuntu 9.04, but uncertain of
> it's status in 9.10. The crash happens before I play any audio, for
> ALSA, OSS or even when None device is selected.
>
> I can recreate this crash by loading a specific file into "Player 1"
> (from a fresh Mixx startup, nothing playing). The file has 0 BPM and
> loads the waveform display for a split second, and then it bombs out.
> Most of the other files load fine.
>
> Let me know if there's any way I can provide more info, willing to
> compile if needed.
>
> Attached is the backtrace.
>
> ** Attachment added: "Mixxx backtrace"
>   http://launchpadlibrarian.net/36601650/mixxx_backtrace.txt
>
> --
> Random crash with 1.7.1
> https://bugs.launchpad.net/bugs/493793
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[gimmeapill (gimmeapill)]

Hi Wesley,
I cannot tell for sure if it is the same bug, but I could reproduce both with the official debian package, the non official ubuntu package and my compiled binaries. It doesn't seem to happen particularly when loading a song, but I may be wrong. I'm trying to reproduce the problem at the moment under gdb, but didn't get any good backtrace yet...

[Wesley Werner (wesley-werner)]

Hi, I will run and post the gdb results tonight after work. Thanks for the
link Albert.

On Wed, Dec 9, 2009 at 8:19 PM, gimmeapill <email address hidden> wrote:

> Hi Wesley,
> I cannot tell for sure if it is the same bug, but I could reproduce both
> with the official debian package, the non official ubuntu package and my
> compiled binaries. It doesn't seem to happen particularly when loading a
> song, but I may be wrong. I'm trying to reproduce the problem at the moment
> under gdb, but didn't get any good backtrace yet...
>
> --
> Random crash with 1.7.1
> https://bugs.launchpad.net/bugs/493793
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Mixxx: New
>
> Bug description:
> Some intermitent crashes with Mixxx 1.7.1 (full system information is in
> the attached file).
> I cannot find a reliable way to reproduce, the problem seems to be
> completely random and happens more or less once per hour.
>
> Here is the gdb log/backtrace:
>
> Debug: [Main]: Load to player2: "/home/extra/Musik/cadenza/[cadenza 009]
> luciano & salif keita - salif keita remix/01 - Luciano & Salif Keita -
> Yamore (Luciano Remix).mp3"
> Debug: [Reader 2]: file length 65889792 i
> Debug: [AnalyserQueue 1]: AnalyserWaveform: f 44100 samplesPerDownsample:
> 110 downsamples 598998 from 65889792
> Debug: [Main]: Received waveform from track
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb1ae1b70 (LWP 5545)]
> 0xb68a0c1c in ?? () from /lib/i686/cmov/libc.so.6
> (gdb) bt
> #0 0xb68a0c1c in ?? () from /lib/i686/cmov/libc.so.6
> #1 0xb68a317e in malloc () from /lib/i686/cmov/libc.so.6
> #2 0xb6c0fe1d in qMalloc(unsigned int) () from /usr/lib/libQtCore.so.4
> #3 0xb6c5bcd9 in QString::realloc(int) () from /usr/lib/libQtCore.so.4
> #4 0xb6e7ee7e in ?? () from /usr/lib/libQtScript.so.4
> #5 0xb6e81856 in ?? () from /usr/lib/libQtScript.so.4
> #6 0xb6e772ca in ?? () from /usr/lib/libQtScript.so.4
> #7 0xb6e81856 in ?? () from /usr/lib/libQtScript.so.4
> #8 0xb6e968cb in ?? () from /usr/lib/libQtScript.so.4
> #9 0xb6ed1e67 in QScriptValue::call(QScriptValue const&,
> QList<QScriptValue> const&) () from /usr/lib/libQtScript.so.4
> #10 0x081cbe2d in ?? ()
> #11 0x081cbfa9 in ?? ()
> #12 0x080e3112 in ?? ()
> #13 0x081d3240 in ?? ()
> #14 0xb6c155e2 in ?? () from /usr/lib/libQtCore.so.4
> #15 0xb6ab4585 in start_thread () from /lib/i686/cmov/libpthread.so.0
> #16 0xb69022be in clone () from /lib/i686/cmov/libc.so.6
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/mixxx/+bug/493793/+subscribe
>

[Wesley Werner (wesley-werner)]

Hi again. Okay here is the output for gdb mixxx, I did notice that dbg didn't find any symbols. I'll happily do this with symbols, I'm not sure what that involves though; Just compiling Mixxx myself with debug options, and running that through gdb?

[Albert Santoni (gamegod)]

Hi Wesley,

Thanks for the more detailed backtrace. If you compile Mixxx from
scratch, debugging symbols will be enabled by default.

At the bottom of your output, GDB reported this:
---Type <return> to continue, or q <return> to quit---

Unfortunately, it only showed a backtrace for our first 3 threads -
GDB wanted you to hit enter a few more times to scroll the terminal
and show you the rest of the backtrace. This is an easy mistake to
make. :) Do you think you can try to reproduce the crash one more time
and grab the rest of gdb's output?

You've been a great help so far, it's very much appreciated.

Thanks,
Albert

On Thu, Dec 10, 2009 at 9:28 AM, Wesley Werner <email address hidden> wrote:
> Hi again. Okay here is the output for gdb mixxx, I did notice that dbg
> didn't find any symbols. I'll happily do this with symbols, I'm not sure
> what that involves though; Just compiling Mixxx myself with debug
> options, and running that through gdb?
>
> ** Attachment added: "gdb_output.txt"
>   http://launchpadlibrarian.net/36664119/gdb_output.txt
>
> --
> Random crash with 1.7.1
> https://bugs.launchpad.net/bugs/493793
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Wesley Werner (wesley-werner)]

Ah silly me, first time using gdb ;)

Okay I got all the deps sorted, compiled, and did a bt with the symbols loaded.

I'll create some sound files and see if one will recreate this behavior, but time is against me until the weekend. I'm playing a live set with Mixxx tomorrow night, actually (I will avoid the faulty song for now, no problem).

Thanks for the work BTW, much appreciated!

[gimmeapill (gimmeapill)]

Yay! Got another one after almost 4 hours!
I copied the full gdb session + backtrace this time, I hope this will be enough...

[Albert Santoni (gamegod)]

Looks like you've identified a race condition in our script engine.
We'll definitely have to take a look at this and see if we can track
it down. Big help guys, thanks!

Albert

On Thu, Dec 10, 2009 at 2:13 PM, gimmeapill <email address hidden> wrote:
> Yay! Got another one after almost 4 hours!
> I copied the full gdb session + backtrace this time, I hope this will be enough...
>
> ** Attachment added: "gdb log"
>   http://launchpadlibrarian.net/36671049/gdb_mixxx_long.txt
>
> --
> Random crash with 1.7.1
> https://bugs.launchpad.net/bugs/493793
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Albert Santoni (gamegod)]

Hey gimmeapill, in Mixxx's preferences, you can disable the BPM detection. Can you try doing that and seeing if you get any crashes?

Because Mixxx is crashing inside a new/malloc, it's possible there's some sort of subtle memory corruption going on. If that's the case, then oddball bits of code like the BPM detector could be stepping on the script engine's memory. (Make sure you test under gdb again, just in case.)

Another test you can do is switching from pitch-independent time stretch to vinyl emulation mode or vice versa. Please test with the BPM detection turned off before you try this though...

Thanks,
Albert

[gimmeapill (gimmeapill)]

Hi Albert,
I never use BPM detection or pitch-independant timestrech. Actually my library has not even been scanned by the BPM detector. But I don't think the problem comes from here as I've just run a full night gdb session on another computer with the same library playing in loop, but without the Hercules RMX and it didn't crash.
So I'll run another one today with the RMX connected and the pitch-independant timestrech see what happens..

[Albert Santoni (gamegod)]

For reference, Msieur Piero on the forums has a backtrace that's very similar to gimmeapill's backtrace (crash in memory allocation from QScriptValue::call()), and he's also using the Hercules RMX:

http://mixxx.org/forums/viewtopic.php?f=3&t=967&st=0&sk=t&sd=a

[Albert Santoni (gamegod)]

Ok, someone humour me. I spotted a bit of code in the Hercules RMX script that might be "stressing" the script engine in some way.

Crack open your Hercules-DJ-Console-RMX-scripts.js in your Mixxx/midi folder and edit lines 33 and 34, and change:

 33 engine.connectControl("[Channel1]","playposition","HerculesRMX.wheelDecay");
 34 engine.connectControl("[Channel2]","playposition","HerculesRMX.wheelDecay");

to:

 33 //engine.connectControl("[Channel1]","playposition","HerculesRMX.wheelDecay");
 34 //engine.connectControl("[Channel2]","playposition","HerculesRMX.wheelDecay");

In other words, just commenting them out. The wheelDecay() function in the script uses the Date class in a way that the Stanton SCS.3d script doesn't (Hercules-DJ-Console-RMX-scripts.js line 41). By commenting out the above connectControl() calls, we should prevent the wheelDecay() function from ever being called. (I'll save my vague speculation as to how this could be causing a problem for later.)

Let's see if commenting out those lines makes a difference gimmeapill, using your original configuration. I'd appreciate it if anyone else using a Hercules RMX could test it as well.

Thanks for your help,
Albert

[Msieur Piero (pierre-blanco)]

I tried to uncomment the lignes 33 and 34 in your script...
It causes me two surprises, one good, one bad:
- First one : the jogwel was still working (not the scratch mode and the librairies search mode, but the beatmatching still work),
- Second one : the mixxxing time increase a bit, but still kills himself after 1H30 (I gain 30mn...)

here's the backtrace, if it can helps :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb13d7b90 (LWP 5088)]
0xb6961a44 in ?? () from /lib/tls/i686/cmov/libc.so.6
(gdb) thread apply all bt

Thread 16 (Thread 0xadc22b90 (LWP 5093)):
#0 0xb7f93430 in __kernel_vsyscall ()
#1 0xb69c9ae7 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb6b9c2fb in ?? () from /usr/lib/libportaudio.so.2
#3 0xb6ba1124 in ?? () from /usr/lib/libportaudio.so.2
#4 0xb6b7e4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#5 0xb69d449e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 15 (Thread 0xae423b90 (LWP 5091)):
#0 0xb7f93430 in __kernel_vsyscall ()
#1 0xb6b820e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7c049b2 in QWaitCondition::wait (this=0xce5ea30, mutex=0xce5ea38, time=4294967295) at thread/qwaitcondition_unix.cpp:87
#3 0x081c1755 in ?? ()
#4 0xb7c0396e in QThreadPrivate::start (arg=0xce5e9b8) at thread/qthread_unix.cpp:189
#5 0xb6b7e4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb69d449e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 14 (Thread 0xafffeb90 (LWP 5090)):
#0 0xb7f93430 in __kernel_vsyscall ()
#1 0xb6b820e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb7c049b2 in QWaitCondition::wait (this=0xcf7ab40, mutex=0xcf7ab48, time=4294967295) at thread/qwaitcondition_unix.cpp:87
#3 0x081c1755 in ?? ()
#4 0xb7c0396e in QThreadPrivate::start (arg=0xcf7aac8) at thread/qthread_unix.cpp:189
#5 0xb6b7e4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb69d449e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 13 (Thread 0xb1bd8b90 (LWP 5089)):
#0 0xb7f93430 in __kernel_vsyscall ()
#1 0xb69c9ae7 in poll () from /lib/tls/i686/cmov/libc.so.6
#2 0xb66ed74b in g_poll () from /usr/lib/libglib-2.0.so.0
#3 0xb66dff82 in ?? () from /usr/lib/libglib-2.0.so.0
#4 0xb66e0268 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#5 0xb7d23438 in QEventDispatcherGlib::processEvents (this=0xd068c00, flags={i = -1312980376}) at kernel/qeventdispatcher_glib.cpp:323
#6 0xb7cf606a in QEventLoop::processEvents (this=0xb1bd82e0, flags={i = -1312980312}) at kernel/qeventloop.cpp:149
#7 0xb7cf64aa in QEventLoop::exec (this=0xb1bd82e0, flags={i = -1312980248}) at kernel/qeventloop.cpp:200
#8 0xb7c00639 in QThread::exec (this=0xb0a19008) at thread/qthread.cpp:481
#9 0x081d1a31 in ?? ()
#10 0xb7c0396e in QThreadPrivate::start (arg=0xb0a19008) at thread/qthread_unix.cpp:189
#11 0xb6b7e4ff in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#12 0xb69d449e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 12 (Thread 0xb13d7b90 (LWP 5088)):
#0 0xb6961a44 in ?? () from /lib/tls/i686/cmo...

[Albert Santoni (gamegod)]

Hi Msieur Piero (and gimmeapill),

Thanks for testing that for me. Today, three of us put our heads together and fixed some small logic errors in our analyser code. I think there's a decent chance this may have fixed your problem.

As soon as you can, can you please check out our latest 1.7 branch code (it includes the bug fixes) and test once again:
  bzr co lp:mixxx/1.7 mixxx_170
  cd mixxx_170
  scons
  ./mixxx

You can uncomment those two lines in the Hercules again, since I don't think they caused the problem.

Thank you very much!
Albert

[gimmeapill (gimmeapill)]

Hi Albert,
I just gave it a try and the latest fixes seem to have caused a huge performance hit.
While I could run smoothly at 12ms with 1.7.1, the latest bzr is barely usable: sound is choppy even at 64ms, and the waveform dsiplay stutters as well. I verified by re-compiling 1.7.1 with the same settings (sudo scons tuned=1 install).
As for the crash it didn't happen again so far. Msieur Piero, can you confirm?

[Adam Davison (adamdavison)]

Hi,

Albert is this your power-of-two buffer size patch in action? Can't
believe that analyser change would have caused a performance hit...

Adam

2009/12/23 gimmeapill <email address hidden>:
> Hi Albert,
> I just gave it a try and the latest fixes seem to have caused a huge performance hit.
> While I could run smoothly at 12ms with 1.7.1, the latest bzr is barely usable: sound is choppy even at 64ms, and the waveform dsiplay stutters as well. I verified by re-compiling 1.7.1 with the same settings (sudo scons tuned=1 install).
> As for the crash it didn't happen again so far. Msieur Piero, can you confirm?
>
> --
> Script Engine Crash
> https://bugs.launchpad.net/bugs/493793
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Msieur Piero (pierre-blanco)]

I've tried several times to type :
bzr co lp/mixxx/1.7 mixxx_170

but the recording always fails at 500 or 600/2589...
Do I forget something important?

I'm quite a noob with the bzr stuff, I know...

[Albert Santoni (gamegod)]

gimmeapill: I've just committed even more new code to rework the latency calculation. Please try again and see if you have any performance problems. (Make sure you have optimizations turned on!) :)

Msieur Piero: Make sure there is a ":" and not a "/" after "lp". The command should be:

   bzr co lp:mixxx/1.7 mixxx_170

It's possible that our Bzr hosting on Launchpad was down yesterday. Please try again!

Thanks again guys,
Albert

[gimmeapill (gimmeapill)]

Hi Albert,

With the latest fixes, performance is back to an OK level (23ms without glitches) although there's still a sensible performance gap compared to the Debian package (http://packages.debian.org/unstable/sound/mixxx).
I still cannot explain why there should be a performance difference, but the Debian binaries run definitely smoother on my system than the ones I produce, (even with optimizations turned on and a stripped binary). It is especially visible with the waveform display. This is anyway unrelated to the script engine bug.

As for the segfault problem, it doesn't seem to happen so far, but I would need a bit more testing, as this is quite random.

Msieur Piero:
here's the short script I use, if that can be of any help (this requires that you are ini the sudoers/wheel group):

#!/bin/sh

# delete the build folder
sudo rm -r 1.7

# get the latest bzr
bzr checkout lp:mixxx/1.7 1.7

# Rename the old binary
sudo mv /usr/local/bin/mixxx /usr/local/bin/mixxx-`date +%Y%m%d%H%M`

# compile & install
sudo scons tuned=1 install

[Msieur Piero (pierre-blanco)]

Sorry for my late answering... My in-laws broadcast was such a mess so I couldn't download the whole bzr stuff...
But...
A fiew asks are still there.
- Do I have to uninstall mixxx 1.7.1 BEFORE using scons or do I have to scons on the existing install?
- I have nothing under usr/local/bin/mixxx
- When I use scons into ./mixxx_170 It shows scons:
*** No SConstruct file found.
File "/usr/lib/scons/SCons/Script/Main.py", line 830, in _main

Into /home/pierre/mixxx_170/mixxx/ scons tuned=1 install shows :
pierre@pierre-laptop:~/mixxx_170/mixxx$ scons tuned=1 install
scons: Reading SConscript files ...
Platform: Linux i686
WE ARE IN: /home/pierre/mixxx_170/mixxx/src
QT path: /usr/share/qt4
Loading qt4 tool...
Exception: Qt4 command 'moc' not found. Tried: /usr/share/qt4/bin/moc-qt4 and /usr/share/qt4/bin/moc:
  File "/home/pierre/mixxx_170/mixxx/SConstruct", line 42:
    SConscript(File('src/SConscript'), build_dir=Dir(build_dir), duplicate=0)
  File "/usr/lib/scons/SCons/Script/SConscript.py", line 612:
    return apply(method, args, kw)
  File "/usr/lib/scons/SCons/Script/SConscript.py", line 549:
    return apply(_SConscript, [self.fs,] + files, subst_kw)
  File "/usr/lib/scons/SCons/Script/SConscript.py", line 259:
    exec _file_ in call_stack[-1].globals
  File "/home/pierre/mixxx_170/mixxx/src/SConscript", line 172:
    env = Environment(tools=['default','qt4'], toolpath=['#build/'], QTDIR=flags_qtdir, ENV = os.environ)
  File "/usr/lib/scons/SCons/Environment.py", line 992:
    apply_tools(self, tools, toolpath)
  File "/usr/lib/scons/SCons/Environment.py", line 106:
    env.Tool(tool)
  File "/usr/lib/scons/SCons/Environment.py", line 1676:
    tool(self)
  File "/usr/lib/scons/SCons/Tool/__init__.py", line 181:
    apply(self.generate, ( env, ) + args, kw)
  File "/home/pierre/mixxx_170/mixxx/build/qt4.py", line 251:
    QT4_MOC = locateQt4Command(env,'moc', env['QTDIR']),
  File "/home/pierre/mixxx_170/mixxx/build/qt4.py", line 234:
    raise Exception("Qt4 command '" + command + "' not found. Tried: " + fullpath1 + " and "+ fullpath2)

Does everything seems alright?

[gimmeapill (gimmeapill)]

Hi Msieur Piero,

Do I have to uninstall mixxx 1.7.1 BEFORE using scons or do I have to scons on the existing install?
-> if you mean the ubuntu package, then yes. The one you compile will go by default under /usr/local/bin so this is not 100% mandatory but otherwise you might run the wrong binary.

- I have nothing under usr/local/bin/mixxx
-> you need root privileges to run the install command, so you must "su" first or run "sudo scons tuned=1 install"

- When I use scons into ./mixxx_170 It shows scons:....
-> I'm not too sure, but I would say you miss some build dependencies (like libqt4-dev)
Be sure to check the build instructions in the wiki: http://mixxx.org/wiki/doku.php/compiling_on_linux

if everything goes fine, you will end up with the Mixxx binary under /usr/local/bin, and the rest under /usr/local/share/mixxx.

[Msieur Piero (pierre-blanco)]

I got a slight problem with the libqt4-dev dependancies...
I'm gonna check it first, and after, i'll check the scons...

[RJ Skerry-Ryan (rryan)]

- When I use scons into ./mixxx_170 It shows scons:
*** No SConstruct file found.
File "/usr/lib/scons/SCons/Script/Main.py", line 830, in _main
--------

You need to use the scons command in ./mixxx_170/mixxx/, not ./mixxx_170 :)

-RJ Ryan

[Msieur Piero (pierre-blanco)]

Ok...
Everything went well... I succed in building mixxx from source (libqt4-dev was such a nightmare to install, but I went through it).
To apologize, I must say it was the first "big software" I built (I used scons for little stuff like taputape, or some other tiny soft).

I begin to test it yesterday (i've not so much time), but, with the little i mixxxed, i would say that it looks like the improvements you made seems to work.

I'm gonna test it deeper tonight.

Thanks everybody.

Keep in touch!

[RJ Skerry-Ryan (rryan)]

Not sure why this was marked milestone 1.8.0. Ideally this was fixed in 1.7.2. Msiuer Piero, gimmeapill: can you confirm that the problem is resolved? You can download 1.7.2 from our website now.

[gimmeapill (gimmeapill)]

Hi Rj, yes, this is correct.
I've been running 1.7.2 since it came out, but I didn't run it for long enough to be sure the crash condition is gone
(Mixxx needs to run at least for 1-2 hours while being actively used).
This is why I didn't update the bug report yet but it does look better.
I'll run some long sessions this week end.

[gimmeapill (gimmeapill)]

Hi Rj, Albert,

The crash condition is still not fixed with 1.7.2.
Performance improved but Mixxx still segfaults after about 1 hour of playing actively with the RMX.
I'll try to generate another gdb trace ASAP...

[Sean M. Pappalardo (pegasus-renegadetech)]

$10 says that the threading issue I fixed in the features_scriptTimers branch is to blame for this as well. Shall I back-port?

[gimmeapill (gimmeapill)]

That would be sweet :-)
But maybe to save you some time I should rather try directly your branch? is it usable/stable enough?

[Sean M. Pappalardo (pegasus-renegadetech)]

It is. Please try it and let me know.

[gimmeapill (gimmeapill)]

OK, after a few hours playing with your branch, the crash iself seems to be gone but new problems appeared (I guess they're related to 1.8 as trunk behaves more or less the same): lights not working anymore after a while, midi controls acting weirdly, small audio glitches when loading a track. Since this renders things hard to compare, would it be possible for to backport your fixes to the 1.7 branch?

[Sean M. Pappalardo (pegasus-renegadetech)]

It's possible to back-port, but might take more time than just waiting for 1.8 to include this (which may not happen until 1.8.1, depends on what the head devs say.)
The rest of those issues are related to using 1.8 over 1.7 except the lights-not-working one. Does that sound like this bug? https://bugs.launchpad.net/mixxx/+bug/410750 Like does the controller stop working altogether or just the lights?

[Sean M. Pappalardo (pegasus-renegadetech)]

Marking in-progress until a decision is made on merging features_scriptTimers or porting the fixes to trunk.

[gimmeapill (gimmeapill)]

By the way, the latest 1.7.x is way more stable now.
It still crashes, but only after about 2.5 hours of playing (it used to be roughly every hour), so the latest fixes definitely helpded...

[Sean M. Pappalardo (pegasus-renegadetech)]

features_scriptTimers has been merged to trunk. Marking fixed.

[Swiftb0y (swiftb0y)]

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