DDT crash

Hi,

When trying to run Greg’s game in DDT, DDT repeatedly crashes.

The game is “unusual” in that it has no areas or literal pools, it makes use of big data tables and large amounts of zero-initialised storage (the code and initial data is around 32K, the zero-init stuff brings this up to ~700K). It also reads and writes to what might conceptually be considered the same chunk. I’m starting with a 4MiB WimpSlot.
Perhaps not “good” in DDE style, but it’s no reason for the debugger to roll over and play dead quite so easily.

This is copied from the other post, in case it isn’t seen in that forum:

This crash is absolutely repeatable.

Error / address exception / data abort in debugger
Registers:
R0  = 000000FF  R1  = 5EF08E5B  R2  = 5EF08E67  R3  = 000000FC
R4  = 5EF08D5F  R5  = 00000002  R6  = 5EF08D67  R7  = 2036A11C
R8  = 00000001  R9  = 00015AF9  R10 = 20363318  R11 = 203691A4
R12 = 00000020  R13 = 20369178  R14 = 2036CEA8  R15 = 2036CEB4
Backtrace:
Anonymous function
Anonymous function
Anonymous function
Please record the above and report it to Acorn
Press any key to continue

Given the propensity for DDT to fall over, could we at least have a build with embedded function names so you guys have something to go on?

DDE version 26.

Upon returning to the Desktop, I got an error message telling me the crash was at &20378AD8 (which doesn’t feature at all in the above debug info!), which is in the DDT module.

So…

*MemoryI 20378AA0
20378AA0 : DDT  : 20544444 : SUBCSS  R4,R4,R4,ASR #8
20378AA4 : work : 6B726F77 : BLVS    &22014888
20378AA8 : spac : 63617073 : Undefined instruction
20378AAC : e... : 00000065 : ANDEQ   R0,R0,R5,RRX
20378AB0 : .... : 00000000 : ANDEQ   R0,R0,R0
20378AB4 : .... : 00000000 : ANDEQ   R0,R0,R0
20378AB8 : .... : 00000000 : ANDEQ   R0,R0,R0
20378ABC : ì".å : E51F22EC : LDR     R2,&203787D8
20378AC0 : .À á : E1A0C00E : MOV     R12,R14
20378AC4 : ..Rã : E3520000 : CMP     R2,#0
20378AC8 : ø".. : 050F22F8 : STREQ   R2,&203787D8
20378ACC : .... : 0A000005 : BEQ     &20378AE8
20378AD0 : .0‹å : E5923000 : LDR     R3,[R2,#0]
20378AD4 : ..Rã : E3520301 : CMP     R2,#&04000000
20378AD8 < .. 3 : 33A00007 : MOVCC   R0,#7
20378ADC : ...? : 3F00001E : SWICC   OS_Module
20378AE0 : .  á : E1A02003 : MOV     R2,R3
20378AE4 : öÿÿê : EAFFFFF6 : B       &20378AC4
20378AE8 : .. ã : E3A00001 : MOV     R0,#1
20378AEC : …..å : E51F128C : LDR     R1,&20378868
20378AF0 : ..1ã : E3310000 : TEQ     R1,#0
20378AF4 : f... : 1F000066 : SWINE   OS_DynamicArea
20378AF8 : .. ã : E3A00000 : MOV     R0,#0
20378AFC : †..å : E50F029C : STR     R0,&20378868
*ShowRegs
Register dump (stored at &20009E10) is:
R0  = 00000000 R1  = 00408000 R2  = FFFFFFFF R3  = FFFFFFFF
R4  = 20000000 R5  = 20369EF8 R6  = 2036DC28 R7  = 2036DC34
R8  = 00000001 R9  = 00015AF9 R10 = FA200200 R11 = 00000000
R12 = 2036CC1C R13 = FA208000 R14 = 2036CC1C R15 = 20378AD8
Mode SVC32 flags set: NzCvqjggggeAIft        PSR = A0000193

And…the failure point register dump is almost entirely different. What does the DDT dump show? Either way, it’s an LDR from a bogus address – neither &5EF08E67 nor &FFFFFFFF are valid addresses.

Running with a 40MiB slot and a 64MiB Next gives exactly the same result, only a few of the addresses (mostly the ones in RMA 203xxxxx) are slightly different.