I have a problem with malloc in pthreads.
This is the function where my pthread is starting execution.
But the program is receiving SIGKILL within library routine malloc and
finally the program exits with Segmentation fault dumping the core.


void *start(void *args)
{
int clifd=*((int *)args);
struct tm *tm1;
time_t t;
char buff[100];
char* buff1;
fd_set set;
int bytes;

printf("---Helo---\n");
srand(time(NULL));
buff1 = (char*) calloc(100,1);
printf("---Helo-1-\n");
if ( !buff1 ) {
perror("malloc:");
exit(-1);
}
.....
}

This is the error i'm getting while backtracing in gdb.

#0  0xff1c1d3c in _malloc_unlocked () from /usr/lib/libc.so.1
#1  0xff1c1c48 in malloc () from /usr/lib/libc.so.1
#2  0xff1b60ec in calloc () from /usr/lib/libc.so.1
#3  0x115c4 in start ()

[ Post a follow-up to this message ]

On Mon, 19 Jul 2004 06:28:03 -0700, pradeep wrote:

> I have a problem with malloc in pthreads.
> This is the function where my pthread is starting execution.
> But the program is receiving SIGKILL within library routine malloc and
> finally the program exits with Segmentation fault dumping the core.
>
>
> void *start(void *args)
> {
> int clifd=*((int *)args);
> struct tm *tm1;
> time_t t;
> char buff[100];
> char* buff1;
> fd_set set;
> int bytes;
>
> printf("---Helo---\n");
> srand(time(NULL));
> buff1 = (char*) calloc(100,1);
> printf("---Helo-1-\n");
> if ( !buff1 ) {
> perror("malloc:");
> exit(-1);
> }
> .....
> }
>
> This is the error i'm getting while backtracing in gdb.
What system is this on ? (does the system have native threading
support, or like e.g. NetBSD 1.x do not, and uses e.g. GNU Pth but
have no native treadsafe malloc..)

[ Post a follow-up to this message ]

"pradeep" <pradeep_pvk@yahoo.co.in> writes:

> But the program is receiving SIGKILL within library routine malloc and
> finally the program exits with Segmentation fault dumping the core.
...
> This is the error i'm getting while backtracing in gdb.
>
> #0  0xff1c1d3c in _malloc_unlocked () from /usr/lib/libc.so.1
> #1  0xff1c1c48 in malloc () from /usr/lib/libc.so.1
> #2  0xff1b60ec in calloc () from /usr/lib/libc.so.1
> #3  0x115c4 in start ()
>

From the info you supplied, one can deduce that you are on Solaris.

Any crash inside heap routines indicates with 99.999% certainty
that you have corrupted heap at some point (possibly long time)
before crash, by either free()ing the same memory twice, writing
to already free()d blocks, or simply writing past the end of a
malloc()ed block.

There are free:
ccmalloc, dmalloc, mpatrol, efence
and commercial:
Purify, Insure++
tools that can help you find such bugs.

Also, the latest versions of 'dbx' have pretty strong debug
facilities built in: search for RTC in dbx documentation.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[ Post a follow-up to this message ]

Paul Pluzhnikov <ppluzhnikov-nsp@charter.net> writes:

>From the info you supplied, one can deduce that you are on Solaris.

>Any crash inside heap routines indicates with 99.999% certainty
>that you have corrupted heap at some point (possibly long time)
>before crash, by either free()ing the same memory twice, writing
>to already free()d blocks, or simply writing past the end of a
>malloc()ed block.

>There are free:
>  ccmalloc, dmalloc, mpatrol, efence
>and commercial:
>  Purify, Insure++
>tools that can help you find such bugs.

And shipped with the OS (therefor free of charge):

libumem		(S9 update 2 or so)
watchmalloc

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]