Click Here
home features news forums classifieds faqs links search
6101 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)



Lost Password?

Don't have an account yet?
Register now!

Your support is needed and is appreciated as is primarily dependent upon the support of its users.

Main sections
OS4 Zone
IRC Network
AmigaWorld Radio
Top Members
Amiga Dealers
About Us
Terms of Service

IRC Channel
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
43 crawler(s) on-line.
 23 guest(s) on-line.
 2 member(s) on-line.

 V8,  geen_naam

You are an anonymous user.
Register Now!
 V8:  15 secs ago
 geen_naam:  1 min ago
 Hammer:  7 mins ago
 Rob:  14 mins ago
 SOFISTISOFTWARE:  15 mins ago
 pixie:  20 mins ago
 t0lkien:  35 mins ago
 Karlos:  44 mins ago
 amigakit:  46 mins ago
 Maijestro:  1 hr 33 mins ago


Main »» OS4 Screenshots

More official AmigaOS4 screenshots from Hyperion (17-Aug-2003)  Popular
(Read 69417 times)
These shots demonstrate the debugging capabilities under AmigaOS 4. Two programs are involved in this: The Grim Reaper and gdb. The Grim Reaper is the replacement of the old-style Guru requester (or the WarpOS crash window under WarpUp). It is automatically started whenever a program crashes. gdb is the GNU debugger, possibly the most powerful open-source debugger available.

Click on thumbnails for larger view.

Shot 1: 'lawbreakersg' is a small program that simply does an illegal access, similar to the old 'lawbreaker'. The result of this is the "Grim Reaper" window. This tab (the "general" page) shows all general crash-related info that could be collected, like the registers, crash location, exception type, and which module the crash location belongs to (if the crash happened in a shared library, this would be listed under "module" in the crash location section).
Shot 2: The button "Write Crash Log" dumps the relevant information to a file. This is the editor displaying this file. It can be mailed to the developer for improved bug reports. As you can see, it also includes a stack trace (see also shot 3) with function names and offset within the function, as well as listing the section within the ELF file and offset).
Shot 3: The Grim Reaper can also show the stack trace in the GUI. The top line displays the location of the crash itself, which happened in the function func3. Note that all of these addresses are internal for the lawbreakersg program; external references, for example from a library, would be prefixed with the executable/module name. This makes it easier to track the error. However, local references are abreviated like this to make the output more readable.
Shot 4: This is Thomas demonstrating gdb. Thomas had been hard at work to complete GDB support, and the result is that we can now debug OS 4 native programs on a source code level. This demonstration shows how gdb intercepts a crash in the 'lawbreakersg'.
Shot 5: Thomas' gdb port also has the ability to attach to a running task, at any time, even after a crash. When a program crashed, the Grim Reaper offers the possibility to attach gdb to the crashed program. The result is the same as if you would have loaded it under gdb's control. Gdb's attaching feature also works if the process is running normally, in which case the program is frozen and put under debugger control. You can now start to examine (and change) variables, single step, continue and even detach gdb again (and, of course, reattach later).

(Note: Shots four and five show the command-line interface of GDB. There might be a GUI for this later).

View comments / Post a comment - MikeB
[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 was originally founded by David Doyle