For what it's worth, I found this to be the line that causes the program
segfault:
249: qDebug() << "value coming out ComputeValue: " << newValue;
I was doing some experimenting last night and the last thing I tried was
this:
249: qDebug() << "value coming out ComputeValue: " <<
QString::number(newValue);
With this change I did notice that, in the console, the messages "value
coming out of ComputeValue: 0" .. I found that interesting, as I do not
recollect seeing messages with a value < 1 before there but my memory could
serve me bad there.
Sadly, it was no solution as the program still crashed at that same spot,
when very intensively using the M-Audio X-Session Pro MIDI controller's
crossfader.
I wonder if there is anyone else experiencing such crashes?
Cheers,
NG
2009/3/15 Navaho Gunleg <[email protected]>
> OK scratch that one (no pun intended)
>
> It seemed to go very well for a very long while but of course, the moment
> you send a patch thinking you fixed something, you get proven wrong :-)
>
> So there still seems to be some fishiness going on in the
> MidiObject::receive( ) call. Here is the backtrace:
>
> (gdb) backtrace
> #0 0xb6a32a28 in vfprintf () from /lib/tls/i686/cmov/libc.so.6
> #1 0xb6a377a0 in ?? () from /lib/tls/i686/cmov/libc.so.6
> #2 0xb6a32c6e in vfprintf () from /lib/tls/i686/cmov/libc.so.6
> #3 0xb6aeb2d7 in __fprintf_chk () from /lib/tls/i686/cmov/libc.so.6
> #4 0x080fdf50 in MessageHandler (type=QtDebugMsg, input=0xa95806c8
> "MidiObject::receive() miditype: \"0xB0\" ch: \"0x01\" , ctrl: \"0x11\"
> , val: \"0x03\" ")
> at /usr/include/bits/stdio2.h:99
> #5 0xb6e36735 in qt_message_output () from
> /usr/share/qt4/lib/libQtCore.so.4
> #6 0x081052fb in MidiObject::receive (this=0x8e59558, status=CTRL_CHANGE,
> channel=0 '\0', control=-12 '�, value=3 '\003', device=
> {static null = {<No data fields>}, static shared_null = {ref =
> {_q_value = 7538}, alloc = 0, size = 0, data = 0x83a37fa, clean = 0,
> simpletext = 0, righttoleft = 0, asciiCache = 0, capacity = 0, reserved = 0,
> array = {0}}, static shared_empty = {ref = {_q_value = 362}, alloc = 0, size
> = 0, data = 0xb70149ce, clean = 0, simpletext = 0, righttoleft = 0,
> asciiCache = 0, capacity = 0, reserved = 0, array = {0}}, d = 0xae2c9364,
> static codecForCStrings = 0x0}) at /usr/share/qt4/include/QtCore/qdebug.h:79
> #7 0x081c7dd1 in MidiObjectALSASeq::run (this=0x8e59558) at
> src/midiobjectalsaseq.cpp:300
> #8 0xb6e3e6ae in ?? () from /usr/share/qt4/lib/libQtCore.so.4
> #9 0xb7c6650f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
> #10 0xb6ad4a0e in clone () from /lib/tls/i686/cmov/libc.so.6
>
>
> Regards,
> NG
>
> 2009/3/15 Navaho Gunleg <[email protected]>
>
> I observed segmentation faults at 'random' moments while using the
>> crossfader a lot (X-Audio Session Pro) which I was able to traceback to
>> invalid data being passed a qDebug( ) in the MidiObject::receive( ) routine.
>>
>> Apparently, for some weird reason, newValue can be invalid -- causing a
>> crash.
>>
>> The qDebug( ) is now skipped if !newValue and also the call to
>> p->queueFromMidi( ) if this is the case, but I am unsure if that's really
>> OK.
>>
>> This seems to fix this segfault and, importantly, seems not to break any
>> other stuff (for me). :)
>>
>> Cheers,
>> NG
>>
>
>
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
