Hi Nick,
I haven't got a real solid way the reproduce: I just start the program and
use it very aggressively (transformer scratch, stuff like that)... usually
within 10 minutes to half an hour it crashes.
Inspecting the relevant routine, newValue is a double I cannot imagine
anything being wrong with that (if it was a pointer I can imagine the
possibility for error there). It seems strange that it crashes wanting to
display it, so perhaps the problem is somewhere else.
Looking at the loggings generated to standard-out, it sometimes seems like
the 'receive( )' routine gets called simultaneously which can happen as it's
called from a thread, if I understand matters correctly.
Debug: [MidiObject 1]: value coming out ComputeValue: "127"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x14" , val: "0x00"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x14" , val: "0x01"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x11" , val: "0x7E"
Debug: [MidiObject 1]: value coming out ComputeValue: "126"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x14" , val: "0x02"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x11" , val: "0x7D"
Debug: [MidiObject 1]: value coming out ComputeValue: "125"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x11" , val: "0x7C"
Debug: [MidiObject 1]: value coming out ComputeValue: "124"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x14" , val: "0x03"
Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01"
, ctrl: "0x11" , val: "0x7B"
Debug: [MidiObject 1]: value coming out ComputeValue: "123"
Note the 3 lines "MidiObject::receive()" lines , sometimes 2, sometimes 1
between the "value coming out ComputeValue" lines... So I'm wondering, could
it perhaps be a re-entrancy issue?
2009/3/16 Nick Guenther <[email protected]>
> I haven't seen this crash at all but I've been getting very good at
> hunting down segfaults in Mixxx's code. Judging from the line it
> segfaults on the this pointer is probably invalid, which likely means
> some buffer is being allocated too large in some method of the class
> and thus smashing the stack. Do you have a way to reproduce it so I
> can help you
>
> 2009/3/16 Navaho Gunleg <[email protected]>:
> > 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
> >
> >
>
--
"The pioneers of a warless world are the young men (and women) who refuse
military service"
- Albert Einstein
------------------------------------------------------------------------------
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
