[kaffe] [Patch] Xdebugging with classes without SourceFile attribute

Tue Apr 5 03:50:37 PDT 2005

I've had problems doing xdebugging, gdb failing at startup. Here is one session:

sauternes /tmp/kaffe-utf8 KAFFE_DEBUG=gdb 
/usr/local/src/kaffe/install/bin/kaffe -Xxdebug -Xmx199m 
-Dnice.raw-traces=true -classpath classes nice.tools.testsuite.TestNice testsuite
GNU gdb 6.1-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library 
"/lib/libthread_db.so.1".

(gdb) source /usr/local/src/kaffe/kaffe/d
developers  docs
(gdb) source /usr/local/src/kaffe/kaffe/developers/gdbinit
(gdb) run
Starting program: /usr/local/src/kaffe/install/jre/bin/kaffe-bin -Xxdebug 
-Xmx199m -Dnice.raw-traces=true -classpath classes 
nice.tools.testsuite.TestNice testsuite
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 3806)]
[New Thread 32769 (LWP 3808)]
[New Thread 16386 (LWP 3809)]
[New Thread 32771 (LWP 3810)]
run test engine
   testsuite: testsuite/compiler/classes/typeParameters.testsuite

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3806)]
0x401d3c2f in strlen () from /lib/libc.so.6
(gdb) xdb
add symbol table from file "xdb.o" at
         .text_addr = 0x0
(gdb) bt
#0  0x401d3c2f in strlen () from /lib/libc.so.6
#1  0x4001afee in addDebugInfo (df=0x82630cc, tag=139047576)
     at ../../../kaffe/kaffe/xprof/debugFile.c:564
#2  0x400837de in installMethodCode (ignore=0x0, meth=0x85bc484,
     code=0xbfffeaa4) at ../../../../kaffe/kaffe/kaffevm/jit3/machine.c:748
#3  0x400771c7 in translate (xmeth=0x85bc484, einfo=0xbfffeb34)
     at ../../../../kaffe/kaffe/kaffevm/jit3/machine.c:381
#4  0x40086392 in soft_fixup_trampoline (_data=0x0) at methodcalls.c:54
#5  0x4008660e in i386_do_fixup_trampoline ()
     at ../../../../kaffe/config/i386/trampolines.S:41
#6  0x085c9269 in containsKey__Q34java4util7HashMapPQ34java4lang6Object ()
     at java/lang/System.java:198
#7  0x40086602 in engine_callMethod (call=0xbfffebcc) at sysdepCallMethod.h:46
#8  0x40054733 in KaffeVM_callMethodA (meth=0x85bc484, func=0x85c9264,
     obj=0x0, args=0x0, ret=0xbfffebcc, promoted=0)
     at ../../../kaffe/kaffe/kaffevm/support.c:507
#9  0x400549bf in KaffeVM_safeCallMethodA (meth=0x85bc484, func=0x85c9264,
     obj=0x0, args=0x0, ret=0x0, promoted=0)
     at ../../../kaffe/kaffe/kaffevm/support.c:531
#10 0x40038b4b in processClass (class=0x8589934, tostate=13, einfo=0xbfffed84)
     at ../../../kaffe/kaffe/kaffevm/classMethod.c:554
#11 0x400862e9 in soft_fixup_trampoline (_data=0x0) at methodcalls.c:47
#12 0x4008660e in i386_do_fixup_trampoline ()
     at ../../../../kaffe/config/i386/trampolines.S:41
#13 0x085c91a9 in containsKey__Q34java4util7HashMapPQ34java4lang6Object ()
     at java/lang/System.java:198
#14 0x085e9c0c in cl0x83099cc.gnu.mapping.ProcedureN._003cclinit_003e ()
     at nice/tools/testsuite/TestCase.java:328
#15 0x085a4af8 in cl0x83099cc.nice.tools.testsuite.TestCase.compilePackages (
     this=0x854b3dc) at nice/tools/testsuite/TestCase.java:296
#16 0x08596c41 in __Q34java2io21ByteArrayOutputStreami ()
     at nice/tools/testsuite/PassTestCase.java:45
#17 0x0857cd4a in cl0x83099cc.nice.tools.testsuite.TestSuite.performTests (
     this=0x83d7a3c) at nice/tools/testsuite/TestSuite.java:224
#18 0x085285d8 in java.io.File.toString ()
     at nice/tools/testsuite/TestSuite.java:85
#19 0x084f44a3 in __Q34java4util9ArrayListPQ34java4util10Collection ()
     at nice/tools/testsuite/TestNice.java:439
#20 0x084a3230 in 
main__Q511cl0x83099cc4nice5tools9testsuite8TestNicePt6JArray1ZPQ34java4lang6String 
(args=0x84c2358) at nice/tools/testsuite/TestNice.java:216
#21 0x40086602 in engine_callMethod (call=0xbfffefc0) at sysdepCallMethod.h:46
#22 0x40054b53 in KaffeVM_callMethodV (meth=0x84a2064, func=0x8492c84,
     obj=0x0, args=0xbffff200 "\001", ret=0xbffff028)
     at ../../../kaffe/kaffe/kaffevm/support.c:664
#23 0x40094b55 in KaffeJNI_CallStaticVoidMethodV (env=0x8265028,
     cls=0x849aab4, meth=0x84a2064, args=0xbffff1fc "X#L\b\001")
     at ../../../../kaffe/kaffe/kaffevm/jni/jni-callmethod.c:1736
#24 0x40094c71 in KaffeJNI_CallStaticVoidMethod (env=0x8265028, cls=0x849aab4,
     meth=0x84a2064)
     at ../../../../kaffe/kaffe/kaffevm/jni/jni-callmethod.c:1749
#25 0x080492d1 in main2 (env=0x0, argv=0xbffff8c4, farg=7, argc=1)
     at ../../../kaffe/kaffe/kaffe/main.c:311
#26 0x080490b7 in main (argc=2, argv=0xbffff8c4)
     at ../../../kaffe/kaffe/kaffe/main.c:222

Looking at the corresponding kaffe code, it looks like the case where some 
user classfiles do not have a SourceFile attribute might not be handled 
gracefully: in the gdb session, the offending class has a 0x0 sourcefile 
field. Attached is a small patch that prevents failure in this case.

Note that I could not reproduce this on a small testcase. For the real-world 
situation that provoked this, the segv disappears, but there seems to be a 
deadlock somewhere else, so I cannot this this is fully tested (I never saw 
"Unknown source file" printed, for instance). Still, the patch is very small, 
so if it looks OK please apply it, I think it can only help.

Cheers,

Daniel (yeah, my first non-library patch ;-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-sourcefile-attribute.diff
Type: text/x-patch
Size: 1283 bytes
Desc: not available
Url : http://kaffe.org/pipermail/kaffe/attachments/20050405/0656d4c7/attachment-0002.bin 