RE: LuaJIT 2.0 beta 9 on PPC GCC 4.4.6 uClibc 0.9.29 mpc8248 PowerQuicc II processor

["Solinsky, Jeff - PAL" <Jeff.Solinsky@...>]

Pall, Mike Wrote:
> Solinsky, Jeff - PAL wrote:
> > It is crashing when main() returns, which I guess might mean
> > that there has been stack corruption?
> Umm, maybe. Or a special register (r2/r13) got corrupted?
> If it crashes for both a regular return from main() and for
> os.exit(), then this ought to be a problem in the process exit
> handling code in uClibc. Maybe set a breakpoint at the last
> instruction of main and step from then on. Not sure how much code
> follows.

Yes, it is dieing somewhere in uClibc code, if I call _exit(), no segfault.  I'm going to recompile uClibc with debugging symbols or put debug printf statements in the uClibc exit code to see where it is dying. Will report what I find. 

I did try using atexit at the start of luajit and registering an exit function, which was called correctly before the segfault upon exit, so it is likely either dying at the end of the cleanup functions or when it calls the uClibc internally registered cleanup functions.

> Another possibility is that the kernel somehow gets confused.
> Maybe due to the cache flush code, because this is only invoked
> when the JIT compiler actually compiled something. Do you see
> anything in dmesg?

That's an interesting though.  I don't see anything in dmesg though so, I am heavily leaning toward exit() in uClibc as the culprit.  

I noticed that the previous compiler I built for our system I used --disable-__cxa_atexit and I didn't use that when I built gcc 4.4.6.  That might have something to do with this also maybe, I may try rebuilding without that.  

On a somewhat unrelated and annoying note, my Linux virtual machine that I'm working in for all this just somehow got its root file system corrupted bad when I used VirtualBox suspend and resume, and I may be spending the next day or two trying to recover from this most recent failure. :(

~Jeff