Bug 2325 - StatusWidget causes frysk to hang on garbage collection in FC5 - gc deadlock
Summary: StatusWidget causes frysk to hang on garbage collection in FC5 - gc deadlock
Status: NEW
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
: 2304 (view as bug list)
Depends on: 2304
Blocks: 1839 1664 2288
  Show dependency tree / graph
 
Reported: 2006-02-10 20:37 UTC by Adam Jocksch
Modified: 2008-10-21 21:39 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Jocksch 2006-02-10 20:37:59 UTC 
1) Run frysk
2) Do enough stuff so that java starts a GC (i.e. rapidly scrolling source window)
3) Frysk hangs
Comment 1 Andrew Cagney 2006-02-10 20:44:06 UTC 
The StatusWidget creates an extra thread vis:

Thread 5 (Thread -1210287184 (LWP 8867)):
#0  0x00c6e402 in ?? ()
#1  0x005127a6 in ?? () from /lib/libpthread.so.0
#2  0x02745213 in _Jv_CondWait (cv=0x304bc00, mu=0x304bc20, millis=0x0,
    nanos=0x0) at ../../../libjava/posix-threads.cc:166
#3  0x02722d81 in gnu::gcj::runtime::FinalizerThread::run (this=0x4c348)
    at ../../../libjava/gnu/gcj/runtime/natFinalizerThread.cc:57
#4  0x02733209 in _Jv_ThreadRun (thread=0x4c348)
    at ../../../libjava/java/lang/natThread.cc:296
(More stack frames follow...)

Thread 4 (Thread -1220777040 (LWP 8868)):
#0  0x00c6e402 in ?? ()
#1  0x00407a5c in *__GI___poll (fds=0x46bff4, nfds=0x7, timeout=0xffffffff)
    at ../sysdeps/unix/sysv/linux/poll.c:86
#2  0x002e744c in g_main_context_check () from /usr/lib/frysk/libglib-2.0.so.0
#3  0x002e7957 in g_main_loop_run () from /usr/lib/frysk/libglib-2.0.so.0
#4  0x008043de in link_thread_io_context () from /usr/lib/libORBit-2.so.0
(More stack frames follow...)

Thread 3 (Thread -1221313616 (LWP 8869)):
#0  0x00c6e402 in ?? ()
---Type <return> to continue, or q <return> to quit---
#1  0x00407a5c in *__GI___poll (fds=0x46bff4, nfds=0x0, timeout=0x10b8)
    at ../sysdeps/unix/sysv/linux/poll.c:86
#2  0x080fbb8d in ?? ()
#3  0x080f6f4f in ?? ()
#4  0x080f7193 in ?? ()
(More stack frames follow...)

Thread 2 (Thread -1232794704 (LWP 8870)):
#0  0x00cfd567 in timer_helper_thread (arg=0x0)
    at ../nptl/sysdeps/unix/sysv/linux/timer_routines.c:74
#1  0x00510b80 in start_thread (arg=0xb6850bb0) at pthread_create.c:261
#2  0x004119ce in ?? () from /lib/libc.so.6

Thread 1 (Thread -1208162624 (LWP 8866)):
#0  0x00c6e402 in ?? ()
#1  0x00407a5c in *__GI___poll (fds=0x46bff4, nfds=0x5, timeout=0xffffffff)
    at ../sysdeps/unix/sysv/linux/poll.c:86
#2  0x002e744c in g_main_context_check () from /usr/lib/frysk/libglib-2.0.so.0
#3  0x002e7957 in g_main_loop_run () from /usr/lib/frysk/libglib-2.0.so.0
#4  0x00a24fc1 in gtk_main () from /usr/lib/frysk/libgtk-x11-2.0.so.0
(More stack frames follow...)

suspect it is causing a garbage collect hang.
Comment 2 Andrew Cagney 2006-02-10 22:28:49 UTC 
adam and I examing strace shows the sequence:

- successfull garbage collect
...

- creation of real-time timer manager thread (I'm guessing that is what it is) 
- timer_create
- creation of short-lived timer expired thread; then exit
- repeat; in some cases several exist in parallel; but all appear to exit

then

- garbage collect sigpwr signals

things hang; suggests bug is bad interaction with the timer event and the
garbage collector.
Comment 3 Andrew Cagney 2006-02-22 17:24:08 UTC 
Upstream fedora tracker:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=180637
Comment 4 Andrew Cagney 2006-05-12 17:10:33 UTC 
*** Bug 2304 has been marked as a duplicate of this bug. ***