malloc failed

QNX Newsgroups (Archives) qdn.public.qnxrtp.newuser
1

We have a program that ran on x86, it took core dump on executing
malloc(1088). The core dump stack shows as following:

#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
#1 0xb031a524 in _list_alloc () from /x86/lib/libc.so.2
#2 0xb031aa45 in malloc () from /x86/lib/libc.so.2
#3 0xb8224dd8 in get_cert_auth () from /root/dmgr.so
#4 0xb822506f in auth_thread () from /root/dmgr.so

Could anyone help me understand what does this mean?

If I change the code to allocate smaller size of memory,
( i.e… malloc(100) ) it works fine.

Is this an alignment problem? I thought on x86 there is no alignment
problem.

Appreciate any help.

-Beth

2

A problem like that can occur is you have a head corruption. A heap
corruption typically occurs when you write beyond your allocated segments.
Typically the way I debug heap corrupt is to create a small function or
method that looks like this:


#define LARGE_HEAP_SEGMENT 2048

void TestHeap( char* filename, int lineno )
{
printf(“Testing heap in: [%s:%d]…”, filename, lineno);

unsigned char* pData = malloc(LARGE_HEAP_SEGMENT);
if ( pData ) {
free pData;
printf(“OK!\n”);
} else {
printf(“Failed to malloc\n”);
}
}


And then start scattering calls to TestHeap() through out your code:

main()
{
TestHeap(FILE, LINE);
…
TestHeap(FILE, LINE);
…
}

Then you should see the system cause a core dump somewhere after the point
where you cause the heap corruption.

Another option is to try to use Electric Fence library to see if it will
detect your heap corruption. You can find a QNX compiled version of efence
here:

http://sourceforge.net/projects/openqnx

–
Jens



“Beth” <id@address.com> wrote in message
news:3EC3F0E4.12455594@address.com…

We have a program that ran on x86, it took core dump on executing
malloc(1088). The core dump stack shows as following:

#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
#1 0xb031a524 in _list_alloc () from /x86/lib/libc.so.2
#2 0xb031aa45 in malloc () from /x86/lib/libc.so.2
#3 0xb8224dd8 in get_cert_auth () from /root/dmgr.so
#4 0xb822506f in auth_thread () from /root/dmgr.so

Could anyone help me understand what does this mean?

If I change the code to allocate smaller size of memory,
( i.e… malloc(100) ) it works fine.

Is this an alignment problem? I thought on x86 there is no alignment
problem.

Appreciate any help.

-Beth

3

“Jens H Jorgensen” <jhj@remove-nospam-videk.com> wrote in message
news:ba0ro8$4cv$1@inn.qnx.com…

A problem like that can occur is you have a head corruption. A heap

^^^^^^^^^^^
heap

corruption typically occurs when you write beyond your allocated segments.
Typically the way I debug heap corrupt is to create a small function or
method that looks like this:


#define LARGE_HEAP_SEGMENT 2048

void TestHeap( char* filename, int lineno )
{
printf(“Testing heap in: [%s:%d]…”, filename, lineno);

unsigned char* pData = malloc(LARGE_HEAP_SEGMENT);
if ( pData ) {
free pData;
printf(“OK!\n”);
} else {
printf(“Failed to malloc\n”);
}
}


And then start scattering calls to TestHeap() through out your code:

main()
{
TestHeap(FILE, LINE);
…
TestHeap(FILE, LINE);
…
}

Then you should see the system cause a core dump somewhere after the point
where you cause the heap corruption.

Another option is to try to use Electric Fence library to see if it will
detect your heap corruption. You can find a QNX compiled version of efence
here:

http://sourceforge.net/projects/openqnx

–
Jens



“Beth” <> id@address.com> > wrote in message
news:> 3EC3F0E4.12455594@address.com> …
We have a program that ran on x86, it took core dump on executing
malloc(1088). The core dump stack shows as following:

#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
#1 0xb031a524 in _list_alloc () from /x86/lib/libc.so.2
#2 0xb031aa45 in malloc () from /x86/lib/libc.so.2
#3 0xb8224dd8 in get_cert_auth () from /root/dmgr.so
#4 0xb822506f in auth_thread () from /root/dmgr.so

Could anyone help me understand what does this mean?

If I change the code to allocate smaller size of memory,
( i.e… malloc(100) ) it works fine.

Is this an alignment problem? I thought on x86 there is no alignment
problem.

Appreciate any help.

-Beth

4

Thanks for your help. I used your TestHeap function saw the core dump with
malloc() right where my call to malloc() was failed. Does that prove I have heap
corruption? If I do, how do I correct this problem?

-Beth

Jens H Jorgensen wrote:

“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:ba0ro8$4cv$> 1@inn.qnx.com> …
A problem like that can occur is you have a head corruption. A heap

^^^^^^^^^^^
heap

corruption typically occurs when you write beyond your allocated segments.
Typically the way I debug heap corrupt is to create a small function or
method that looks like this:


#define LARGE_HEAP_SEGMENT 2048

void TestHeap( char* filename, int lineno )
{
printf(“Testing heap in: [%s:%d]…”, filename, lineno);

unsigned char* pData = malloc(LARGE_HEAP_SEGMENT);
if ( pData ) {
free pData;
printf(“OK!\n”);
} else {
printf(“Failed to malloc\n”);
}
}


And then start scattering calls to TestHeap() through out your code:

main()
{
TestHeap(FILE, LINE);
…
TestHeap(FILE, LINE);
…
}

Then you should see the system cause a core dump somewhere after the point
where you cause the heap corruption.

Another option is to try to use Electric Fence library to see if it will
detect your heap corruption. You can find a QNX compiled version of efence
here:

http://sourceforge.net/projects/openqnx

–
Jens



“Beth” <> id@address.com> > wrote in message
news:> 3EC3F0E4.12455594@address.com> …
We have a program that ran on x86, it took core dump on executing
malloc(1088). The core dump stack shows as following:

#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
#1 0xb031a524 in _list_alloc () from /x86/lib/libc.so.2
#2 0xb031aa45 in malloc () from /x86/lib/libc.so.2
#3 0xb8224dd8 in get_cert_auth () from /root/dmgr.so
#4 0xb822506f in auth_thread () from /root/dmgr.so

Could anyone help me understand what does this mean?

If I change the code to allocate smaller size of memory,
( i.e… malloc(100) ) it works fine.

Is this an alignment problem? I thought on x86 there is no alignment
problem.

Appreciate any help.

-Beth

5

“Beth” <id@address.com> wrote in message
news:3ECBFBC2.15D98DDB@address.com…

Thanks for your help. I used your TestHeap function saw the core dump with
malloc() right where my call to malloc() was failed. Does that prove I
have heap
corruption? If I do, how do I correct this problem?

Place a bunch of call of TestHeap throughout your program. This should
allow you to “zoom in” on when the heap corruption problem occurs. You
coula also look at debug malloc library that put cookies around memory block
to help detect overrun and underrun.

-Beth

Jens H Jorgensen wrote:

“Jens H Jorgensen” <> jhj@remove-nospam-videk.com> > wrote in message
news:ba0ro8$4cv$> 1@inn.qnx.com> …
A problem like that can occur is you have a head corruption. A heap


^^^^^^^^^^^

heap

corruption typically occurs when you write beyond your allocated
segments.
Typically the way I debug heap corrupt is to create a small function
or
method that looks like this:


#define LARGE_HEAP_SEGMENT 2048

void TestHeap( char* filename, int lineno )
{
printf(“Testing heap in: [%s:%d]…”, filename, lineno);

unsigned char* pData = malloc(LARGE_HEAP_SEGMENT);
if ( pData ) {
free pData;
printf(“OK!\n”);
} else {
printf(“Failed to malloc\n”);
}
}


And then start scattering calls to TestHeap() through out your code:

main()
{
TestHeap(FILE, LINE);
…
TestHeap(FILE, LINE);
…
}

Then you should see the system cause a core dump somewhere after the
point
where you cause the heap corruption.

Another option is to try to use Electric Fence library to see if it
will
detect your heap corruption. You can find a QNX compiled version of
efence
here:

http://sourceforge.net/projects/openqnx

–
Jens



“Beth” <> id@address.com> > wrote in message
news:> 3EC3F0E4.12455594@address.com> …
We have a program that ran on x86, it took core dump on executing
malloc(1088). The core dump stack shows as following:

#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb031a332 in _list_memalign () from /x86/lib/libc.so.2
#1 0xb031a524 in _list_alloc () from /x86/lib/libc.so.2
#2 0xb031aa45 in malloc () from /x86/lib/libc.so.2
#3 0xb8224dd8 in get_cert_auth () from /root/dmgr.so
#4 0xb822506f in auth_thread () from /root/dmgr.so

Could anyone help me understand what does this mean?

If I change the code to allocate smaller size of memory,
( i.e… malloc(100) ) it works fine.

Is this an alignment problem? I thought on x86 there is no alignment
problem.

Appreciate any help.

-Beth
\