malloc problems

Unrecoverable error in run time system. Not enough memory, Malloc failed, (Heap over written)

I’m getting the above error and I’m having a hard time tracking down the problem. The generic code I’ve written does not error on Windows with Visual Studio but with RISC OS OPEN C++ on RPCEMU it gives the above error. Obviously alot of the code pertaining to RISC OS cant be tested on the other side and this is likely where the issue lies.

I know I can’t get a ‘ah, this is your issue’ here because of the nature of the beast but pointers on malloc issues and how to resolve them would be great. I came across ‘MalCheck’ but it doesn’t work with my setup. I get a ‘amu doesn’t know how to make MalCheck …..’

The problem area is structures and pointers to, and as members of, structures. I’ve tried a number of ways of defining and declaring them but I can’t find the problem.

Anybody know of anything like the MalCheck library to intercept malloc calls that works with RISC OS OPEN C++?

You probably don’t see your heap corruption problem with Visual Studio C++, particularly when compiled for debug, has massive guards between blocks, but requires explicit calls to detect if they have been trampled on (CRT memory checkpoints or some such).

Is this any use?:

https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Paint/-/blob/master/h/guard
https://gitlab.riscosopen.org/RiscOS/Sources/Apps/Paint/-/blob/master/c/guard

If you look in the header file, it redefines malloc(), free(), etc. to check for the guard words. You could temporarily add the above two files to your solution, but it does have a dependency on ftrace (which can write debugging information out to a file if you do e.g. “Set Trace$To flogfile” – make sure the ‘f’ is at the start of the path as it enables tracing to a file), but you can get c.ftrace and h.ftrace from Paint’s source code on Gitlab as well.

Ftrace includes quite a lot of other libraries including WIMP stuff, so to get it working on your project it might be quicker to just replace all the ftrace calls in c.guard with printf() instead.

Thanks David, good points.

Great info Andy, I’ll give that a go, using the ‘printf’ option me thinks.

I have made some progress but not there yet.

@ Mike

In the worst case, you can use DDT debugger, in recent months some C++ users made me use it again and I saw it can do source debugging of the C++ code too.

It may be worth a try.

If you’re not familiar with it, I wrote a set of tutorials on how to use it to debug sources on RISC OS:
https://paolozaino.wordpress.com/tag/acorn-ddt-tutorial/

I need to add more tutorial articles, but just had not enough time for it yet.

If you’re compiling on Linux for Linux, I’d give it a test using Valgrind.

Thank you Paolo, I’ll give it a try and the tutorials.

I have found the current problems with malloc (actually my coding) but I’m sure there will be more bug hunting ahead.