Segment violation in malloc()

Hi,

I’ve come up against a problem with a program I’m writing and I can’t
see what’s causing it.

Basically I’m allocating memory for a load of data blocks, the first one
allocates fine but the second one causes a segment violation within the
malloc( ) function.

I’ve tried adding some calls to _heapchk( ) and _heapwalk( ) to debug
the program but it now dies in the _heapwalk( ) call just before the
malloc( ), i.e. the same error is happening but in a different library
call.

I’m using QNX 4.25 and Watcom C 10.6.

Kevin.

Previously, Kevin O’Rourke wrote in qdn.public.qnx4:

I tried that, _heapchk reports that everything is fine and if I try to
use _heapwalk to go through the heap listing nodes it dies instead of
malloc( ).

The bug is not in malloc. Something in your code is:

  1. writing beyond the bounds of a previously malloc()ed block,
  2. writing prior to the start of a block,
  3. writing into random memory,
  4. free()ing a memory block more than once,
  5. free()ing a memory address that was not the return value from
    malloc(),
  6. free()ing memory and then continuing to use it.

[Anybody want to add to this list?]

The next time malloc encounters this corrupted memory area (usually
not for many calls to malloc after the damage occurs), it crashes.
Malloc() normally assumes that memory is not corrupt and does not
attempt to detect or handle corruption. This is a hard problem to
solve, but it is one that everybody faces, regularly, and it is never,
ever, the fault of malloc.

One way to deal with this is to get a different malloc()
implementation that is designed specifically for finding memory
problems. If that is not an option, use the debugger - try to find
an area of memory that is getting corrupted, and place a watchpoint on
it to see where the corruption is occurring. This is tedious, but
better than just reading your code and guessing.

Good luck,
Andrew

you could put a c wrapper around malloc to ensure you are passing in values
okay…

another thing you could look at is a debuggable/tunable malloc that’s available
in /usr/free/tmp/ called libmalloc.tgz

that is a useful archive…

Kevin O’Rourke <kevin_i_orourke@hotmail.com> wrote:

Hi,

I’ve come up against a problem with a program I’m writing and I can’t
see what’s causing it.

Basically I’m allocating memory for a load of data blocks, the first one
allocates fine but the second one causes a segment violation within the
malloc( ) function.

I’ve tried adding some calls to _heapchk( ) and _heapwalk( ) to debug
the program but it now dies in the _heapwalk( ) call just before the
malloc( ), i.e. the same error is happening but in a different library
call.

I’m using QNX 4.25 and Watcom C 10.6.

Kevin.


Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

I couldn’t find the file in /usr/free/tmp, found something called
libmalloc3r.tgz in /usr/free/qnx4/os/libs so I downloaded it. It
doesn’t seem to have any documentation though.

The thing that’s really confusing me is where I could possibly be going
wrong with a malloc call. Just doing a malloc(44) I can’t see any way
that I can be causing the crashes, it should either work or return NULL,
shouldn’t it?

Kev.


Randy Martin wrote:

you could put a c wrapper around malloc to ensure you are passing in values
okay…

another thing you could look at is a debuggable/tunable malloc that’s available
in /usr/free/tmp/ called libmalloc.tgz

that is a useful archive…

Kevin O’Rourke <> kevin_i_orourke@hotmail.com> > wrote:
Hi,

I’ve come up against a problem with a program I’m writing and I can’t
see what’s causing it.

Basically I’m allocating memory for a load of data blocks, the first one
allocates fine but the second one causes a segment violation within the
malloc( ) function.

I’ve tried adding some calls to _heapchk( ) and _heapwalk( ) to debug
the program but it now dies in the _heapwalk( ) call just before the
malloc( ), i.e. the same error is happening but in a different library
call.

I’m using QNX 4.25 and Watcom C 10.6.

Kevin.


Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

Perhaps the heap was corrupted before you made the malloc(44) call? There are
functions (heap*) for checking heap integrity, etc. that might be helpful.

Kevin O’Rourke wrote:

I couldn’t find the file in /usr/free/tmp, found something called
libmalloc3r.tgz in /usr/free/qnx4/os/libs so I downloaded it. It
doesn’t seem to have any documentation though.

The thing that’s really confusing me is where I could possibly be going
wrong with a malloc call. Just doing a malloc(44) I can’t see any way
that I can be causing the crashes, it should either work or return NULL,
shouldn’t it?

Kev.

Randy Martin wrote:

you could put a c wrapper around malloc to ensure you are passing in values
okay…

another thing you could look at is a debuggable/tunable malloc that’s available
in /usr/free/tmp/ called libmalloc.tgz

that is a useful archive…

Kevin O’Rourke <> kevin_i_orourke@hotmail.com> > wrote:
Hi,

I’ve come up against a problem with a program I’m writing and I can’t
see what’s causing it.

Basically I’m allocating memory for a load of data blocks, the first one
allocates fine but the second one causes a segment violation within the
malloc( ) function.

I’ve tried adding some calls to _heapchk( ) and _heapwalk( ) to debug
the program but it now dies in the _heapwalk( ) call just before the
malloc( ), i.e. the same error is happening but in a different library
call.

I’m using QNX 4.25 and Watcom C 10.6.

Kevin.


Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

I tried that, _heapchk reports that everything is fine and if I try to
use _heapwalk to go through the heap listing nodes it dies instead of
malloc( ).

Kev.

Dean Douthat wrote:

Perhaps the heap was corrupted before you made the malloc(44) call? There are
functions (heap*) for checking heap integrity, etc. that might be helpful.

Thanks for that, you prompted me to check how much memory I’m
allocating. I had added some members to the structure but had forgotten
to change the structure size calculation. As a result a later fread( )
was writing past the end of the malloc’ed memory.

Thanks to everyone who helped me out on this one and apologies for
wasting your time on such a stupid mistake. I think it’s time to go
home now before I cause any more damage.

Thanks again,
Kev.


Andrew Thomas wrote:

Previously, Kevin O’Rourke wrote in qdn.public.qnx4:
I tried that, _heapchk reports that everything is fine and if I try to
use _heapwalk to go through the heap listing nodes it dies instead of
malloc( ).

The bug is not in malloc. Something in your code is:

  1. writing beyond the bounds of a previously malloc()ed block,
  2. writing prior to the start of a block,
  3. writing into random memory,
  4. free()ing a memory block more than once,
  5. free()ing a memory address that was not the return value from
    malloc(),
  6. free()ing memory and then continuing to use it.

[Anybody want to add to this list?]

The next time malloc encounters this corrupted memory area (usually
not for many calls to malloc after the damage occurs), it crashes.
Malloc() normally assumes that memory is not corrupt and does not
attempt to detect or handle corruption. This is a hard problem to
solve, but it is one that everybody faces, regularly, and it is never,
ever, the fault of malloc.

One way to deal with this is to get a different malloc()
implementation that is designed specifically for finding memory
problems. If that is not an option, use the debugger - try to find
an area of memory that is getting corrupted, and place a watchpoint on
it to see where the corruption is occurring. This is tedious, but
better than just reading your code and guessing.

Good luck,
Andrew

Kevin O’Rourke <kio@pcmail.nerc-bas.ac.uk> wrote:

This is a multi-part message in MIME format.
--------------05F4909011CCEF3D7607AED9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for that, you prompted me to check how much memory I’m
allocating. I had added some members to the structure but had forgotten
to change the structure size calculation. As a result a later fread( )
was writing past the end of the malloc’ed memory.

The sizeof operator is very useful. Use it for allocation of memory for
structures.

-David

QNX Training Services
dagibbs@qnx.com

Also, when heapchk_ fails, try backing up through the control flow of your
program to where it succeeds. Then, trying half-way down or up, you can often
isolate the problem.

Kevin O’Rourke wrote:

Thanks for that, you prompted me to check how much memory I’m
allocating. I had added some members to the structure but had forgotten
to change the structure size calculation. As a result a later fread( )
was writing past the end of the malloc’ed memory.

Thanks to everyone who helped me out on this one and apologies for
wasting your time on such a stupid mistake. I think it’s time to go
home now before I cause any more damage.

Thanks again,
Kev.

Andrew Thomas wrote:

Previously, Kevin O’Rourke wrote in qdn.public.qnx4:
I tried that, _heapchk reports that everything is fine and if I try to
use _heapwalk to go through the heap listing nodes it dies instead of
malloc( ).

The bug is not in malloc. Something in your code is:

  1. writing beyond the bounds of a previously malloc()ed block,
  2. writing prior to the start of a block,
  3. writing into random memory,
  4. free()ing a memory block more than once,
  5. free()ing a memory address that was not the return value from
    malloc(),
  6. free()ing memory and then continuing to use it.

[Anybody want to add to this list?]

The next time malloc encounters this corrupted memory area (usually
not for many calls to malloc after the damage occurs), it crashes.
Malloc() normally assumes that memory is not corrupt and does not
attempt to detect or handle corruption. This is a hard problem to
solve, but it is one that everybody faces, regularly, and it is never,
ever, the fault of malloc.

One way to deal with this is to get a different malloc()
implementation that is designed specifically for finding memory
problems. If that is not an option, use the debugger - try to find
an area of memory that is getting corrupted, and place a watchpoint on
it to see where the corruption is occurring. This is tedious, but
better than just reading your code and guessing.

Good luck,
Andrew

“Andrew Thomas” <Andrew@cogent.ca> wrote in message
news:Voyager.010219124209.782377A@andrewhome.cogent.ca

Previously, Kevin O’Rourke wrote in qdn.public.qnx4:
I tried that, _heapchk reports that everything is fine and if I try to
use _heapwalk to go through the heap listing nodes it dies instead of
malloc( ).

The bug is not in malloc. Something in your code is:

  1. writing beyond the bounds of a previously malloc()ed block,
  2. writing prior to the start of a block,
  3. writing into random memory,
  4. free()ing a memory block more than once,
  5. free()ing a memory address that was not the return value from
    malloc(),
  6. free()ing memory and then continuing to use it.

[Anybody want to add to this list?]

very often mistake - overrunning local stack variables. i.e.

void abc(void) {
char text[4];
void ptr;
ptr = malloc(44);
/
/
strcpy(text,“1234”); /
remember the zero at the end of string !
/
/
… */
free(ptr);
};

i.e. pointer “ptr” value is corrupted by strcpy() due to invalid buffer
size.
this is the general case, local implementation depends on fantasy of the
implementator.

and so on.

The next time malloc encounters this corrupted memory area (usually
not for many calls to malloc after the damage occurs), it crashes.
Malloc() normally assumes that memory is not corrupt and does not
attempt to detect or handle corruption. This is a hard problem to
solve, but it is one that everybody faces, regularly, and it is never,
ever, the fault of malloc.

One way to deal with this is to get a different malloc()
implementation that is designed specifically for finding memory
problems. If that is not an option, use the debugger - try to find
an area of memory that is getting corrupted, and place a watchpoint on
it to see where the corruption is occurring. This is tedious, but
better than just reading your code and guessing.

Good luck,
Andrew


Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit www.novosoft-us.com

David Gibbs wrote:

Kevin O’Rourke <> kio@pcmail.nerc-bas.ac.uk> > wrote:
This is a multi-part message in MIME format.
--------------05F4909011CCEF3D7607AED9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for that, you prompted me to check how much memory I’m
allocating. I had added some members to the structure but had forgotten
to change the structure size calculation. As a result a later fread( )
was writing past the end of the malloc’ed memory.

The sizeof operator is very useful. Use it for allocation of memory for
structures.
Unfortunately it’s a variable-sized structure so sizeof wont work.

However I’ve moved the size calculation code all to one place now so all
the parts of the program should use the same size.

Kev.