On Mon, 3 Mar 2014, Mark Cave-Ayland wrote:
Ah that's why this looks a little strange to me. Can you try with just plain SVN trunk (without Olivier's patch) to make sure that doesn't have an effect too?
Here it is with SVN trunk with only DEBUG_CIF and the memdump length changed for nextprop in debug code:
nextprop(0xfff517e4, "name", 0x07de7e30) =
: nextprop ( 7de7e30 7de7e30 fff517e4 ) fff49f08: >r 3 > 7de7e30 20 dump 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............ 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok 3 > resume ok ( 7de7e30 7de7e30 fff517e4 ) fff49f08: >r ( 7de7e30 7de7e30 ) fff49f0c: dup ( 7de7e30 7de7e30 7de7e30 ) fff49f10: 0= ( 7de7e30 7de7e30 0 ) fff49f14: do?branch ( 7de7e30 7de7e30 ) fff49f28: dup ( 7de7e30 7de7e30 7de7e30 ) fff49f2c: cstrlen 3 > 7de7e30 20 dump 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............ 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok 3 > resume ok ( 7de7e30 7de7e30 7de7e30 ) fff49f2c: cstrlen ( 7de7e30 7de7e30 4 ) fff49f30: 0 3 > 7de7e30 20 dump 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............ 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok 3 > resume ok ( 7de7e30 7de7e30 4 ) fff49f30: 0 ( 7de7e30 7de7e30 4 0 ) fff49f34: 3 ( 7de7e30 7de7e30 4 0 3 ) fff49f38: pick ( 7de7e30 7de7e30 4 0 7de7e30 ) fff49f3c: c! 5 > 7de7e30 20 dump 7de7e30 6e 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 name............ 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok 5 > resume ok ( 7de7e30 7de7e30 4 0 7de7e30 ) fff49f3c: c! ( 7de7e30 7de7e30 4 ) fff49f40: dup 3 > 7de7e30 20 dump 7de7e30 00 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 .ame............ 7de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ok 3 > resume ok ( 7de7e30 7de7e30 4 ) fff49f40: dup ( 7de7e30 7de7e30 4 4 ) fff49f44: do?branch ( 7de7e30 7de7e30 4 ) fff49f4c: 2dup ( 7de7e30 7de7e30 4 7de7e30 4 ) fff49f50: r@ ( 7de7e30 7de7e30 4 7de7e30 4 fff517e4 ) fff49f54: get-package-property ( 7de7e30 7de7e30 4 ffffffff ) fff49f58: do?branch ( 7de7e30 7de7e30 4 ) fff49f60: r> ( 7de7e30 7de7e30 4 fff517e4 ) fff49f64: 2drop ( 7de7e30 7de7e30 ) fff49f68: 2drop ( Empty ) fff49f6c: -1 ( ffffffff ) fff49f70: exit -1
0x07de7e30 00 61 6d 65 00 00 00 00 00 00 00 00 00 00 00 00 .ame............ 0x07de7e40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ child(0xfff517e4) = 0x00000000
I wonder if the problem could be caused by the incoming property address and the outgoing property address being the same? It may be that MorphOS relies on an implementation-specific behaviour that means this just happens to work on PPC Open Firmware.
It can be. It looks like that the buffer is cleared before it gets used by later code. Do you have any idea how to fix this?
Regards, BALATON Zoltan