English Amiga Board

Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

Thread Tools
Old 14 April 2018, 11:34   #1
Posts: n/a
Debugging help


I am trying to port a simple 3d engine to the amiga (amiga OS 3 m68k + RTG). it is somewhat working but unfortunately it is crashing when closing the window and my knowledge about debugging is rather poor. Usually I am working quite high level. I have some (very basic) gdb knowledge and some assumptions (not knowledge ) about what is going on low level (stack pointer etc).

But generally speaking I am new to amiga coding in general and not really used to work low level so I am very likely missing some very obvious stuff and thought I might find some help here.

The engine I am trying to port is using C++ and so far targets Unix and Windows and I created some cmake cross compile setup around the C++ toolchain of bebbo. I have created the neccesary bits for window management and I am seeing stuff on the screen (hooray ).

Unfortunately when closing the window it crashes and I am trying to find out why.

Simple printf debugging so far yielded nothing useful (for my untrained eyes) and I couldn't get gdb running so far.

This was when I found winuae-enforcer from the thread here:


This seems to be what I need but I am not really able to put the picture together.

Here is a full enforcer output that I am getting after the crash:


I don't really get what it is trying to say.

This is what I made up in my mind (which is probably totally off):

I am seeing that the PC is somewhere inside Exec ($00f83584) and NOT in my code (cube).

As I don't have any experience with enforcer outputs I made a simple assembly test to see if it always looks like this:

move.w #$0,$AAAAAA00 ; just a random address

This created output that I expected. namely that it was failing in my program and NOT in exec.

So I am wondering what is going on.

The arrow lines list the stack and the addresses (do they?). So I would like to know what 07c28868 refers to in cube as that seemed to happen last (in my code). For that I thought I could use the addr2line utility. However that yields nothing (I compiled with -g -O0):

mop@franz-peter:~/projects/le3d-build$ /home/mop/m68k-amigaos/bin/m68k-amigaos-addr2line -f -e examples/cube 0x07c28868
I found some stack overflow posts but most of them refer to --section parameters which are not present in the m68k version. So again I am lost. I tried some other addresses randomly to see if it outputs anything at all but it always shows the output above. Does it even work? Am I missing something?

Within the original winuae-enforcer thread I also found the following note:


How can I do this? I read some documentation but apparently I don't get it :S
Old 14 April 2018, 12:08   #2

Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 454
You best bets atm are:

* use some debugger like barfly, dbug, ...
* share your project (e.g. via github), maybe someone will look into it
bebbo is offline  
Old 14 April 2018, 12:10   #3
Toni Wilen
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 45
Posts: 23,672
Something called exec/Alert() and possibly system was messed up enough to not be able to show guru. In other words there is no more information than: something went horribly wrong.

EDIT: most common is program overwriting exec base or exception vectors but winuaeenforcer should detect it unless you have JIT enabled.

This may also help if you use winuae. Or you can try using "real" enforcer + mmu emulation (use 68040, 68030 MMU emulation is quite slow), it may show more information.
Toni Wilen is offline  
Old 14 April 2018, 18:33   #4
Registered User

Join Date: Nov 2015
Location: Italy
Posts: 44
Originally Posted by mop View Post
unfortunately it is crashing when closing the window
Random wild guess: you are killing the window inside event loop (while msg = GetMsg ... if event A do this ... if event B close window ... if event C do that ... ReplyMsg). You can't GetMsg/ReplyMsg/WaitPort after window is closed.
aros-sg is offline  
Old 15 April 2018, 22:55   #5
Posts: n/a
thanks for the pointers. will do some investigation
Old 20 April 2018, 08:37   #6
Posts: n/a
The obvious thing I was missing was this:


For future reference:

first execute

stack 200000
then execute your program in the shell

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Debugging strategies pipper Coders. C/C++ 43 17 June 2018 20:02
3.6.0 Debugging Mode bloodline support.WinUAE 2 23 February 2018 19:52
Debugging? MartinW Coders. C/C++ 10 03 January 2018 20:59
Remote C/C++ debugging? alkis Coders. C/C++ 1 03 January 2014 12:17
Enforcer debugging tool M&F support.WinUAE 0 21 May 2002 22:53

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 17:00.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.06886 seconds with 13 queries