Opened 8 years ago
Closed 8 years ago
#12913 closed bug (fixed)
Debugger crashes on Step into
Reported by: | KapiX | Owned by: | anevilyak |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications/Debugger | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
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.
Attachments (1)
Change History (6)
by , 8 years ago
Attachment: | Debugger-18570-debug-13-08-2016-13-53-22.report added |
---|
comment:1 by , 8 years ago
comment:2 by , 8 years ago
There is no recipe yet, I am working on one.
Steps:
- Needed libs: boehm_gc, libatomic_ops, libffi, libgmp.
- 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
- Build will crash. Go to build directory and run
Debugger ecl_min compile
. - Set breakpoint in
si_infinity()
, then inecl_make_long_float
set breakpoint onx = ecl_alloc_object(t_longfloat);
. (Both functions are in src/c/number.d. - Run (you can't step over due to #12914 - it will crash on
DO_DETECT_FPE();
). - Step into.
- 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.
comment:3 by , 8 years ago
Status: | new → in-progress |
---|
comment:4 by , 8 years ago
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!
comment:5 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
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.