RAWBInfo crash after ACTION_INFO

[chris]

@chris

doslist = IDOS->AllocDosObjectTags(DOS_DOSLIST, ADO_Name, rarray[A_NAME], TAG_DONE);

Just wondering why you don't set ADO_Type here to DLT_VOLUME? Then you won't have to poke it into the structure later and if AllocDosObject() needs to do some specific initialisation for DLT_VOLUME then it will be able to do so.

I think I added it after seeing your code, but it didn't make any difference. I'll double-check though, thanks.

[chris]

Just had another look at this. Compared to FTPMount, RAWBInfo seems to be trying to get "device" information for my handler:

Obviously it doesn't have any (it's a handler, not a filesystem), so I suspect this is what is causing it to crash.

What causes RAWBInfo to try to obtain this information? Why is it trying to access something which must be a NULL pointer (or uninitialised perhaps)?

The only thing I can immediately think of, is that I'm returning DOSTRUE for ACTION_IS_FILESYSTEM. According to the documentation, that is correct though:

ACTION_IS_FILESYSTEM 1027 IsFileSystem(devname)

RES1: BOOL Success/Failure (DOSTRUE/DOSFALSE)
RES2: CODE Failure code if RES1 is DOSFALSE

Through this function, a handler can indicates whether or not it is a
file system (whether or not it can support separate files for
storing information). Programs will assume a handler can create
multiple, distinct files through calls to Open() if the handler
returns this packet with a DOSTRUE value. A handler does not need to
support directories and subdirectories in order to qualify as a file
system. It does have to support the Examine()/ExNext() calls.

I notice running MountInfo returns a "corrected" mountlist, where it says filesystem instead of handler (but then it also does that for PRT: and SER:, so I'm not sure how reliable an indicator that is). The mountlist itself is definitely correct.

edit Hmm, just noticed I get the same problem with HTTPS: (with a crash), but not with HTTP: - both using the same handler, which definitely does not report itself as being a filesystem.

Code: Select all

10.AmigaOS:> mountinfo http:
/* HTTP: (03/03/2013 15:13) */
Handler = l:http-handler
StackSize = 4096
Priority = 5
GlobVec = -1
10.AmigaOS:> mountinfo https:
/* HTTPS: (03/03/2013 15:13) */
Device = s
Unit = 173295949
FileSystem = l:http-handler
StackSize = 4096
Priority = 5
GlobVec = -1

[tonyw]

I'm just wondering if the crash happens *after* the ACTION_INFO request.

What happens if you are sent other ACTION_xxx packets? Do you reply to them nicely with res1 = FALSE and res2 = ERROR_ACTION_NOT_KNOWN? Can you print out something for every packet you receive, so you can be sure that the ACTION_INFO is the last before the crash?

Also, have you tried telling the truth and saying that it is NOT a filesystem?

[salass00]

@chris

Have you implemented ACTION_GET_DISK_FSSM according to this?
http://babel.de/download/actionfssm.tar.bz2

I don't know if RAWBInfo uses this, but it's a safer way to obtain this information.

Handlers and other filesystems that can't produce the information for a FileSysStartupMsg should return DOSFALSE in Res1 and ERROR_OBJECT_WRONG_TYPE in Res2 in response to ACTION_GET_DISK_FSSM (this is what my XADFS does).

[chris]

I'm just wondering if the crash happens *after* the ACTION_INFO request.

What happens if you are sent other ACTION_xxx packets? Do you reply to them nicely with res1 = FALSE and res2 = ERROR_ACTION_NOT_KNOWN?

Yes.

Can you print out something for every packet you receive, so you can be sure that the ACTION_INFO is the last before the crash?

Code: Select all

[webdav-handler] received packet 25
[webdav-handler] received packet 8
[webdav-handler] received packet 19
[webdav-handler] received packet 19
[webdav-handler] received packet 29
[webdav-handler] received packet 15
[webdav-handler] received packet 1005
[webdav-handler] received packet 82
[webdav-handler] received packet 1027
[webdav-handler] received packet 1007
[webdav-handler] received packet 8
[webdav-handler] received packet 23
[webdav-handler] received packet 29
[webdav-handler] received packet 26
[webdav-handler] received packet 15
[webdav-handler] received packet 29
[webdav-handler] received packet 29
[webdav-handler] received packet 26
Dump of context at 0x7fdb87c0
Trap type: DSI exception
Machine State (raw): 0x2f030
Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on] 
Instruction pointer: 0x6fa4e354
Crashed process: Information... (0x56925cb0)
 0: 00000039 52f5a8c0 00000000 0000180f 5844f790 52f5a8c8 00000001 8000000f
 8: 8000000b 81a1d1d0 8000000a 20687474 00000000 00000000 00000000 00000000
16: 5bf50000 5bf5603c 5bf50000 5bf5603c 5c1e4285 5869e4cc 5bd84388 5bf50000
24: 5bf50000 5bf50000 5bf50000 5bf50000 52f5aa00 577fbb44 5844f790 56279690
CR: 44422044   XER: 00000004  CTR: 0141633c  LR: 6fa4e2c0
ESR: 00000000
DEAR: 81a1d1d0
mcsrr0: 0x0
csrr0: 0x0

Disassembly of crash site:
 6fa4e344: 2f800000   cmpwi             cr7,r0,0
 6fa4e348: 419e0168   beq-              cr7,0x6FA4E4B0
 6fa4e34c: 817e0004   lwz               r11,4(r30)
 6fa4e350: 5569103a   rlwinm            r9,r11,2,0,29
>6fa4e354: 88090000   lbz               r0,0(r9)
 6fa4e358: 2f800000   cmpwi             cr7,r0,0
 6fa4e35c: 41beff6c   beq-              cr7,0x6FA4E2C8
 6fa4e360: 801e0008   lwz               r0,8(r30)
 6fa4e364: 7fa6eb78   mr                r6,r29
 6fa4e368: 389c0020   addi              r4,r28,32
Fault caused by load operation

Registers pointing to code:
r6 : module apps:development/sashimippc/sashimi at 0x00000001 (section 0 @ 0xFFFFFFE8)
r17: module RAWBInfo at 0x5BF5603C (section 4 @ 0x24)
r19: module RAWBInfo at 0x5BF5603C (section 4 @ 0x24)
r29: module RAWBInfo at 0x577FBB44 (section 6 @ 0x1B2C)
ip : module RAWBInfo at 0x6FA4E354 (section 5 @ 0x1433C)
lr : module RAWBInfo at 0x6FA4E2C0 (section 5 @ 0x142A8)
ctr: module Kickstart/kernel at 0x0141633C (section 0 @ 0x16344)

Stack Backtrace:
(0x52f5a8c0) module RAWBInfo at 0x6FA4E354 (section 5 @ 0x1433C)
(0x52f5a900) module RAWBInfo at 0x6FA3C3CC (section 5 @ 0x23B4)
(0x52f5aeb0) module RAWBInfo at 0x6FA421CC (section 5 @ 0x81B4)
(0x52f5af10) module RAWBInfo at 0x6FA42648 (section 5 @ 0x8630)
(0x52f5af40) module LIBS:workbench.library at 0x6FF166D8 (section 5 @ 0x616C0)
(0x52f5af70) module LIBS:workbench.library at 0x6FEF2034 (section 5 @ 0x3D01C)
(0x52f5af90) module Kickstart/dos.library.kmod at 0x0151939C (section 0 @ 0x22DA4)
(0x52f5afc0) module Kickstart/kernel at 0x0143BD20 (section 0 @ 0x3BD28)
(0x52f5afd0) module Kickstart/kernel at 0x0143BDA0 (section 0 @ 0x3BDA8)
(0x52f5afe0) 
(0x0) module Kickstart/kernel at 0x01DBDC56 (section 1 @ 0x15DC5E)
WARNING: Backchain pointer loops

Disassembly of crash site:
 6fa4e344: 2f800000   cmpwi             cr7,r0,0
 6fa4e348: 419e0168   beq-              cr7,0x6FA4E4B0
 6fa4e34c: 817e0004   lwz               r11,4(r30)
 6fa4e350: 5569103a   rlwinm            r9,r11,2,0,29
>6fa4e354: 88090000   lbz               r0,0(r9)
 6fa4e358: 2f800000   cmpwi             cr7,r0,0
 6fa4e35c: 41beff6c   beq-              cr7,0x6FA4E2C8
 6fa4e360: 801e0008   lwz               r0,8(r30)
 6fa4e364: 7fa6eb78   mr                r6,r29
 6fa4e368: 389c0020   addi              r4,r28,32
Stack pointer (0x52f5a8c0) is inside bounds
Redzone is OK (4)

68k register dump
DATA: 00000000 0000009a 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 00000000 52646d40 00000000 00000000 00000000 00000000 00000000 52f5a8b0
STCK: 52f5aa00 577fbb44 5844f790 56279690 52f5a900 6fa4e2c0 15701620 00000000
STCK: 52f5a8f0 24422022 5bd84388 00000001 ffffffff 55c05ab0 5bf50000 16707df8
STCK: 56279320 00000000 52f5aa00 5869e340 52f5aeb0 6fa3c3cc 5bda07c8 52f5aae8
STCK: 57a61f50 00000000 52f5aae8 5bda07c8 52f5a930 01596100 58c382a0 5bf4c730
STCK: 52f5aa00 6fbaae4c 80020003 00000006 80020004 484220a4 00000000 00000007
STCK: 6fa4e1c8 58c373e4 5869e4cc 5bf5603c 58c36184 00000000 01595f94 58c34d1c
STCK: 52f5aaf8 58c37e6c 5ffff800 52f5aaf8 00000000 5ffff800 5ff924d0 6fdd06dc
STCK: 52f5a9f0 015a5ffc 5c17ab40 5c17ab40 52f5a9d0 00000000 01588184 52f5aa70
PC-8: 00005818 e9d01670 7df8577f a1380000 00000000 0000ffff 00000000 00000000
PC *: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Address of 68k IP r21 0x5869e4ca not found
Address of 68k IP r8  0x8000000b not found
----> 577fbb44 - "RAWBInfo" Hunk 0006 Offset 00001b44 (SegList: 0x15ee866d)
----> 6fa4e2c0 - "RAWBInfo" Hunk 0005 Offset 000142c0 (SegList: 0x15ee866d)
----> 00000001 - "apps:development/sashimippc/sashimi" Hunk 0000 Offset 00000000 (SegList: 0x15a4966d)
----> 6fa3c3cc - "RAWBInfo" Hunk 0005 Offset 000023cc (SegList: 0x15ee866d)
----> 01596100 - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00008300
----> 6fbaae4c - "CLASSES:gadgets/space.gadget" Hunk 0004 Offset 00000e4c (SegList: 0x15db6a75)
----> 6fa4e1c8 - "RAWBInfo" Hunk 0005 Offset 000141c8 (SegList: 0x15ee866d)
----> 5bf5603c - "RAWBInfo" Hunk 0004 Offset 0000003c (SegList: 0x15ee866d)
----> 01595f94 - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 00008194
----> 6fdd06dc - "CLASSES:gadgets/layout.gadget" Hunk 0005 Offset 000086dc (SegList: 0x16ff838d)
----> 015a5ffc - "Kickstart/intuition.library.kmod" Hunk 0000 Offset 000181fc
----> 01588184 - "Kickstart/graphics.library.kmod" Hunk 0000 Offset 0002b724

Disassembly of 68k crash site:
 5869E4CA: 0000 0000               	ori.b	#0,d0
 5869E4CE: 0000 0000               	ori.b	#0,d0
 5869E4D2: 0000 0000               	ori.b	#0,d0
 5869E4D6: 0000 0000               	ori.b	#0,d0
 5869E4DA: 0000 0000               	ori.b	#0,d0
 5869E4DE: 0000 0000               	ori.b	#0,d0
 5869E4E2: 0000 0000               	ori.b	#0,d0
 5869E4E6: 0000 0000               	ori.b	#0,d0
 5869E4EA: 0000 0000               	ori.b	#0,d0
 5869E4EE: 0000 0000               	ori.b	#0,d0
Page information:
Page not found


[webdav-handler] received packet 25
[webdav-handler] received packet 15

Packet 26 is ACTION_INFO.

Also, have you tried telling the truth and saying that it is NOT a filesystem?

Well, I'm not sure if it really is the truth given dos.library's definition, but I've just tried it and it makes no difference.


@salass00

First I've heard of it, but packets 4201/4202 don't show up in my log, so it won't help.

[salass00]

@chris

If you still have problems check this:
http://amigaworld.net/modules/newbb/vie ... r=0#580516

I had a similar problem in XADFS that was fixed by setting dn_Startup to ZERO. This stops RAWBInfo from trying to interpret it as a FileSysStartupMsg structure.

[chris]

@chris

If you still have problems check this:
http://amigaworld.net/modules/newbb/vie ... r=0#580516

I had a similar problem in XADFS that was fixed by setting dn_Startup to ZERO. This stops RAWBInfo from trying to interpret it as a FileSysStartupMsg structure.

You utter genius, it worked!

Now we know the cause, can you log a bugzilla for it to be fixed? (even if it's a documentation update "if you're writing a handler, you need to clear the dn_Startup field after initialisation")

[salass00]

Now we know the cause, can you log a bugzilla for it to be fixed? (even if it's a documentation update "if you're writing a handler, you need to clear the dn_Startup field after initialisation")

I've just changed RAWBInfo so that it uses GetDiskFileSystemData() which does more sanity checking on the possible FSSM structure before using it to avoid these kinds of problems.