multiview/picture datatype crashlog

Does anybody have any ideas what might be the cause of this crash?

I'm getting exactly the same crash when loading files with two different datatypes (it's random though - not always the same file). It is a complete freeze, with the following being piped out the serial port:


Dump of context at 0x01888EE0
Trap type: DSI exception
Machine State (raw): 0x0000F030
Machine State (verbose): [ExtInt on] [User] [FPU on] [IAT on] [DAT on]
Temporary stack trace:
#0: in module Kickstart/kernel+0x000228D8 (0x014228D8)
#1: 0x7E4CD128
#2: 0x7E4C1B70
#3: 0x7E4C2250
#4: 0x7E4C22B0
#5: in module Kickstart/kernel+0x0004BD2C (0x0144BD2C)
#6: 0x6FEE1F70
#7: 0x00010142

Crashed process: (0x6A393390)
0: 00000000 6FEE1BD0 FEFEFEFE 6A264328 6A370FF0 00000BE8 00000C00 6A265E28
8: 6A265D28 00000000 6A371010 6A264DE0 39F55E55 FEFEFEFE 69ADD7CC 6A78D320
16: 00000010 00000000 00000010 FFFFFFFF 6A041898 00000010 6A041894 00000001
24: 6FEE1BF4 6FEE1C2C 00000000 00000000 00000004 00000100 6B794454 6B452A54
CR: 53F55E55 XER: C000FE7E CTR: 0000000A LR: 014163CC
DSISR: 40000000 DAR: 6A371000
DSI verbose error description: Access not found in hash or BAT (page fault)
Access was a load operation

Registers pointing to code:
ip : native kernel module Kickstart/kernel+0x000228D8
lr : native kernel module Kickstart/kernel+0x000163CC
ctr: unknown (0x0000000A)

Stack Backtrace:
native kernel module Kickstart/kernel+0x000228D8
module LIBS:datatypes/picture.datatype at 0x7E4CD128 (section 4 @ 0xD108)
module LIBS:datatypes/picture.datatype at 0x7E4C1B70 (section 4 @ 0x1B50)
module LIBS:datatypes/picture.datatype at 0x7E4C2250 (section 4 @ 0x2230)
module LIBS:datatypes/picture.datatype at 0x7E4C22B0 (section 4 @ 0x2290)
native kernel module Kickstart/kernel+0x0004BD2C
native kernel module Kickstart/kernel+0x0004BD2C
WARNING: Invalid backchain pointer found (68k crosscall?)!
native kernel module Kickstart/intuition.library.kmod+0x0001AA24
native kernel module Kickstart/intuition.library.kmod+0x0001AAC0
native kernel module Kickstart/intuition.library.kmod+0x0001AAC0

Disassembly of crash site:
014228C8: 80040008 lwz r0,8(r4)
014228CC: 900B0008 stw r0,8(r11)
014228D0: 8124000C lwz r9,12(r4)
014228D4: 912B000C stw r9,12(r11)
>014228D8: 80040010 lwz r0,16(r4)
014228DC: 900B0010 stw r0,16(r11)
014228E0: 81240014 lwz r9,20(r4)
014228E4: 912B0014 stw r9,20(r11)
014228E8: 80040018 lwz r0,2

@Chris

The crash seems to happen in OM_SET, in the code which
detects that the number of colors have changed, the part
which copies the old colors to the new allocated colors,
so probably the old colors were already freed or the old
number of colors was too high or something like that.

@TetiSoft

That's useful, except the number of colours changing is pretty much the first thing one of the datatypes does (not sure about the other one). The sequence is:

IDataTypes->SetDTAttrs(o, NULL, NULL,
PDTA_NumColors,cols,
TAG_END);

IDataTypes->GetDTAttrs(o,
PDTA_ColorRegisters,&cmap,
PDTA_CRegs,&cregs,
TAG_END);

Followed by setting the colour registers, and then setting the depth parameter in the bitmap header. There is no other code relating to the colour palette.

The only thing that strikes me is that there should be no old palette for picture.datatype to copy - could this be the problem? Am I supposed to be initialising something else to stop this happening?

Chris

@Chris

I'm not a great expert in datatypes, maybe its best when
you send me some sourcecode which causes the crash, or URLs
to the datatypes, and the image which doesnt work. Then
I can try to debug what happens.

@TetiSoft

The easiest way to reproduce it, is to download this and continually double-click on testpage.bin until it crashes. The actual picture doesn't matter, and the crash/freeze will occur after a seemingly random number of open attempts.

The other one with the same problem is this, but I don't have any example pictures to hand, and they're tricky to find on the Web.

Chris

@Chris

picture.datatype 52.2 (13.4.2007) <dwuerkner>

- When PDTA_NumColors was changed from a non-zero value to a greater
value, too many color data was copied which could trigger the GrimReaper
when trying to read from unallocated memory. Thanks to Chris Young for
the report.

Eventually you can work around the bug by querying the value
and setting it to zero first when it was non-zero before.

@TetiSoft

Thanks Detlef, I'll implement the workaround for now.

Chris