Grim Reaper displaying strange callstack

5 posts / 0 new

Last post

Sat, 2025-02-08 07:47

Colin Ward

Offline

Last seen: 5 days 12 hours ago

Joined: 2025-02-08 07:36

Grim Reaper displaying strange callstack

Hello everyone.

I am trying to debug a tricky crash that only happens on OS4 using both m68k and PPC builds of my app (the m68k version runs fine on OS3) but I'm having a hard time debugging it.

It's crashing in a call to IDOS->Read() and I don't know why, and when I look at the call stack in Grim Reaper, I get this:

Stack trace:
native kernel module kernel+0x00022f6c
native kernel module kernel+0x0000b774
native kernel module newlib.library.kmod+0x00002ef0
_start()+0x170 (section 1 @ 0x1AB4)
native kernel module dos.library.kmod+0x00024c18
native kernel module kernel+0x0003caf0
native kernel module kernel+0x0003cb70

This is clearly incorrect as it doesn't even mention any of my code, and it's definitely crashing when my code calls Read() because I have put calls to printf() before and after the Read() call. I have debug symbols (tried with -ggdb and -gstabs) but no luck. Does anyone have any ideas?

Sat, 2025-02-08 13:26

thomas

Offline

Last seen: 18 hours 1 min ago

Joined: 2011-05-16 14:23

Re: Grim Reaper displaying strange callstack

Where did you get IDOS from? Is it properly initialized?

Sat, 2025-02-08 13:53

OldFart

Offline

Last seen: 4 hours 1 min ago

Joined: 2010-11-30 14:09

Re: Grim Reaper displaying strange callstack

Hi,

There is a tool, an Arexx script, 'AddressToLine. rexx' that converts 0x1ab4 in
_start()+0x170 (section 1 @ 0x1AB4)
into a line of your code.
However, I do not know where to get it, but it's a script of a handfull of lines. Very usefull. Very handy.

Addition:
Ok, it's sunday morning and I located the 2 files consisting of this tool:
The DOS-script

; 
; Convert an address to a source line number
;
 
Set Address `C:RequestString "Convert an address to a source line number" "Enter the address of the offending program*nplease?*n*n*nIn the form of:*nMyMisbehavingFunction()+0x16C (section 1 @ 0xe18)*nyou need to enter here the value '0xe18'*nThen press the 'OK'-button"`
;C:Echo "=== $Address ==="
 
If WARN
Else
 Addr2Line -e Project.DEBUG --section=.text $Address
EndIf

This is a slightly modified version of the original, as it contains 'Project.DEBUG' as filename. In my development train all projects are first compiled to that name. For me it made life much easier, you know.

The Arexx-script:

/*
 * Copyright 2009 Chris Young <chris@unsatisfactorysoftware.co.uk>
 */
 
parse arg filename offset
 
address command 'SDK:gcc/bin/readelf -e' filename '>t:addr2line.tmp'
 
if open('tmp','t:addr2line.tmp','R') then do
	do until index(var," .text ") > 0
		if eof('tmp') then break
		var = readln('tmp')
	end
	dummy = close('tmp')
	address command 'delete t:addr2line.tmp'
end
 
textaddr = x2d(substr(var,42,8))
newoffset = d2x(textaddr + x2d(offset))
address command 'SDK:gcc/bin/addr2line -e' filename '0x' || newoffset

It clearly states that Chris Young is the original author of the tool.

Hope this was usefull.

OldFart

Sun, 2025-02-16 01:51

(Reply to #3) #4

Colin Ward

Offline

Last seen: 5 days 12 hours ago

Joined: 2025-02-08 07:36

Re: Grim Reaper displaying strange callstack

Thanks @OldFart, I've saved those scripts and will try them out!

@thomas, I use -D__USE_INLINE__ when compiling, for source compatibility with OS3, so handling of IDOS is automatic. But it's not the crash I'm concerned with here - it's the fact that I get a totally incorrect call stack. It should be something like:

dos.library's Read() // Crashes here
CExecute::launchCommand()
CExecute::execute()
StartServer()
main()

But as you can see from my original post, the callstack displayed is nothing like this.

I love my Sam460LE. I don't love my Vampire 4 SA.

Tue, 2025-02-18 01:53

(Reply to #4) #5

msteed

Offline

Last seen: 10 hours 17 min ago

Joined: 2022-01-18 08:34

Re: Grim Reaper displaying strange callstack

"-gstabs" should be enough to get the debug info into your executable. The 'addr2line' program and the scripts that use it aren't necessary when using an executable with debug info; they're for use when debugging a release version where the debug info has been stripped.

If the crash clobbers the stack, the stack trace will of course not be valid. To check this you can try adding a read from address zero somewhere prior to the crash, to cause a harmless DSI. If the stack trace looks okay at that point then everything is working properly, so the incorrect trace after the crash is likely due to a damaged stack. (If you've got Ranger, it can display a snapshot of the stack while the program is running as a further check.)

Search form

User login