DDT 1.91

Trying to save the running image of an app (waiting till it decompressed the image), scrolling down get an:
Error / address exception / data abort in debugger
Registers:
……
Backtrace:
Please report the above and report it to Acorn
Press space …

I have some photos, who should I email them too? Is there a better way to save the workspace of a running app?

Abort on data transfer at 3826988.

I think you will need to specify the version of OS (inc date of build) you are running and the version of DDT before people can give a meaningful answer.

The version of DDT is 1.91, the os is 4.39 as the software is 26bit, and you can’t run DDT under aemulor.

Is there a better way to save the workspace of a running app?

Zap.

Iconbar menu – Create – Read memory…
Click it, don’t go on to the submenu. That works, but it is fiddly. Clicking the option gets the window onscreen without the menu behaviour.

Anyway. See the big green cog? Drag that to the iconbar icon of the task whose workspace you want to save. You’ll see the addresses and stuff change.
Then click on Read.

A Zap editor window will open with a snapshot of the entire WimpSlot for the task.

Ctrl-Shift-F5 to switch to disassembly.
Ctrl-Shift-F3 to switch to word mode.
Ctrl-Shift-F1 to switch to text dump mode (the default).

Looks like StrongEd can do it too.
Right click on iconbar – Dump – Application – [select from list]
Hmm, not much in the way of colourisation there.
Mode change buttons are on the top bar. The left arrow gives a sort of Edit-like display.

Anyway, if you just want to sniff the application’s workspace, forget about the Debugger. It is easier to use an editor.

If, on the other hand, you want to change data in the application space of a running application. Well, that’s a whole different matter!

Thanks Rick, that got me over the initial problem. – I had never noticed that feature of Zap.

I was just scrolling through the memory space of the app when the crash occurred. Does anyone have a later version of the DDT?

I was just scrolling through the memory space of the app when the crash occurred.

Yeah, it’s “fun” when the debugger is flakier than the program you’re trying to debug.

Does anyone have a later version of the DDT?

No. Just checked, the DDE26 ones is the same. 1.91, 25th March 2014. Ditto for the DDT module.

Referring to the original post, the message “Please record the above and report it to Acorn” is at offset +&2BA8 of the DDT module. This probably ought to say the ctools@ address nowadays. ;-)

While you are there, a couple of suggestions for improving DDT:

1, Backtrace to VDU? Seriously? It isn’t 1986 any longer. Can’t this be written to a file in Scrap or somesuch?

2, One of the most seriously annoying things about DDT, and the reason I try to avoid using it, is that after it crashes, you cannot perform any further debugging using it without resetting the machine. Any attempts to either start a new debug or RMKill the module result in the message “Debugging session already in progress”. Could somebody please either attach an atexit() handler to discard the current debugging session upon a crash or a longjmp() to recover and throw away enough environment to allow the module to shut itself down safely. It would be better to not leak memory, but if this is inadvoidable due to how the thing works, then let it leak. It’s better than being forced to reset the machine because of debugger inadequacies…

That is exactly what I was trying to find out, who maintains DDT.

With maybe the option to send them to a server, next time it’s run.