On Tue, Mar 17, 2009 at 10:34 AM, Navaho Gunleg <[email protected]> wrote: > I couldn't get that re-entrancy thing out of my head so I spent some more > time tracing this problem. > > The qDebug( ) messages all go through the MessageHandler defined in main.cpp > -- one that attempts to update / or create a file mixxx.log. > > Now, for fun I put a new QMutex around the log-file access in the file > operations, played around a little and one thing I immediately noticed is a > more evenly distributed amount of "miditype" debug messages between the > ComputeValue messages scrolling passed: > > Debug: [MidiObject 1]: value coming out ComputeValue: "55" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x14" , val: "0x48" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x11" , val: "0x36" > Debug: [MidiObject 1]: value coming out ComputeValue: "54" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x14" , val: "0x49" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x11" , val: "0x37" > Debug: [MidiObject 1]: value coming out ComputeValue: "55" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x14" , val: "0x48" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x11" , val: "0x39" > Debug: [MidiObject 1]: value coming out ComputeValue: "57" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x14" , val: "0x46" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x11" , val: "0x3A" > Debug: [MidiObject 1]: value coming out ComputeValue: "58" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x14" , val: "0x45" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x11" , val: "0x3B" > Debug: [MidiObject 1]: value coming out ComputeValue: "59" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x14" , val: "0x44" > Debug: [MidiObject 1]: MidiObject::receive() miditype: "0xB0" ch: "0x01" > , ctrl: "0x11" , val: "0x3C" > Debug: [MidiObject 1]: value coming out ComputeValue: "60" > > It could of course be (very) coincidental but it seems to indicate that the > file-access may be the problem. I could run it for quite a while and it did > not crashed on me. Even more interestingly, it nicely closed when I chose > "Exit" -- it 'normally' segfaults then. Related? > > My 2nd run was ended because of another bug that seems to haunt me that I'm > trying to trace (at some point, Mixxx crawles to a halt, sound comes out all > stuttery, screen updates seem to 'crawl' behind (the crossfader still moving > from side-to-side after not touching controls anymore)). But I'm > digressing; that is another problem... > > Anyway, I'm gonna ride with this QMutex lock around the log-file access for > a while to see how that goes.. I shall probably do more test-runs later > today, I really should be working :) > > Keep you all posted.. >
Good work. If you can pinpoint this bug I'm sure we'll take your patch. -Nick ------------------------------------------------------------------------------ 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
