I think we may have found our problem. See Mr. Hansen's reply below. The only thing I'm wondering is if the ControlObject signals are emitted in a different thread than anything MidiObject instantiates? If so, would adding a mutex to MidiScriptEngine::execute take care of this?
(Someone needs to explain to me when to use a static/const mutex vs a regular one, too.) Sean "D.J. Pegasus" -------- Original Message -------- Subject: Re: [Qt-interest] QtScript segfault on C++ signal (dis)connection/firing Date: Wed, 14 Jan 2009 17:44:42 +0100 From: Kent Hansen <[email protected]> Hi Sean, Any chance that the same script engine is being accessed from multiple threads? QtScript is not thread-safe, so be sure that there's only a single thread evaluating code (unless you've explicitly added a synchronization mechanism), and make sure that all connections are queued. If QtScript intercepts a signal and starts to handle it, and then another thread starts evaluating a script while this is going on, one likely result is that the QtScript call stack will get corrupted, which the backtrace seems to indicate. Regards, Kent Sean M. Pappalardo wrote: > Hello again. > > Just wondering if you've been able to find anything out? This issue is > quite literally a show-stopper, considering this is a DJ app. :) > > After a bunch more testing, the crashing doesn't happen if I don't > connect any of the C++ signals. I can call MidiScriptEngine::setValue() > all day from the script with no problems. It's crashing when signals are > connected and setValue() is called many times in a row, affecting > objects that emit signals. And it's worse on faster systems (more > setValue()s per second, I assume.) The signals only fire once per > latency period though. I did also find that increasing the latency alot > (400ms or more) makes it less likely to happen, depending on processor > speed. > > I ran valgrind with Mixxx compiled against Qt 4.5 which seems to give > more detail in the QtScript area, incase it helps: > > =20125== Process terminating with default action of signal 11 (SIGSEGV) > ==20125== Access not within mapped region at address 0x8 > ==20125== at 0x530F078: > QScriptContextPrivate::execute(QScript::Code*) (qscriptcontext_p.cpp:2020) > ==20125== by 0x5320B15: > QScript::ScriptFunction::execute(QScriptContextPrivate*) > (qscriptcontext_p.cpp:313) > ==20125== by 0x5335B7A: QScriptEnginePrivate::call(QScriptValueImpl > const&, QScriptValueImpl const&, QList<QScriptValueImpl> const&, bool) > (qscriptengine_p.cpp:1252) > ==20125== by 0x5371496: QScriptValue::call(QScriptValue const&, > QList<QScriptValue> const&) (qscriptvalueimpl_p.h:719) > ==20125== by 0x80FA4C1: MidiObject::receive(MidiCategory, char, char, > char, QString) (midiobject.cpp:273) > ==20125== by 0x81BA89F: MidiObjectALSASeq::run() > (midiobjectalsaseq.cpp:286) > ==20125== by 0x502861D: QThreadPrivate::start(void*) > (qthread_unix.cpp:184) > ==20125== by 0x42CB4BF: start_thread (in > /lib/i686/cmov/libpthread-2.7.so) > ==20125== by 0x55B461D: clone (in /lib/i686/cmov/libc-2.7.so) > > Thanks again for your time. Let me know your thoughts and if there's > anything else I can do to help. > > Sincerely, > Sean M. Pappalardo <<--------------------------------------------------------------------------------->> This E-Mail message has been scanned for viruses and cleared by >>SmartMail<< from Smarter Technology, Inc. <<--------------------------------------------------------------------------------->> ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
