Crash double-clicking any knob in debug build (git master)

[davidgerard]

Git master, running on Xubuntu 14.04 amd64.

To reproduce: double-click on any volume knob. Note that you can still change volume by clicking and dragging on the knob. It happens with both continuous knobs and discrete knobs (e.g. in many effects).

Crash running debug build in gdb is completely consistent, happens every time:

ASSERT: "!this->isEmpty()" in file /usr/include/qt4/QtCore/qstack.h, line 68

Program received signal SIGABRT, Aborted.
0x00007ffff410df79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Top of stack trace:
#0 0x00007ffff410df79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff4111388 in __GI_abort () at abort.c:89
#2 0x00007ffff684fc92 in qt_message_output(QtMsgType, char const*) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#3 0x00007ffff684fff9 in ?? () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#4 0x00007ffff6850804 in qFatal(char const*, ...) () from /usr/lib/x86_64-linux-gnu/libQtCore.so.4
#5 0x0000000000529db9 in pop (this=0x9fc02d0) at /usr/include/qt4/QtCore/qstack.h:68
#6 restoreJournallingState (this=) at /home/fun/lmms-git/include/JournallingObject.h:53
#7 knob::mouseReleaseEvent (this=0xa494b80, event=) at /home/fun/lmms-git/src/gui/widgets/knob.cpp:595
#8 0x00007ffff712250a in QWidget::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4

[diizy]

Can't reproduce...

[davidgerard]

I've just tried a completely clean build on a different computer (also Xubuntu 14.04 amd64) ... and the problem doesn't happen! So yeah, might just be me. I'll try a completely clean build on the original box at home later.

[davidgerard]

OK, this is weird - made a debug build (on this second machine), ran it in gdb, double-clicked on a knob and got a crash!

ASSERT: "!this->isEmpty()" in file /usr/include/qt4/QtCore/qstack.h, line 68

Program received signal SIGABRT, Aborted.
0x00007ffff4149f79 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.

Debug build also crashes when not run in gdb.

Next, I deleted CMakeCache.txt and did a normal (non-debug) build. And ... the bug doesn't manifest!

So why would a debug build (running standalone or in gdb) show the bug when a non-debug build doesn't??

I'll try again at home ...

[davidgerard]

I tried again at home - yep, this happens in debug build (run in gdb and not run in gdb) but doesn't happen in a non-debug build. (Both test PCs are Xubuntu 14.04 amd64.)

This is not helpful in running debug builds to supply stack traces ...

What could be causing the crash in a debug build but not in a non-debug build? I thought debug builds just had symbol information, etc ... do they e.g. zero variables, add padding, etc?

[davidgerard]

(I've corrected the bug title.)

[davidgerard]

Still happening in today's git master, debug build (and not in normal build).

[krafczyk]

This happens in the stable-1.1 branch as well. The crash described above happens with a 'Debug' build, but not with the 'Release' build.

[Sti2nd]

So it is a bug in the debugger?

[davidgerard]

When a bug shows up in the debugger but not the normal build, it's usually something working by accident (e.g. getting away with a use-after-free), and the debugger showing it (e.g. zeroing something that just happened not to be zeroed in normal use). So it may be a bug waiting to bite.

(Have you ever looked at code and gone "How did that ever work??" :-) )

[krafczyk]

I found that sometimes, a mouseReleaseEvent is sent twice for a double click event depending on how quickly you release your mouse after the last click.

In the knob mouseReleaseEvent, there is a stack which is popped without checking the size of the stack.

In the Qt code, there is an assert to prevent this in debug mode, but in normal mode, it's allowed.

To fix, I added an 'isEmpty' method to the JournallingObject. I then check this method to make sure that the stack isn't empty before popping.

[krafczyk]

The fix mentioned above has been merged, and has solved this bug. Someone should close this issue.

[tresf]

Fixed per #1145.