my first suspicions when a debugger can't give a useful backtrace are stack corruption or a call down a bogus function pointer.
Unfortunately such problems can be a nightmare to debug, I have often resorted to debugging with printf statements in the past. Recently "reverse debugging" tools have appeared that in principle should be able to help with this sort of thing, but I haven't found any free ones for arm linux. On 13/01/2020 11:36, David Bremner wrote:
Dear Arm experts; Any help with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948789 would be appreciated. I can replicate the crash on harris, and cd $HOME/racket-7.5+dfsg1/build && \ gdb --args ./racketcgc -cu \ $HOME/racket-7.5+dfsg1/src/racket/src/compile-startup.rkt cstartup.inc \ cstartup.zo $HOME/racket-7.5+dfsg1/src/racket/src/startup.inc \ $HOME/racket-7.5+dfsg1/src/racket/src/schvers.h should get you to the segfault in gdb. The backtrace doesn't make much sense to me, lots of talk about <error reading variable: DWARF-2 expression error: Loop detected (257).> It's entirely possible racket is doing something odd with signals; I remember something like using SEGFAULTS in gc. d
