[kaffe] -O4 jit3 problem

[Patrick Tullmann]

I wrote:
> (*) InternHog seems to fail in the (non-optimized) interp-debug builds
> now.  Of course, I can't get it to fail when run under GDB... Bah!
> I'll keep poking at that one.

This is very bizarre.

As far as I can tell, it only happens in interp+debug (static or not),
with the patch I just posted to fix the VmException stuff.  It only
happens when I run the test with the obj-tree BUILD-ENVIRONMENT, and
not if I used the installed version of build.  Once I found the right
conditions, the segv hits every time.  Trying to duplicate the bug
with a smaller test case, or in other builds always failed for me,
though....

Kaffe seg-faults in string.c:stringCompare, when its passed the
strings "1812" and "/tmp".  Interestingly, those have the same
hashcode.  The backtrace is:
    #0  0x081113de in stringCompare (v1=0x83df800, v2=0x834a878) at ...kaffe/kaffevm/string.c:428
    #1  0x0813c761 in hashFindSlot (tab=0x832c1c0, ptr=0x83df800) at ...kaffe/kaffevm/hashtab.c:189
    #2  0x0813c562 in hashRemove (tab=0x832c1c0, ptr=0x83df800) at ...kaffe/kaffevm/hashtab.c:133
    #3  0x0811122d in stringUninternString (string=0x83df800) at ...kaffe/kaffevm/string.c:352
    #4  0x08111655 in stringDestroy (collector=0x8215460, obj=0x83df800) at ...kaffe/kaffevm/string.c:539
    #5  0x080fa325 in finishGC (gcif=0x8215460) at ...kaffe/kaffevm/mem/gc-incremental.c:707
    #6  0x080f9b6d in gcMan (arg=0x8215460) at ...kaffe/kaffevm/mem/gc-incremental.c:527
    #7  0x08113547 in startSpecialThread (arg=0x8335c20) at ...kaffe/kaffevm/thread.c:273

Here are the strings:
(gdb) p* s1
$1 = {base = {dtable = 0x82e9c60, lock = 0x0}, value = 0x83defb0, offset = 0, count = 4, interned = 1 '\001', 
  hash = 1515144}
(gdb) p* s2
$2 = {base = {dtable = 0x82e9c60, lock = 0x0}, value = 0x8346f18, offset = 0, count = 4, interned = 1 '\001', 
  hash = 1515144}

They're both intern'd strings.  s1 is the string being destroyed by the GC.

The SEGV occurs on the first dereference of the zero'th byte of one of
the strings.  (My x86 assembly isn't very keen, here's a chunk of the
disassembly.)

...
0x81113d6 <stringCompare+230>:  jmp    0x8111400 <stringCompare+272>
0x81113d8 <stringCompare+232>:  mov    0xfffffff0(%ebp),%eax
0x81113db <stringCompare+235>:  mov    0xffffffec(%ebp),%edx
0x81113de <stringCompare+238>:  movzwl (%eax),%eax
0x81113e1 <stringCompare+241>:  cmp    (%edx),%ax
0x81113e4 <stringCompare+244>:  je     0x81113f0 <stringCompare+256>
0x81113e6 <stringCompare+246>:  mov    $0x1,%eax
0x81113eb <stringCompare+251>:  jmp    0x8111404 <stringCompare+276>
...

eip is on the movzwl instruction.  eax is 0x83defbc.  ebp is valid.

I can see no reason why the given instruction would seg fault.  The
only thing I could think of is that jchar's are 16-bit, and there's
some sort of alignment problem, but the x86 doesn't have any alignment
constraints AFAIK.  GDB can print the contents of each string, and
both look fully functional.

The main thread kicked the gc from a gcAlloc() request for a String
object (that's all InternHog does is allocate a *lot* of Strings).
Nothing too funny looking in its back trace.a

I tried re-writing the body of stringCompare to see if it was some
sort of odd GCC bug, but nothing helped.

Adding code to check if the two arguments to stringCompare were
intern'd, and then seeing if they're == or not fixes the problem
because it avoids the dereference of the string contents....  Adding
printfs to the code indicates that this is the *only* time that two
intern'd strings are passed to stringCompare.  I can't see any reason
why intern'd strings would cause a seg-fault, though.

I guess I'm curious if anyone else can reproduce this problem, and if
anyone else has any ideas as to what might be going wrong.  (Or can
justify the fix from the previous paragraph.)

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
                   All your base are belong to us.