Bug#275547: One error condition found
retitle 275547 String.intern() may deadlock or infiniteloop if interned Strings are GC'ed at a high rate
severity 275547 minor
thanks
On Sat, Oct 09, 2004 at 06:25:43PM +0200, Jeroen van Wolffelaar wrote:
> This is probably only one of multiple bugs, as this cannot possibly
> explain the deadlock that sometimes happens.
Okay, that one was reproducible by _not_ using a libgcj that wasn't optimized
nor had debugging symbols, if doing so, there is a real deadlock:
(gdb) where
#0 0xffffe410 in __kernel_vsyscall ()
#1 0x4080e64b in __lll_mutex_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0
#2 0x4080b8a5 in _L_mutex_lock_24 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0x00000000 in ?? ()
#4 0x00000000 in ?? ()
#5 0x00000000 in ?? ()
#6 0x00000000 in ?? ()
#7 0x407b9dd0 in ?? () from /usr/lib/libgcj.so.4
#8 0x080e2fd8 in ?? ()
#9 0x403b1129 in _Jv_MonitorEnter () from /usr/lib/libgcj.so.4
#10 0x4042a898 in gnu::gcj::runtime::FinalizerThread::finalizerReady () from /usr/lib/libgcj.so.4
#11 0x40562c90 in GC_notify_or_invoke_finalizers () from /usr/lib/libgcj.so.4
#12 0x4056523c in GC_generic_malloc () from /usr/lib/libgcj.so.4
#13 0x40565441 in GC_malloc_atomic () from /usr/lib/libgcj.so.4
#14 0x4038ce1e in _Jv_AllocPtrFreeObject () from /usr/lib/libgcj.so.4
#15 0x403b4510 in _Jv_AllocString () from /usr/lib/libgcj.so.4
#16 0x403b4552 in _Jv_NewString () from /usr/lib/libgcj.so.4
#17 0x403b3e4f in java::lang::String::intern () from /usr/lib/libgcj.so.4
#18 0x08048ae4 in Test.main(java.lang.String[]) (argv=0x8092fe0) at Test.java:7
#19 0x403a7d8b in gnu::gcj::runtime::FirstThread::call_main () from /usr/lib/libgcj.so.4
#20 0x4042aac8 in gnu::gcj::runtime::FirstThread::run () from /usr/lib/libgcj.so.4
#21 0x403b66bc in _Jv_ThreadRun () from /usr/lib/libgcj.so.4
#22 0x4038de3c in _Jv_RunMain () from /usr/lib/libgcj.so.4
#23 0x4038df69 in JvRunMain () from /usr/lib/libgcj.so.4
#24 0x08048a58 in main (argc=1, argv=0xbffff9b4) at /tmp/cc6jvCW3.i:11
(gdb)
I suspect this one is caused by GC interfering with the full or
nearly-full hashtable which at the same time was trying to add a string,
but I'm not sure.
Meanwhile it turned out that the original large program also accidently
suffered from interning strings at a high rate without keeping
references to them, so that they needed to be GC'd at a high rate.
Since I cannot think of a legitemate use of interning huge amounts of
strings without keeping references to them, downgraded to minor.
--Jeroen
--
Jeroen van Wolffelaar
jeroen@wolffelaar.nl
http://jeroen.A-Eskwadraat.nl
Reply to: