Debugger crashes on Step into

[KapiX]

hrev50467 gcc4h

Core file: ​http://haiku.kacperkasper.pl/core-Debugger-18771.7z

This happens when debugging Embeddable Common Lisp. I can provide specific steps to reproduce if necessary.

[anevilyak]

Is there a recipe available for ECL? From a quick look, what appears to be happening is that an executable image wasn't found corresponding to the top stack frame at the time the step was attempted, but that information would have been constructed elsewhere entirely. That means I'd need to be able to replicate this situation myself to analyze it a bit more closely, but at least from a quick look through haikuports, I'm not finding a recipe to do so with.

As such, steps to both build the interpreter and reproduce the crash would be appreciated.

[KapiX]

There is no recipe yet, I am working on one.

Steps:

1. Needed libs: boehm_gc, libatomic_ops, libffi, libgmp.
2. In source directory (I was using commit 0fbf2a4c44901fa818493a689fc4b601e096ef68):

   cd src
   libtoolize --force --copy --install
   autoreconf -fi
   cd ..
   ./configure --enable-threads=no --with-dffi=system --enable-boehm=system --with-asdf=no --with-tcp=no --with-ieee-fp=yes
   make
   

3. Build will crash. Go to build directory and run Debugger ecl_min compile.
4. Set breakpoint in si_infinity(), then in ecl_make_long_float set breakpoint on x = ecl_alloc_object(t_longfloat);. (Both functions are in src/c/number.d).
5. Run (you can't step over due to #12914 - it will crash on DO_DETECT_FPE();).
6. Step into.
7. Debugger crashes.

I think ECL uses some kind of intermediate compiler (note the .d extension) and this might be the problem, but Debugger definitely should not crash.

[anevilyak]

Crash fixed in hrev50487. However, it looks like you're going to have to go a little further down the rabbit hole on this one. In this particular instance, part of the reason for the failure is that EIP was at 0x1, which is obviously invalid. I suspect ecl is miscomputing where to {set,long}jmp somewhere along the way, but since it's also catching sigsegv, this doesn't actually lead to a direct crash, but rather an abort (as seen when running on console). However, the problem itself appears to be somewhere earlier on that front. Good luck!