|
Home > Archive > Unix Programming > July 2004 > posix threads
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| pradeep 2004-07-19, 7:52 am |
| 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 ()
| |
| Nils O. Selåsdal 2004-07-19, 5:57 pm |
| 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..)
| |
| Paul Pluzhnikov 2004-07-19, 5:57 pm |
| "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.
| |
| Casper H.S. Dik 2004-07-19, 5:57 pm |
| 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.
|
|
|
|
|