From: Lasse L. <dab...@gm...> - 2006-07-25 15:22:44
|
ok i realized this happened only when switching between windows (sometimes, not always). its reproducable here. just start lmms, press the playbutton (don't know if its relevant), switch to the console output and wait some minutes (2-15 here) until its visible that it crashed. gdb> bt #0 0x00000028 in ?? () #1 0xb7a7aea1 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #2 0x080b32bb in mixer::nextAudioBuffer (this=0xb64612dc, t0=0x84a4ab0, t1=0x200) at mixer.moc:121 #3 0x0814af84 in mixer::renderNextBuffer (this=0x832ca20) at mixer.cpp:294 #4 0x0814b3bd in audioDevice::getNextBuffer (this=0x83dc7a0, _ab=0x83862c0) at audio_device.h:167 #5 0x0814c219 in audioALSA::run (this=0x83dc7a0) at audio_alsa.cpp:228 #6 0xb7a0c89c in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3 #7 0xb76b03a7 in start_thread () from /lib/libpthread.so.0 #8 0xb724760e in clone () from /lib/libc.so.6 i'm using Qt 3.3.6. |
From: Javier S. P. <ja...@te...> - 2006-07-26 21:33:46
Attachments:
mixer_signal.patch
|
Second try, looks like sourceforge's been down ----- Ok, this is no way reproducible. But I've found something about Qt3 internals. If you're using GCC 4, update from CVS and try it again. If your problem persists or not using GCC 4, I'd like you to apply this patch. The command is: patch -p0 < mixer_signal.patch in your cvs folder. Let me know if this has solved your problem. Bye. |
From: danny m. <khj...@ya...> - 2006-07-27 17:16:53
|
> - void setAudioBuffer( ..., const fpab_t _frames ); > + void setAudioBuffer( ..., int _frames ); Okay, what's up? I was able to find a posting from a couple of years ago that said that there was a problem with moc that would allow bogus overloading when using const with pass-by-value in slots. Is that what this is related to, or is it some sort of overflow problem that's resulting from using a short instead of an int? I guess my real question is should I avoid using pass-by-value consts in slots? I can't really think of a reason for doing it in the first place, but I have a habit of mindlessly copying examples, so is this some sort of subtle thing I should be on the look-out for? Danny __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Javier S. P. <ja...@te...> - 2006-07-28 01:23:33
|
En/na danny mcrae ha escrit: >> - void setAudioBuffer( ..., const fpab_t _frames ); >> + void setAudioBuffer( ..., int _frames ); > > Okay, what's up? It all depends on Lasse's answer. If this solves the problem, I'll explain it in more detail. Otherwise it won't matter. Don't worry about this (or take a look into the generated moc). Bye. |
From: Javier S. P. <ja...@te...> - 2006-07-27 18:11:58
Attachments:
mixer_signal.patch
|
Ok, this is no way reproducible. But I've found something about Qt3 internals. If you're using GCC 4, update from CVS and try it again. If your problem persists or not using GCC 4, I'd like you to apply this patch. The command is: patch -p0 < mixer_signal.patch in your cvs folder. Let me know if this has solved your problem. Bye. |
From: Lasse L. <dab...@gm...> - 2006-07-28 21:49:08
|
hi, sorry for didn't write earlier. unfortunately it seems that the patch has nothing changed for me. these are the reports for 0.2.0-cvs20060723 (with and without patch) and today's version (the patch is already committed in there, right?.. couldn't apply it). 0.2.0-cvs20060723 (without patch): [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1244578896 (LWP 8506)] Error while running hook_stop: Invalid type combination in ordering comparison. 0x00740000 in ?? () gdb> bt #0 0x00740000 in ?? () #1 0xb7a3eea1 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #2 0x080b3956 in mixer::nextAudioBuffer (this=0xb5d132cc, t0=0x85bcdd8, t1=0x200) at mixer.moc:121 #3 0x0814c69c in mixer::renderNextBuffer (this=0x832f758) at mixer.cpp:294 #4 0x0814cb08 in audioDevice::getNextBuffer (this=0x83df108, _ab=0x8388e40) at audio_device.h:167 #5 0x0814dc6b in audioALSA::run (this=0x83df108) at audio_alsa.cpp:228 #6 0xb79d089c in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3 #7 0xb73393a7 in start_thread () from /lib/libpthread.so.0 #8 0xb6fc460e in clone () from /lib/libc.so.6 gdb> 0.2.0-cvs20060723 (with patch applied): [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1244062800 (LWP 25727)] Error while running hook_stop: Invalid type combination in ordering comparison. 0x00000000 in ?? () gdb> bt #0 0x00000000 in ?? () #1 0xb7abcea1 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #2 0x080b3b56 in mixer::nextAudioBuffer (this=0xb5d912dc, t0=0x83548d8, t1=0x83548d8) at mixer.moc:121 #3 0x0814c6dc in mixer::renderNextBuffer (this=0x832f8d8) at mixer.cpp:294 #4 0x0814cb48 in audioDevice::getNextBuffer (this=0x83f08c8, _ab=0x8388da0) at audio_device.h:167 #5 0x0814dcab in audioALSA::run (this=0x83f08c8) at audio_alsa.cpp:228 #6 0xb7a4e89c in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3 #7 0xb73b73a7 in start_thread () from /lib/libpthread.so.0 #8 0xb704260e in clone () from /lib/libc.so.6 Today's CVS: [...] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1243927632 (LWP 10988)] Error while running hook_stop: Invalid type combination in ordering comparison. 0x00000000 in ?? () gdb> bt #0 0x00000000 in ?? () #1 0xb7addea1 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 #2 0x080b3b36 in mixer::nextAudioBuffer (this=0xb5db22dc, t0=0x84034b0, t1=0x84034b0) at mixer.moc:121 #3 0x0814c85c in mixer::renderNextBuffer (this=0x832f7a0) at mixer.cpp:294 #4 0x0814ccc8 in audioDevice::getNextBuffer (this=0x83eb1d8, _ab=0x83da920) at audio_device.h:167 #5 0x0814de2b in audioALSA::run (this=0x83eb1d8) at audio_alsa.cpp:228 #6 0xb7a6f89c in QThreadInstance::start () from /usr/qt/3/lib/libqt-mt.so.3 #7 0xb73d83a7 in start_thread () from /lib/libpthread.so.0 #8 0xb706360e in clone () from /lib/libc.so.6 gdb> Am Mittwoch, 26. Juli 2006 04:59 schrieb Javier Serrano Polo: > Ok, this is no way reproducible. But I've found something about Qt3 > internals. > If you're using GCC 4, update from CVS and try it again. > If your problem persists or not using GCC 4, I'd like you to apply this > patch. The command is: > > patch -p0 < mixer_signal.patch > > in your cvs folder. > Let me know if this has solved your problem. > > Bye. |
From: Javier S. P. <ja...@te...> - 2006-07-31 00:08:04
|
En/na Lasse Lindner ha escrit: > hi, > > sorry for didn't write earlier. > unfortunately it seems that the patch has nothing changed for me. > these are the reports for 0.2.0-cvs20060723 (with and without patch) and > today's version (the patch is already committed in there, right?.. couldn't > apply it). Oops! Looks like that patch's been committed. That wasn't my intention since it hasn't solved your problem but it makes no harm. I'll give some details about the patch (this is targeted at developers). Qt3 signaling handles simple types with value-based calls. Anything else uses pointer-based calls. Simple types include bool, int, double... but don't include short nor float. That doesn't mean one method is better than the other. Both of them should work. They simply work in a different way. > > Today's CVS: > [...] > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1243927632 (LWP 10988)] > Error while running hook_stop: > Invalid type combination in ordering comparison. > 0x00000000 in ?? () > gdb> bt > #0 0x00000000 in ?? () > #1 0xb7addea1 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3 > #2 0x080b3b36 in mixer::nextAudioBuffer (this=0xb5db22dc, t0=0x84034b0, > t1=0x84034b0) at mixer.moc:121 That's a scary backtrace. t1 is the number of frames per buffer and should be something like 0x200 (512). Lasse, your gdb is from 2005, isn't it? Do you get a segmentation fault when running lmms without gdb? Bye. |
From: Lasse L. <dab...@gm...> - 2006-08-02 21:11:26
|
Uhm, I'm using gdb 6.4. I don't know at which date it was released, but gdb -v gives "Copyright 2005 ..", yes. Should I upgrade to 6.5 (It's still marked as "testing" in the Gentoo distribution)? But, yes, lmms still crashes without running from gdb. Any ideas left what could I do or test? Am Montag, 31. Juli 2006 02:13 schrieb Javier Serrano Polo: > Lasse, your gdb is from 2005, isn't it? Do you get a segmentation fault > when running lmms without gdb? > > Bye. |
From: Javier S. P. <ja...@te...> - 2006-08-03 03:06:08
|
En/na Lasse Lindner ha escrit: > Uhm, I'm using gdb 6.4. I don't know at which date it was released, but gdb -v > gives "Copyright 2005 ..", yes. Should I upgrade to 6.5 (It's still marked > as "testing" in the Gentoo distribution)? No, just checking gdb is not the problem. > But, yes, lmms still crashes without running from gdb. > Any ideas left what could I do or test? Are you using alsa, 2 channels? Try configuring with CXXFLAGS="-g -O2" ./configure I assume you're using gcc 3.4 and that all your dependent libraries (especially qt) were compiled with this version. Bye. |
From: Lasse L. <dab...@gm...> - 2006-08-03 19:36:31
|
> Are you using alsa, 2 channels? yes. > I assume you're using gcc 3.4 and that all your dependent libraries > (especially qt) were compiled with this version. that's right. is gcc4 needed for lmms? > Try configuring with > CXXFLAGS="-g -O2" ./configure i'll do that at next. thanks, lasse |
From: Lasse L. <dab...@gm...> - 2006-08-04 08:57:07
|
yes, i have built the whole system new after upgrading to 3.4. I think otherwise I'd have generally problems with this systems, but unfortunately i get these behaviour only with lmms. I don't know what "-g O2" in CXXFLAGS means, but's still segfaulting. Am Donnerstag, 3. August 2006 23:48 schrieb Javier Serrano Polo: > As you may know, gcc 3.3 is binary incompatible with gcc 3.4. > Gentoo released qt 3.3.6 before the first gcc 3.4 ebuild. When you > upgraded gcc, you did emerge your whole system, didn't you? > > Bye. |
From: Javier S. P. <ja...@te...> - 2006-08-04 14:17:30
|
En/na Lasse Lindner ha escrit: > I don't know what "-g O2" in CXXFLAGS means, but's still segfaulting. These are standard flags (debug info + optimization). Configuring this way you don't use any extra flags. Have you tried the instructions in: http://wiki.mindrules.net/doku.php?id=documentation:installation#installing_lmms_on_gentoo_linux ? Bye. |
From: Javier S. P. <ja...@te...> - 2006-08-03 22:49:50
|
En/na Lasse Lindner ha escrit: >> I assume you're using gcc 3.4 and that all your dependent libraries >> (especially qt) were compiled with this version. > that's right. is gcc4 needed for lmms? I don't think so. But Gentoo people have to be careful with the toolchain. As you may know, gcc 3.3 is binary incompatible with gcc 3.4. Gentoo released qt 3.3.6 before the first gcc 3.4 ebuild. When you upgraded gcc, you did emerge your whole system, didn't you? Bye. |