Ticket #381 (Open)Wed Mar 05 15:24:11 UTC 2014
Memory leaks on longjmp
| Reported by: | WPB (1391) | Severity: | Normal |
| Part: | RISC OS: Software library | Release: | |
| Milestone: | Status | Open |
Details by WPB (1391):
The C runtime leaks memory when longjmp is performed. Ben Avison quotes from the compiler release notes:
VLAs use new library functions “__rt_allocauto” and “__rt_freeauto”. In the future these could be improved to make sure VLAs are freed correctly in longjmp-type situations, by associating blocks with stack chunk and stack pointer values.To quote Ben’s approach to fixing the problem (communicated via email):
In principle, it’s just a matter of over-allocating memory within __rt_allocauto and using the extra space to construct a wrapper which includes a linked list pointer so it can be located from the stack chunk header, plus the stack pointer that was pertinent at allocation time; then when you longjmp back up the stack, iterate over stack chunks and auto-alloced blocks that belonged to skipped stack frames, and free them.I discovered this when trying to compile & link C code using OSLibSupport (http://sourceforge.net/projects/ro-oslib/files/…), when linking fails with:
ARM Linker: (Error) Undefined symbol(s).
ARM Linker: ___arm_alloca_longjmp, referred to from OSLibSupport:o.OSLibSupport32(o).
ARM Linker: Errors in link, no output generated.
ARM Linker: finished, 2 informational, 0 warning and 1 error messages.
AMU: * exit (1) *
Changelog:
Modified by Ben Avison (25) Sun, March 09 2014 - 21:24:56 GMT
- Part changed from RISC OS: C/C++ toolchain to RISC OS: Software library
It looks like you’re confusing two different issues there. I think the unsatisfied call to __arm_alloca_longjmp must have been inserted by GCC? It’s not part of the Norcroft / shared C library VLA support routines, and it’s also not explicitly referenced in the OSLib source code. If OSLibSupport:o.OSLibSupport32 was compiled using GCC (I’m not sure how it was generated) you might want to try recompiling it using Norcroft to avoid this.
I’m also changing the “Part” that this fault applies to, since __rt_allocauto and __rt_freeauto are functions in the shared C library, not the toolchain – see kernel.s.k_body.
