Missing memory in a dynamic area

I recently migrated mail from my old Iyonix to the brand new ARMini/Pandaboard thingy. Unfortunately I’m having problems with SpamStamp. Thankfully it is my own software, so today I’ve been looking into what is happening, and frankly, I do not understand what is going on.

It seems to me the dynamic area used by SpamStamp is missing 76Kb at the end. (I think the amount differs and I’ve also seen SpamStamp work, so I think it’s not always the same).

When I list out the DA with this code: (let’s see if I can get textile to cooperate… first try with something more advanced here…)

area%=-1
REPEAT
 SYS"OS_DynamicArea",3,area% TO ,area%
 IF area%<>-1 THEN
  SYS"OS_DynamicArea",2,area% TO ,,size%,base%,flags%,max%,,,name$
 ENDIF
 IF name$="SpamStamp workspace" THEN
  PRINTarea%,name$,~base%,~size%,~max%,~flags%
 ENDIF
UNTIL area%=-1

This gives the following output:

        282SpamStamp workspace   93003000    808000    808000        80

I would expect the last address in this area to be at &93003000 + &808000 – 1 but:

>P.?(&93003000+&808000-1)

Internal error: abort on data transfer at &FC170610
>P.?(&93003000+&7f5000-1)
         0
>P.?(&93003000+&7f5001-1)

Internal error: abort on data transfer at &FC170610

It seems to me the last 76Kb are missing. Am I right in concluding that this never should happen? What is going on?

The version of RISC OS I am running is a nightly build from 24 Sep 2012.

I’m totally mistified by this problem. I’ve been investigating but the results make me just wonder even more… I’ve made a routine that checks if the memory of a DA is available. It appears that it is not missing the last part of the DA. There are just some blocks gone, sometimes (guessing now) 7 areas of memory missing within a DA of 8224Kb. But most often it is just a block of 16Kb that is missing.

Using this test routine I made a program that created a DA, checked it, created the next one, checked it and so on. After that it went through them again (expecting DA 1 to go corrupted when DA 2 is created) and after that deleting the DAs.

However, what I saw was that for some DAs, it is corrupted right away. But on the second pass, they all turn out fine! Nothing wrong!

Just for a sanity check: In BASIC this is what I use to create a DA:

SYS"OS_DynamicArea",0,-1,size%,-1,&80,size%,0,0,"TestArea "+STR$testarea% TO ,area%

SpamStamp itself uses C and does this:

  error = xosdynamicarea_create (os_DYNAMIC_AREA_APPLICATION_SPACE,
                                 needed_size,
                                 osdynamicarea_ALLOCATE_BASE,
                                 os_AREA_NO_USER_DRAG,
                                 needed_size,
                                 NULL,
                                 NULL,
                                 Title " workspace",
                                 &dyn_area,
                                 (byte **) &dict_mem,
                                 &size);

Is something wrong here? It seems fine to me.

I have a little C-program that just does the creation of a DA with the above code and nothing else. On 2 occassions it gave an error followed by some other apps crashing and eventually stiffing the whole machine.

You can see my testprogram here

ARMini/Pandaboard

ARMini or Pandaboard? They’re two completely different things.

Do you have anything running which could be messing with the memory map? e.g. Aemulor.

I’ll give your test program a go tonight on my BB-xM (i.e. ARMini) and see what happens.

Sorry, that was a bit unclear. It’s a Pandaboard (ES, actually) in an ARMini case.

Strangely the effects seemed to be gone yesterday evening but I think that was just coincidence. It also seemed that my testprogram was a slower when there were errors to report. I don’t think the detection of errors itself should account for that, but I’m not sure. But it could be I was imagining that, not sure.

Your test program runs OK on my BB-xM.

It also seemed that my testprogram was a slower when there were errors to report.

That sounds plausible. I’m thinking the bug is caused by the memory map becoming corrupt, resulting in invalid addresses being mapped in when you create the dynamic areas. It could also result in the kernel trying to flush those invalid pages from the cache before they get remapped to the dynamic area. On ARMv7 flushing an invalid address will trigger an abort, while on earlier architectures it wouldn’t. The abort handler in the kernel will detect this and ignore the abort (since there are a few situations where the kernel will try flushing invalid addresses). However the abort handler will slow things down a bit.