These are probably jit'd methods:

>   #17 0x3e3128 in ?? ()
>   #18 0x3e3128 in ?? ()
>   #19 0x3e3128 in ?? ()
>   #20 0x3e3128 in ?? ()
> 
>     [ thousands of identical stack frames omitted ]
> 
>   #8905 0x3e3128 in ?? ()
>   #8906 0x3e3128 in ?? ()
>   #8907 0x3e3128 in ?? ()
>   #8908 0x45e188 in ?? ()
>   #8909 0x59816e in ?? ()

You're probably running off the end of the stack because of recursive
calls---it looks like function 0x3e3128 is the culprit.  Cool thing is
that the object at the end of the stack is the thread context, so
that'll get trashed, followed by whatever else has been allocated
after that... all bets are off at this point.

I posted a GDB macro for groking numbers like '0x3e3128' and turning
them into "class.method(signature)" strings, check the mailing list
archives for it (or just mail me and I'll send it to you).

This is an known problem with Kaffe.  In the interpreter you can stick
sanity checks like the following in machine.c.  In the JIT'r, on the
other hand....

   /*
    * Assert we haven't fallen off the bottom of our stack ...
    */
   if (!(jthread_on_current_stack((&high) - 1024)))
   {
   	   printf("Thread %p is falling off the bottom of its stack [%p-%p] @~%p\n",
   		  CURRENTTHREAD(),
   		  jthread_current()->stackBase,
   		  jthread_current()->stackEnd, 
   		  (&high) - 1024);
   	   panic("Cannot handle such things.");
   }

-Pat