SEGV in malloc()! glibc bug??
wang yin
I'm writing a simple program that need much memory.
I allocate memory with mallocs such as this line:
if ((left = malloc (sizeof (tree_node))) == NULL) fatal ("not enough
memory");
But once in a while my program got a SEGV and dumped a core. I examine
the core with gdb. But gdb gave me this information:
Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x400fe000
#0 0x420741df in ?? ()
I run the program in gdb and after a while, it cought a SEGV inside malloc!
Program received signal SIGSEGV, Segmentation fault.
0x420739e5 in _int_malloc () from /lib/i686/libc.so.6
But sometimes it doesn't killed by SEGV at all. Sometimes it get cought
in sbrk()!
Program received signal SIGSEGV, Segmentation fault.
0x420d3399 in sbrk () from /lib/i686/libc.so.6
What happened to the program?
Paul Pluzhnikov
> But sometimes it doesn't killed by SEGV at all. Sometimes it get cought
> in sbrk()!
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x420d3399 in sbrk () from /lib/i686/libc.so.6
>
> What happened to the program?
All of the symptoms you listed are *classic* symptoms of heap
corruption. With 99.9999% probability the bug is in *your* code,
not in glibc.
Check your code with mptarol, dmalloc, efence or valgrind.
Cheers,
--
In order to understand recursion you must first understand recursion.
Kasper Dupont
>
> I run the program in gdb and after a while, it cought a SEGV inside malloc!
http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html#SIGSEGV
--
Kasper Dupont -- der bruger for meget tid på usenet.
For sending spam use mailto:aaa...@daimi.au.dk
or mailto:mcxumhv...@skrammel.yaboo.dk
Eric P. McCoy
> I run the program in gdb and after a while, it cought a SEGV inside malloc!
[...]
> But sometimes it doesn't killed by SEGV at all. Sometimes it get cought
> in sbrk()!
[...]
> What happened to the program?
Usually problems of this sort are caused by heap corruption from
elsewhere in your program. Somewhere, some piece of code is trashing
the heap, and that's causing malloc() to do something it can't. Try
running your program with a bounds checker or malloc debugger, like
Valgrind.
--
Eric McCoy (reverse "ten.xoc@mpe", mail to "ctr2sprt" is filtered)
"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass." - John Novak, rasfwrj
wang yin
VLSI chip. It works with nodes on the 2-d surface.
I deleted all my calls to free() from the program and still get the problem!
I linked the program with efence and it still crashes! It can't give me
any information.
Surprisingly, I link the program with dmalloc and it works fine! It can
even handle 1,000,000 nodes without any problem! And it works well
inside gdb!
What a stange problem!
Kevin Easton
> My program is for illustrate the MMM algorithm of routing wires on a
> VLSI chip. It works with nodes on the 2-d surface.
>
> I deleted all my calls to free() from the program and still get the problem!
>
> I linked the program with efence and it still crashes! It can't give me
> any information.
Yes, efence is designed to make your program get a SEGV at the point
where it first does an invalid memory access. Set "ulimit -c unlimited"
to enable core file generation, run your program so that it crashes and
generates a coredump, then analyse the coredump with gdb to see where it
crashed.
- Kevin.
Martin Blume
Kasper Dupont <kas...@daimi.au.dk> schrieb in im Newsbeitrag:
3D9FEFDA...@daimi.au.dk...
> wang yin wrote:
> > I run the program in gdb and after a while, it cought a SEGV inside
malloc!
> http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html#SIGSEGV
>
- calling a function with the wrong number of parameters
- misinterpreting some parameters
- reading a return value from a void function
(although some of these should be caught already by the compiler ...)
These errors usually (I'speaking from Windoze experience here) don't crash
the program right away, but sometimes later (sometimes a lot later ...) in a
function that "cannot possibly crash".
Have a close look at functions with variable number of parameters, with
functions that take generic pointers (void *pData) which you then have to
cast to the proper object type.
Regards
Martin
wang yin
1033902671: 580: Dmalloc version '4.8.1' from 'http://dmalloc.com/'
1033902671: 580: flags = 0x4f41d03, logfile 'memlog'
1033902671: 580: interval = 1, addr = 0, seen # = 0
1033902671: 580: starting time = 1033902670
1033902671: 580: heap-check: failed OVER picket-fence magic-number
check: pointer '0x805ce48' from 'mmm1.w:241'
1033902671: 580: Dump of proper fence-top bytes: 'i\336\312\372'
1033902671: 580: Dump of '0x805ce48'+8:
'c\000\000\000\305\305\305\305\305\305\3
05\305\305\305\305\305\305\305\305\305\000\000\000\000'
1033902671: 580: ERROR: fence_read: failed OVER picket-fence
magic-number check
(err 27)
But I don't know what caused the violation. my mmm1.w contains the line:
if ((root = malloc(sizeof (point)))==NULL)
fatal("not enough memory for root node");
I can't get information from the core file...
I must read my source code carefully later. I'll have a rest!
Thank you all :)
bowman
SEGV in a call to malloc() is usually a result of your code calling free()
on an invalid pointer or overwriting an allocated buffer, destroying the
fenceposts that malloc/free use.
These problems can be difficult to detect as the segfault often occurs well
after you've corrupted the internal data. Try one one the malloc debuggers.
Måns Rullgård
> In addition to the possible errors, you might add:
> - calling a function with the wrong number of parameters
> - misinterpreting some parameters
> - reading a return value from a void function
> (although some of these should be caught already by the compiler ...)
Which is why you always do something about "implicit declaration"
warnings.
--
Måns Rullgård
m...@users.sf.net
Hartmann Schaffer
wang yin <wang...@mails.tsinghua.edu.cn> writes:
> Hmmm... dmalloc caught the bug!
>
> 1033902671: 580: Dmalloc version '4.8.1' from 'http://dmalloc.com/'
> 1033902671: 580: flags = 0x4f41d03, logfile 'memlog'
> 1033902671: 580: interval = 1, addr = 0, seen # = 0
> 1033902671: 580: starting time = 1033902670
> 1033902671: 580: heap-check: failed OVER picket-fence magic-number
> check: pointer '0x805ce48' from 'mmm1.w:241'
> 1033902671: 580: Dump of proper fence-top bytes: 'i\336\312\372'
> 1033902671: 580: Dump of '0x805ce48'+8:
> 'c\000\000\000\305\305\305\305\305\305\3
> 05\305\305\305\305\305\305\305\305\305\000\000\000\000'
> 1033902671: 580: ERROR: fence_read: failed OVER picket-fence
> magic-number check
> (err 27)
>
> But I don't know what caused the violation. my mmm1.w contains the line:
> if ((root = malloc(sizeof (point)))==NULL)
> fatal("not enough memory for root node");
> I can't get information from the core file...
>
> I must read my source code carefully later. I'll have a rest!
> Thank you all :)
you haven't shown the code after an allocation, when you initialize
the allocated block. most likely the problem lies there, e.g. if you
do something like
int *p= malloc(10*sizeof(int);
p[10]= ...
where you write something beyond the allocated block. this overwrites
the information malloc writes at the boundaries to kep track of free
blocks and typically results in your problem
hs
--
don't use malice as an explanation when stupidity suffices
wang yin
>>But I don't know what caused the violation. my mmm1.w contains the line:
>>if ((root = malloc(sizeof (point)))==NULL)
>> fatal("not enough memory for root node");
>>I can't get information from the core file...
>>
>>I must read my source code carefully later. I'll have a rest!
>>Thank you all :)
>
>
> you haven't shown the code after an allocation, when you initialize
> the allocated block. most likely the problem lies there, e.g. if you
> do something like
>
> int *p= malloc(10*sizeof(int);
>
> p[10]= ...
>
> where you write something beyond the allocated block. this overwrites
> the information malloc writes at the boundaries to kep track of free
> blocks and typically results in your problem
>
> hs
>
God! The point is here! I should use:
if ((root = malloc(sizeof (tree_node)))==NULL)
fatal("not enough memory for root node");
But I allocated a "point" structure, which is smaller than "tree_node",
for the root pointer! And I when I manipulate the root node later, I
corrupted the memory structure infomation for malloc()...
Thank you!! dmalloc is useful. Sigh for malloc()... I'll be cautious
next time! What if C has "new"!
Kasper Dupont
>
> What if C has "new"!
I have seen this used in a header file:
#define NEW(type) (type *)Malloc(sizeof(type))
void *Malloc(unsigned n);
With Malloc looking like this:
void *Malloc(unsigned n)
{ void *p;
if (!(p = malloc(n))) {
fprintf(stderr,"Malloc(%d) failed.\n",n);
fflush(stderr);
abort();
}
return p;
Kamil Burzynski
"wang yin" <wang...@mails.tsinghua.edu.cn> wrote in message news:3DA0FA2A...@mails.tsinghua.edu.cn...
> Thank you!! dmalloc is useful. Sigh for malloc()... I'll be cautious
> next time! What if C has "new"!
root = new point; also would be a bug :)
--
Best regards from
Kamil Burzynski
Senior Design Engineer
Advanced Digital Broadcast Poland, LTD.
- -
"Yes, I'm criminal. My crime is that of curiosity."
wang yin
> "wang yin" <wang...@mails.tsinghua.edu.cn> wrote in message news:3DA0FA2A...@mails.tsinghua.edu.cn...
>
>>Thank you!! dmalloc is useful. Sigh for malloc()... I'll be cautious
>>next time! What if C has "new"!
>
>
> root = new point; also would be a bug :)
But the bug won't pass the compiler :P