Thing/Kobold crash with MAGIC.RAM, but not with the original MAGIC.RAM

[uweseimet]

Environment: Thing 1.29, Kobold 3.31, real TT or TT emulated with Hatari, 32 MB TT-RAM, 4 MB ST-RAM, MagiC snapshot 20250827-135900, but also with 20241003-101256.

Whenever I copy a file to drive C: or copy and rename a file on C:, Thing, when configured to use Kobold for copying, crashes with a bus error. The copy operation as such is always successful. My guess is that the crash occurs after the copy operation, when Thing refreshes the window for drive C:. When not using Kobold there is no crash.
With the last beta version I received from Andreas Kromke (February 2000) there is no crash.

Hatari says:

WARN : Bus Error writing at address $4, PC=$100ab56 addr_e3=100ab56 op_e3=5368
WARN : Bus Error writing at address $4, PC=$100b6bc addr_e3=100b6bc op_e3=5368

This is consistent with the address Templmon displays in MagiC when the crash occurs, see attached image.

[th-otto]

Does that also happen with Jinnee (when configured to use kobold)? Otherwise that sounds more like a bug in thing rather than in MagiC.

And is it possible to find out where that PC belongs to? Since we have sources for both Thing and MagiC, it should be possible to locate the actual function.

[uweseimet]

I don't have Jinnee (never used it), sorry. I have been using the combination of Thing and Kobold for ages, both with real hardware and with Hatari. Considering that the "original" MagiC does not have this problem, why should it be a Thing issue and not a MagiC issue?

Edit: The PC IMO belongs to MagiC, because it is close to the start of TT-RAM.

[th-otto]

Yes, seems like the function is

MagicMac/kernel/dos/magidos.s

Lines 4272 to 4282 in 8ac9ef7

	unlock_dd:
	subq.w #1,dd_refcnt(a0) ; alter Pfad
	bne.b unldd_ok ; noch nicht freigeben
	movem.l d0-d2/a0-a2,-(sp)
	move.l dd_dmd(a0),a2
	move.l d_xfs(a2),a2
	move.l xfs_freeDD(a2),a2
	jsr (a2) ; DD freigeben
	movem.l (sp)+,d0-d2/a0-a2
	unldd_ok:
	rts

Looks like is it was called with a NULL pointer in a0. Is it possible to get a backtrace from Hatari? I can also try to provide a text file with symbols for the kernel, if that helps.

[uweseimet]

I am not familiar with the Hatari debugger. Can you outline how to enter the debugger on a bus error and how to get a backtrace, please?

[th-otto]

Invocation is done with

$ hatari --debug --debug-except bus

It is possible that some others programs trigger a bus-error (eg. pure-c programs typically try to detect the SFP004 at $FFFFFA42), in that case you have to use c until you see the desktop.

Once you are in the desktop, enter the hatari debugger with the keyboard short again (typically that should be Alt-Pause).
Then you load the symbols file using

> symbols magic.sym <textstart>

Where textstart is the base address where magic.ram was loaded. Maybe you have to experiment a bit to get the correct value, but typically this should be near the start of TT-RAM. You should also turn profiling on: > profile on

Continue again, then do whatever it takes to trigger the bug. When a bus-error occurs, that should enter the debugger, which then hopefully prints a backtrace.

Attached is a current kernel and the symbol file.

magic.zip

[uweseimet]

Where textstart is the base address where magic.ram was loaded. Maybe you have to experiment a bit to get the correct value, but typically this should be near the start of TT-RAM.

Experiment?

[uweseimet]

SYS_MON says $01000030 is the right address. But Hatari does not show a backtrace but only:

> symbols /home/us/magic.sym $01000030
Reading 'nm' style ASCII symbols from '/home/us/magic.sym'...
Removed 113 symbols in same addresses as other symbols.
Skipping detailed duplicate symbols reporting when autoload is enabled.
Loaded 10127 symbols (8882 for code) from '/home/us/magic.sym'.
...
CPU profiling warning counts:
- Subroutine calls returned (at max) through 2 stack frames

CPU=$100ab64, VBL=7175, FrameCycles=218364, HBL=243, LineCycles=636, DSP=N/A
0100ab64 5368 0004                subq.w #$01,($0004,a0) == $00000004 [00e0] 0.00% (3291, 105312, 0, 0)

[th-otto]

Yes, sorry. I don't know how to get the basepage address of magic.ram in the debugger, hatari can only print the basepage of the active program (if that works at all in magic). You could try to do something like > disasm bot_vcle, which is a routine near the beginning:

MagicMac/kernel/bios/atari/magibios.s

Lines 608 to 614 in 8ac9ef7

	bot_vclear:
	move.l d0,(a0)+
	move.l d0,(a0)+
	move.l d0,(a0)+
	move.l d0,(a0)+
	cmpa.l a0,a1
	bhi.b bot_vclear

to check whether the address is correct.

I think an address of 0x01000100 should work (start of tt-ram, plus 256 bytes for the basepage). But maybe something has already been loaded before that address.

[uweseimet]

bot_vclear is at $010000b6 in my case. What does this mean for the base address?

[uweseimet]

Looks as if the base address is $01000000, because:

> symbols /home/us/magic.sym $01000000
Reading 'nm' style ASCII symbols from '/home/us/magic.sym'...
Removed 113 symbols in same addresses as other symbols.
Skipping detailed duplicate symbols reporting when autoload is enabled.
Loaded 10127 symbols (8882 for code) from '/home/us/magic.sym'.
> disasm bot_vcle
bot_vcle:
010000b6 20c0                     move.l d0,(a0)+ == $00000000 [602e0306]
010000b8 20c0                     move.l d0,(a0)+ == $00000000 [602e0306]
010000ba 20c0                     move.l d0,(a0)+ == $00000000 [602e0306]
010000bc 20c0                     move.l d0,(a0)+ == $00000000 [602e0306]
010000be b3c8                     cmpa.l a0,a1
010000c0 62f4                     bhi.b #$f4 == $010000b6 (T)
010000c2 42b8 098c                clr.l $0000098c.w [00000000]

But I don't get any backtrace.

[uweseimet]

Or is this the backtrace? I am not familiar with Hatari's output.

Bus error exception at 0x100ab64!
Finalizing costs for 2 non-returned functions:
- 1. 0x100ab64: D_Dsetpa +0xe48 (unlock_d +0x0)
- 2. 0x100c64c: dos_trap +0x5c (dt_go +0x6)

[th-otto]

Looks as if the base address is $01000000

Strange, but the disassembly is correct.

Or is this the backtrace? I am not familiar with Hatari's output.

Yes. The call is from D_Dsetpath. I will have a look.

[uweseimet]

An additional piece of information: The same crash happens when I start DISKUS, leave it (Ctrl-Q) without doing anything, and then start any other program. This is reproducable and a simpler scenario.