segfault

Bug #443426 reported by Kamil Páral
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lrcShow-X
Confirmed
Medium
lrcShow-X team

Bug Description

$ ./lrcShow-X.py
Player 'amarok' is not running.
Player 'audacious' is not running.
exaile instance has no attribute 'version'
Player 'qmmp' is not running.
Player 'quodlibet' is not running.
Player 'vlc' is not running.
Player 'juk' is not running.
QThread: Destroyed while thread is still running
Segmentation fault
$

Happens very often when starting (50%).

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

This also happens to me sometimes, I'm already looking for a solution, but for now there's nothing else to do than simply try to restart the program.
I'm sorry.
You were using Rhythmbox right?

I'll continue in finding a solution to this bug, and hope to solve it quickly.

Changed in lrcshow-x:
importance: Undecided → Medium
assignee: nobody → lrcShow-X team (lrcshow-x)
status: New → Confirmed
Revision history for this message
Kamil Páral (kamil.paral) wrote :

Yes, rhythmbox. I believe it's some kind of a threading issue. I have dual core pc and it really happens to me extremely often.

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

It is possible, I also have an Intel core 2 duo and now running Ubuntu.
I think that the only way to find the real problem is trying to debug the entire application (for example with WinPDB) and hope to reproduce the bug. Once found the problem we could try to find a solution.
Unfortunately debugging the entire application repeatedly needs a lot of time, and sincerely I'm quite busy with University and work. I hope in the next days to have the time to work seriously on this issue, just wait for a next release or for a svn/bzr update.

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

I found some news: segmentation fault should be caused by imported modules written in c.
Now, I don't know exactly which of the modules that we use can cause the seg fault.
It depends on the architecture (mine is amd_64), on the distro (mine is 9.04), and so on.
Anyway I'll be very glad to solve this bug, but I cannot reproduce it by myself when I want to debug it.
So it's a big problem, and I really don't know what to do.

Revision history for this message
frank (xujia19) wrote :

I want to know this happens only with rhy or others? At least I never saw it before, with juk, amarok2, qmmp, audacious.

I run my gentoo box on x86_64 arch.

Revision history for this message
Kamil Páral (kamil.paral) wrote :

I have no idea how to help you, because I am a Python beginner. I believe it's cause by incorrect use of threads in QT because of this message:
QThread: Destroyed while thread is still running
But that's just a guess.

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

I've just found this: http://wiki.python.org/moin/DebuggingWithGdb
you can try debugging python with gdb and post here the traceback (tb).

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

@frank: for me it happens also when using Amarok, but something like once over a hundred.

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

@Kamil: If you want, you coud also try pdb (should be already included in python).
Just (from a shell) type "pdb lrcShow-X.py" then "r" to run the appl. When it crashes, it should give you more information.

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

With gdb I just found this:
[New Thread 0x7f9f3ac82950 (LWP 25548)]
QThread: Destroyed while thread is still running

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f9f3ac82950 (LWP 25548)]
0x00007f9f4be40cb4 in QThreadData::get2 () from /usr/lib/libQtCore.so.4
(gdb) bt
#0 0x00007f9f4be40cb4 in QThreadData::get2 () from /usr/lib/libQtCore.so.4
#1 0x00007f9f4be43c9d in ?? () from /usr/lib/libQtCore.so.4
#2 0x00007f9f4d1fe3ba in start_thread () from /lib/libpthread.so.0
#3 0x00007f9f4c6c6fcd in clone () from /lib/libc.so.6
#4 0x0000000000000000 in ?? ()
(gdb)

Revision history for this message
Kamil Páral (kamil.paral) wrote :

$ pdb ./lrcShow-X.py
> /home/ripper/programy/lrcShow-X/lrcShow-X.py(28)<module>()
-> import os,sys,gettext,pickle,ConfigParser,commands
(Pdb) r
Error: lrcShow-X allows only one instance
--Return--
> /home/ripper/programy/lrcShow-X/lrcShow-X.py(102)<module>()->None
-> sys.exit()
(Pdb)

After I have modified the source code to disable the single instance check:

$ pdb ./lrcShow-X.py
> /home/ripper/programy/lrcShow-X/lrcShow-X.py(28)<module>()
-> import os,sys,gettext,pickle,ConfigParser,commands
(Pdb) r
Player 'amarok' is not running.
Player 'audacious' is not running.
exaile instance has no attribute 'version'
Player 'qmmp' is not running.
Player 'quodlibet' is not running.
Player 'vlc' is not running.
Player 'juk' is not running.
QThread: Destroyed while thread is still running
Segmentation fault
$

Maybe I am missing some debug libraries or something?

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

Yes, I think, but me too I've never debugged a python script with gdb/pdb before, so I'm trying to undertstand how it works.
I'm trying to install all py qt related dbg and/or dev packages.

Thank you for your time.
I hope that one of us will solve this bug.

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

Now found:
QThread: Destroyed while thread is still running

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f70392cd950 (LWP 1885)]
0x00007f704aca4651 in ?? () from /lib/libc.so.6
(gdb) backtrace
#0 0x00007f704aca4651 in ?? () from /lib/libc.so.6
#1 0x00007f704aca68f1 in ?? () from /lib/libc.so.6
#2 0x00007f704aca79bf in ?? () from /lib/libc.so.6
#3 0x00007f704aca8a74 in memalign () from /lib/libc.so.6
#4 0x00007f704aca8c78 in posix_memalign () from /lib/libc.so.6
#5 0x00007f7049890481 in slab_allocator_alloc_chunk (chunk_size=32)
    at /build/buildd/glib2.0-2.20.1/glib/gslice.c:1136
#6 0x00007f7049891d43 in IA__g_slice_alloc (mem_size=24)
    at /build/buildd/glib2.0-2.20.1/glib/gslice.c:666
#7 0x00007f70498722d6 in g_main_context_add_poll_unlocked (context=0x23311c0,
    priority=1056, fd=0x23bdaf0)
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c:2855
#8 0x00007f7049873da3 in IA__g_main_context_new ()
    at /build/buildd/glib2.0-2.20.1/glib/gmain.c:500
#9 0x00007f704a5a1ad9 in QEventDispatcherGlibPrivate::QEventDispatcherGlibPrivate () from /usr/lib/libQtCore.so.4
#10 0x00007f704a5a1c80 in QEventDispatcherGlib::QEventDispatcherGlib ()
   from /usr/lib/libQtCore.so.4
#11 0x00007f704a48eb3b in ?? () from /usr/lib/libQtCore.so.4
#12 0x00007f704a48ece2 in ?? () from /usr/lib/libQtCore.so.4
#13 0x00007f704b8493ba in start_thread () from /lib/libpthread.so.0
#14 0x00007f704ad11fcd in clone () from /lib/libc.so.6
#15 0x0000000000000000 in ?? ()

Revision history for this message
OutLikeAShoe (outlikeashoe) wrote :

I've committed a new release into the SVN, I'm almost sure that it will not solve the bug, but at least, trying to avoid shared object instances between different threads should make better the actual situation.

Revision history for this message
frank (xujia19) wrote :

I guess this problem is caused by the signal listening thread, since it is started in main window's construction method (__init__), it may be conflict with main window's construction.

I modified the code and ci to svn already. Now the thread would be started after constructing the window, I hope it would fix this problem.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.