Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

malloc causes SIGSEGV signal with SEGV_MAPERR si_code

643 views
Skip to first unread message

Bill

unread,
Oct 2, 2008, 12:48:45 PM10/2/08
to
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.

Rainer Weikusat

unread,
Oct 2, 2008, 1:10:44 PM10/2/08
to
Bill <jobhu...@aol.com> writes:
> 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.

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.


Joe Pfeiffer

unread,
Oct 2, 2008, 1:45:02 PM10/2/08
to
Bill <jobhu...@aol.com> writes:

How numerous? Are you out of memory? How much swap do you have?

Paul Keinanen

unread,
Oct 2, 2008, 2:38:53 PM10/2/08
to
On Thu, 2 Oct 2008 09:48:45 -0700 (PDT), Bill <jobhu...@aol.com>
wrote:

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

lion3875

unread,
Oct 3, 2008, 12:39:32 AM10/3/08
to

Are u sure that u have more free pages in memory space, may be memory
leaks causing no free pages could be alloc.

Bill

unread,
Oct 3, 2008, 9:13:16 PM10/3/08
to
On Oct 2, 10:45 am, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

> Bill <jobhunt...@aol.com> writes:
> > 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.
>


> How numerous?  

Hundreds. Thousands if runs for any amount of time, say over 10
minutes.


> Are you out of memory?  How much swap do you have?

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

Bill

unread,
Oct 3, 2008, 9:13:49 PM10/3/08
to


How would I check for that?

Josef Moellers

unread,
Oct 6, 2008, 3:17:46 AM10/6/08
to

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

0 new messages