f



realloc failed error

Am having a go at 32bitting !TreeMenu.

A ex 'C' prog restubbed etc.
Seems to be working ok with RO4.

But with RO5.23 - opening a menu of the $ Dir (its job) it gives the 
error 'Unrecoverable error in run time System: Not enough memory, 
realloc failed, (bad user block).

Sometimes it will be ok for hours.

If it gives the error - the prog quits - but on reloading - it gets to 
the iconbar- clicking on the iconbar gives the same error.
Time and time again - until the emulator is rebooted.

Where does' realloc get its memory from RMA?
Any pointers?

Thanks

-- 
Colin Ferris Cornwall UK
0
cferris
9/6/2016 12:34:10 PM
comp.sys.acorn.programmer 2499 articles. 0 followers. Post Follow

3 Replies
205 Views

Similar Articles

[PageSpeed] 26

On 06/09/2016 13:34, cferris@freeRemoveuk.com.invalid wrote:
> Am having a go at 32bitting !TreeMenu.
>
> A ex 'C' prog restubbed etc.
> Seems to be working ok with RO4.

If you've restubbed it following my method, then its more luck than 
judgement that it works, and finding intermittent issues is going to be 
difficult to fix.

> But with RO5.23 - opening a menu of the $ Dir (its job) it gives the
> error 'Unrecoverable error in run time System: Not enough memory,
> realloc failed, (bad user block).

The only way to get to the bottom of this is to use the very primitive 
Acorn C/C++ debugger, if it even works at all on your system.

> Sometimes it will be ok for hours.

I had a similar thing with a RISC OS 4 screen saver that I ported, it 
would work for hours then crash. It wasn't often enough for me to bother 
fixing it.

> If it gives the error - the prog quits - but on reloading - it gets to
> the iconbar- clicking on the iconbar gives the same error.
> Time and time again - until the emulator is rebooted.
>
> Where does' realloc get its memory from RMA?
> Any pointers?

Only if its a module written in C, if it's a C executable it comes from 
application memory.

---druck

0
druck
9/6/2016 12:44:02 PM
On 06/09/2016 13:34, cferris@freeRemoveuk.com.invalid wrote:
> Am having a go at 32bitting !TreeMenu.
>
> A ex 'C' prog restubbed etc.
> Seems to be working ok with RO4.
>
> But with RO5.23 - opening a menu of the $ Dir (its job) it gives the
> error 'Unrecoverable error in run time System: Not enough memory,
> realloc failed, (bad user block).
>
> Sometimes it will be ok for hours.
>
> If it gives the error - the prog quits - but on reloading - it gets to
> the iconbar- clicking on the iconbar gives the same error.
> Time and time again - until the emulator is rebooted.
>
> Where does' realloc get its memory from RMA?
> Any pointers?
>
> Thanks
>

You could try using Fortify to wrap the memory allocations - 
http://nettle.cvs.sourceforge.net/viewvc/nettle/nettle/c/fortify and 
http://nettle.cvs.sourceforge.net/viewvc/nettle/nettle/h/fortify

Then if you try and free/realloc 'bad' blocks it should catch them as it 
tracks all the memory allocations done (provided you've included 
fortify.h in all your C files)

Alex.
0
Alex
9/8/2016 7:39:52 AM
On 08/09/2016 08:39, Alex Macfarlane Smith wrote:
> You could try using Fortify to wrap the memory allocations -
> http://nettle.cvs.sourceforge.net/viewvc/nettle/nettle/c/fortify and
> http://nettle.cvs.sourceforge.net/viewvc/nettle/nettle/h/fortify
>
> Then if you try and free/realloc 'bad' blocks it should catch them as it
> tracks all the memory allocations done (provided you've included
> fortify.h in all your C files)

 From what the OP said about re-stubbing, it's a port to 32bit from the 
26bit binary and no source is available to recompile from.

You could intercept memory allocation calls to the stub branch table, 
and redirect them at your own assembler wrappers. To put the code in 
application memory means changing a few things in the AIF and Stubs 
headers, so it's probably best to use a module to avoid that.

OP: did you alter the relevant numbers when you re-stubbed?

It comes down to how much time you are willing to spend tracking down 
such problems, if there isn't an alternative program you can use, it 
might well be quicker to write a replacement from scratch!

---druck

0
druck
9/8/2016 9:27:33 AM
Reply: