|
From: Peter S. <sei...@ci...> - 2005-03-20 12:20:48
|
The following short test proramm produces a lot of output
when running under valgrind-2.4.0.rc4 (on debiab-3.0, but similar on
SuSE-8.2). Is this a valgrind or a libc/libpthread problem?
#include <stdlib.h>
#include <pthread.h>
void *thread(void *args) {
return NULL;
}
int main(int argc, char *argv[]) {
pthread_t th;
pthread_create(&th, NULL, thread, NULL);
pthread_join(th, NULL);
return 0;
}
$ gcc -Wall -g -pthread valgrind_pthread.c
$ valgrind ./a.out
==22241== Memcheck, a memory error detector for x86-linux.
==22241== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==22241== Using valgrind-2.4.0.rc4, a program supervision framework for x86-linux.
==22241== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==22241== For more details, rerun with: -v
==22241==
==22241== Conditional jump or move depends on uninitialised value(s)
==22241== at 0x1B991DA9: strstr (in /lib/libc-2.2.5.so)
==22241== by 0x1B910ADA: is_smp_system (in /lib/libpthread-0.9.so)
==22241== by 0x1B910CC0: pthread_initialize (in /lib/libpthread-0.9.so)
==22241== by 0x1B915DB6: (within /lib/libpthread-0.9.so)
==22241== by 0x1B90CC65: (within /lib/libpthread-0.9.so)
==22241== by 0x1B8EDCC6: call_init (in /lib/ld-2.2.5.so)
==22241== by 0x1B8EDD58: _dl_init (in /lib/ld-2.2.5.so)
==22241== by 0x1B8E5310: (within /lib/ld-2.2.5.so)
==22241==
==22241== Syscall param write(buf) points to uninitialised byte(s)
==22241== at 0x1B9E1404: write (in /lib/libc-2.2.5.so)
==22241== by 0x80484A3: main (valgrind_pthread.c:10)
==22241== Address 0x52BFEBE4 is on thread 1's stack
==22241==
==22241== Syscall param write(buf) points to uninitialised byte(s)
==22241== at 0x1B9E1404: write (in /lib/libc-2.2.5.so)
==22241== by 0x80484B4: main (valgrind_pthread.c:11)
==22241== Address 0x52BFEBD0 is on thread 1's stack
==22241==
==22241== Syscall param write(buf) points to uninitialised byte(s)
==22241== at 0x1B9E1404: write (in /lib/libc-2.2.5.so)
==22241== by 0x1B949E52: exit (in /lib/libc-2.2.5.so)
==22241== by 0x1B937154: __libc_start_main (in /lib/libc-2.2.5.so)
==22241== by 0x80483C0: (within /home/seiderer/test/a.out)
==22241== Address 0x52BFEBD0 is on thread 1's stack
==22241==
==22241== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 6 from 3)
==22241== malloc/free: in use at exit: 8160 bytes in 1 blocks.
==22241== malloc/free: 1 allocs, 0 frees, 8160 bytes allocated.
==22241== For counts of detected errors, rerun with: -v
==22241== searching for pointers to 1 not-freed blocks.
==22241== checked 98304 bytes.
==22241==
==22241== LEAK SUMMARY:
==22241== definitely lost: 8160 bytes in 1 blocks.
==22241== possibly lost: 0 bytes in 0 blocks.
==22241== still reachable: 0 bytes in 0 blocks.
==22241== suppressed: 0 bytes in 0 blocks.
==22241== Use --leak-check=full to see details of leaked memory.
$ cat /etc/debian_version
3.0
$ /lib/libc.so.6
GNU C Library stable release version 2.2.5, by Roland McGrath et al.
Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease).
Compiled on a Linux 2.4.18 system on 2005-01-07.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.9 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bu...@gn...>.
--
------------------------------------------------------------------------
Peter Seiderer E-Mail: sei...@ci...
|
|
From: Tom H. <to...@co...> - 2005-03-20 12:44:20
|
In message <200...@li...te>
Peter Seiderer <sei...@ci...> wrote:
> The following short test proramm produces a lot of output
> when running under valgrind-2.4.0.rc4 (on debiab-3.0, but similar on
> SuSE-8.2). Is this a valgrind or a libc/libpthread problem?
They are features of the pthread library you are using. The first one
can be suppressed and is for many version of the pthread library but
the supression obviously doesn'y match on your system.
The other's can't really be suppressed because the stack trace isn't
good enough to blame the threading library so any supression would be
far too general.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|