Bug 2976 - instantiating org.gnu.gnomevte.Terminal causes frysk to hang on exit
Summary: instantiating org.gnu.gnomevte.Terminal causes frysk to hang on exit
Status: NEW
Alias: None
Product: frysk
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on: 2940
Blocks: 3398
  Show dependency treegraph
 
Reported: 2006-07-28 21:31 UTC by Ivan P
Modified: 2006-11-28 16:46 UTC (History)
0 users

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan P 2006-07-28 21:31:34 UTC
When a org.gnu.gnomevte.Terminal connected to a pty is created anytime during
execution of frysk, frysk starts showing some bizarre behavior and hangs when
you try to shut it down. The backtrace of a hung frysk is:
Thread 4 (Thread -1210434656 (LWP 10530)):
#0  0x0081c402 in __kernel_vsyscall ()
#1  0x00cae216 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x04b0eddb in _Jv_CondWait () from /usr/lib/libgcj.so.7
#3  0x04af6f6d in gnu::gcj::runtime::FinalizerThread::run ()
#4  0x04b06e0b in _Jv_ThreadRun () from /usr/lib/libgcj.so.7
#5  0x04b0e880 in _Jv_ThreadRegister () from /usr/lib/libgcj.so.7
#6  0x050fbf24 in GC_start_routine () from /usr/lib/libgcj.so.7
#7  0x00cab3b6 in start_thread () from /lib/libpthread.so.0
#8  0x0090233e in clone () from /lib/libc.so.6
Thread 3 (Thread -1291535456 (LWP 10538)):
#0  0x0081c402 in __kernel_vsyscall ()
#1  0x00cb0b8b in __read_nocancel () from /lib/libpthread.so.0
#2  0x04afbf70 in gnu::java::nio::channels::FileChannelImpl::read ()
#3  0x04cfea72 in java::io::FileInputStream::read () from /usr/lib/libgcj.so.7
#4  0x083b1a23 in jline::Terminal::readCharacter ()
#5  0x083b0b21 in jline::PtyTerminal::readVirtualKey ()
#6  0x083ad1e7 in jline::ConsoleReader::readVirtualKey ()
#7  0x083ab9da in jline::ConsoleReader::readBinding ()
#8  0x083ab752 in jline::ConsoleReader::readLine ()
#9  0x083ab6c2 in jline::ConsoleReader::readLine ()
#10 0x080fbdd8 in frysk::vtecli::ConsoleWindow$reader::run ()
#11 0x04d0ea54 in java::lang::Thread::run () from /usr/lib/libgcj.so.7
#12 0x04b06e0b in _Jv_ThreadRun () from /usr/lib/libgcj.so.7
#13 0x04b0e880 in _Jv_ThreadRegister () from /usr/lib/libgcj.so.7
#14 0x050fbf24 in GC_start_routine () from /usr/lib/libgcj.so.7
#15 0x00cab3b6 in start_thread () from /lib/libpthread.so.0
#16 0x0090233e in clone () from /lib/libc.so.6
Thread 2 (Thread -1281045600 (LWP 10553)):
#0  0x0081c402 in __kernel_vsyscall ()
#1  0x00cae216 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x04b0eddb in _Jv_CondWait () from /usr/lib/libgcj.so.7
#3  0x04b02e8e in java::lang::Object::wait () from /usr/lib/libgcj.so.7
#4  0x04af2b33 in java::lang::Object::wait () from /usr/lib/libgcj.so.7
#5  0x0816095b in frysk::sys::Ptrace$PtraceThread::run ()
#6  0x04b06e0b in _Jv_ThreadRun () from /usr/lib/libgcj.so.7
#7  0x04b0e880 in _Jv_ThreadRegister () from /usr/lib/libgcj.so.7
#8  0x050fbf24 in GC_start_routine () from /usr/lib/libgcj.so.7
#9  0x00cab3b6 in start_thread () from /lib/libpthread.so.0
#10 0x0090233e in clone () from /lib/libc.so.6
Thread 1 (Thread -1208333760 (LWP 10529)):
#0  0x0081c402 in __kernel_vsyscall ()
#1  0x00cae216 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0x04b0e510 in _Jv_ThreadWait () from /usr/lib/libgcj.so.7
#3  0x04af7939 in gnu::java::lang::MainThread::call_main ()
#4  0x04b39b16 in gnu::java::lang::MainThread::run () from /usr/lib/libgcj.so.7
#5  0x04b06e0b in _Jv_ThreadRun () from /usr/lib/libgcj.so.7
#6  0x04ac9868 in _Jv_RunMain () from /usr/lib/libgcj.so.7
#7  0x04ac99a4 in _Jv_RunMain () from /usr/lib/libgcj.so.7
#8  0x04ac99eb in JvRunMain () from /usr/lib/libgcj.so.7
#9  0x080dd241 in main ()
Comment 1 Andrew Cagney 2006-07-28 21:45:45 UTC
From irc discussion with mjw: this is likely a garbage collect deadlock.
Comment 2 Ivan P 2006-07-31 16:35:26 UTC
The problem seems to be that vte issues waitpid signals, thus consuming signals
that frysk is expecting. To fix, vte should be changed to not use waitpid. On
the other hand, Frysk assumes that only it's own event loop is consuming
signals, which is also a problem.