In my application, after it runs for about 3 hours, I am getting SIGSEGV signal with an si_code of SEGV_MAPERR (address not mapped to object) when it tries to do a malloc of 65536 bytes, which it does successfully numerous times before it gets this seg fault. Repeated trials show it happening at the same place.
Any ideas what may be causing this or how I might go about determining the cause? I am running Linux 2.6.26 on PowerPC.
Assuming the information above is correct, ie the segfault happens inside malloc, the best guess would be 'malloc heap corrupted due to use of a dangling pointer elsewhere' (or 'writing beyond the boundaries of an allocated object'). Enabling coredumps (ulimit -c) and feeding the resulting core file to gdb should be sufficient to determine if the exception is really caused by the malloc-implementation. If it is, you could try to use a watch point to cause the debugger to stop your program when the corruption occurs.
How numerous? Are you out of memory? How much swap do you have?
While I might use malloc() at startup, I hate the use of free() due to the pool fragmentation problem, so I prefer not to use free() in systems, unless I have been in retirement for a few years, when the free() is executed :-).
Paul
Are u sure that u have more free pages in memory space, may be memory leaks causing no free pages could be alloc.
Hundreds. Thousands if runs for any amount of time, say over 10 minutes.
Running meminfo gives the information below. What is the best way to determine if out of memory and how much swap there is while the program in running?
# cat meminfo MemTotal: 126996 kB MemFree: 102828 kB Buffers: 0 kB Cached: 10108 kB SwapCached: 0 kB Active: 7640 kB Inactive: 8316 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 5892 kB Mapped: 2188 kB Slab: 1648 kB SReclaimable: 276 kB SUnreclaim: 1372 kB PageTables: 312 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 63496 kB Committed_AS: 288636 kB VmallocTotal: 376832 kB VmallocUsed: 26188 kB VmallocChunk: 346620 kB
How would I check for that?
Take a look at "electric fence" or valgrind. They are tools to catch malloc/free errors.
EFence will replace malloc/free with versions which allocate entire pages for each item you malloc(), leaving holes between these, so it catches bugs where you run over the end of the malloc'ed area. It will also always return free()'d areas to the OS, catching bugs where you reference stale pointers. The core dumps it produces are gigantic ;-)
Valgrind will trace your program's execution and alert you when the program does illegal accesses (e.g. access the 101th element in a
100-sized array). It slows down the program extremely.Josef
-- These are my personal views and not those of Fujitsu Siemens Computers! Josef Möllers (Pinguinpfleger bei FSC) If failure had no penalty success would not be a prize (T. Pratchett) Company Details: http://www.fujitsu-siemens.com/imprint.html
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.