|
From: Ron K. <ro...@ko...> - 2006-01-07 19:49:08
|
Hi,
I'm having trouble with pthreads even with the simplest program. I'm using
valgrind 3.1.0 on debian sarge using linux-2.4.26.
Even this simple "textbook" program causes problems:
#include <pthread.h>
void * threadhandler(void * ptr) {
sleep(2);
pthread_exit(0);
}
int main() {
pthread_t thread;
pthread_create(&thread, NULL, &threadhandler, NULL);
pthread_join(thread, NULL);
return 0;
}
I compile it like this: gcc -lpthread -ggdb ./main.c
The errors that this tiny program cause in valgrind are appended to the
bottom of this message. I don't have a clue what the problem could be. I saw
that valgrind has good pthread support, and I've searched google but I just
can't seem to find anyone with the same problem. Does anybody have any clue
what could be going on?
Thank you,
Ron Korving
==17229== Memcheck, a memory error detector.
==17229== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==17229== Using LibVEX rev 1471, a library for dynamic binary translation.
==17229== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==17229== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==17229== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==17229== For more details, rerun with: -v
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x402DC6A: pthread_create@@GLIBC_2.1 (in
/lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF8B0 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF9AC is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484E7: main (main.c:15)
==17229== Address 0xBEFFF9A4 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x40A2B61: exit (in /lib/libc-2.3.2.so)
==17229== by 0x408CE3D: __libc_start_main (in /lib/libc-2.3.2.so)
==17229== Address 0xBEFFF99C is on thread 1's stack
==17229==
==17229== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 13 from 1)
==17229== malloc/free: in use at exit: 8,160 bytes in 1 blocks.
==17229== malloc/free: 1 allocs, 0 frees, 8,160 bytes allocated.
==17229== For counts of detected errors, rerun with: -v
==17229== searching for pointers to 1 not-freed blocks.
==17229== checked 353,728 bytes.
==17229==
==17229== LEAK SUMMARY:
==17229== definitely lost: 8,160 bytes in 1 blocks.
==17229== possibly lost: 0 bytes in 0 blocks.
==17229== still reachable: 0 bytes in 0 blocks.
==17229== suppressed: 0 bytes in 0 blocks.
==17229== Use --leak-check=full to see details of leaked memory.
|
|
From: Ron K. <ro...@ko...> - 2006-01-07 18:41:03
|
Hi,
I'm having trouble with pthreads even with the simplest program. I'm using
valgrind 3.1.0 on debian sarge using linux-2.4.26.
Even this simple "textbook" program causes problems:
#include <pthread.h>
void * threadhandler(void * ptr) {
sleep(2);
pthread_exit(0);
}
int main() {
pthread_t thread;
pthread_create(&thread, NULL, &threadhandler, NULL);
pthread_join(thread, NULL);
return 0;
}
I compile it like this: gcc -lpthread -ggdb ./main.c
The errors that this tiny program cause in valgrind are appended to the
bottom of this message. I don't have a clue what the problem could be. I saw
that valgrind has good pthread support, and I've searched google but I just
can't seem to find anyone with the same problem. Does anybody have any clue
what could be going on?
Thank you,
Ron Korving
==17229== Memcheck, a memory error detector.
==17229== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==17229== Using LibVEX rev 1471, a library for dynamic binary translation.
==17229== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==17229== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==17229== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==17229== For more details, rerun with: -v
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x402DC6A: pthread_create@@GLIBC_2.1 (in
/lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF8B0 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484D4: main (main.c:13)
==17229== Address 0xBEFFF9AC is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x80484E7: main (main.c:15)
==17229== Address 0xBEFFF9A4 is on thread 1's stack
==17229==
==17229== Syscall param write(buf) points to uninitialised byte(s)
==17229== at 0x4031A3B: write (in /lib/libpthread-0.10.so)
==17229== by 0x40A2B61: exit (in /lib/libc-2.3.2.so)
==17229== by 0x408CE3D: __libc_start_main (in /lib/libc-2.3.2.so)
==17229== Address 0xBEFFF99C is on thread 1's stack
==17229==
==17229== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 13 from 1)
==17229== malloc/free: in use at exit: 8,160 bytes in 1 blocks.
==17229== malloc/free: 1 allocs, 0 frees, 8,160 bytes allocated.
==17229== For counts of detected errors, rerun with: -v
==17229== searching for pointers to 1 not-freed blocks.
==17229== checked 353,728 bytes.
==17229==
==17229== LEAK SUMMARY:
==17229== definitely lost: 8,160 bytes in 1 blocks.
==17229== possibly lost: 0 bytes in 0 blocks.
==17229== still reachable: 0 bytes in 0 blocks.
==17229== suppressed: 0 bytes in 0 blocks.
==17229== Use --leak-check=full to see details of leaked memory.
|
|
From: Paul P. <ppl...@gm...> - 2006-01-08 01:52:44
|
On 1/7/06, Ron Korving <ro...@ko...> wrote: > I'm having trouble with pthreads even with the simplest program. I'm usin= g > valgrind 3.1.0 on debian sarge using linux-2.4.26. ... > I compile it like this: gcc -lpthread -ggdb ./main.c The link line above is incorrect (though it just happens to work). Correct build line is: gcc -pthread -ggdb main.c You may wish to read this if you want to understand why "-lpthread" doesn't belong where you've put it: http://webpages.charter.net/ppluzhnikov/linker.html > The errors that this tiny program cause in valgrind are appended to the > bottom of this message. These are "normal" for LinuxThreads. > I don't have a clue what the problem could be. There isn't really a problem. LinuxThreads does this: struct pthread_request { ... enum { ... } req_kind; union { ... fields that depend on req_kind }; }; struct pthread_request req; req.req_kind =3D ...; // code that fills some, *but not all* of the other fields write(pipe_to_thread_manager, &req, sizeof(req)); // triggers: > =3D=3D17229=3D=3D Syscall param write(buf) points to uninitialised byte(s= ) because some of the bytes in req are uninitialized. Cheers, |
|
From: John R.
|
> There isn't really a problem. LinuxThreads does this:
>
> struct pthread_request {
> ...
> enum { ... } req_kind;
> union { ... fields that depend on req_kind };
> };
>
> struct pthread_request req;
> req.req_kind = ...;
>
> // code that fills some, *but not all* of the other fields
>
> write(pipe_to_thread_manager, &req, sizeof(req)); // triggers:
>
>
>>==17229== Syscall param write(buf) points to uninitialised byte(s)
>
>
> because some of the bytes in req are uninitialized.
So, you can safely write a suppression for this error.
If you want to adjust libpthread itself so that it never
uses uninit bytes, then see
http://bitwagon.com/glibc-audit/glibc-audit.html
for suitable patches. In this case, the fix uses
memset(&req, 0, sizeof(req)); /* 2003-04-15 be kind to auditors */
shortly after declaration but before any assignments to the struct.
Besides eliminating the message from memcheck, the change also
observes proper hygiene with respect to information leaks
from the stack of one thread to another thread.
--
|
|
From: Ron K. <ro...@ko...> - 2006-01-08 07:28:00
|
Awesome, thank you very much guys. I really want to suppress these issues,
which I think is the easiest step here. I could use an edited libpthread,
but I'd need to do that on every machine I was compiling on. I have no clue
how to suppress these errors yet, but I'm sure the manual has plenty to say
about that. I do hope that these suppression configurations suppress a kind
of problem, and not one instance of a problem, because then I'd have to keep
suppressing new errors every time I use a pthread function. In that case I'd
be better of using glibc-audit. I wonder why the patches in glibc-audit
haven't been made final in glibc? But that's probably a subject that's not
meant for this mailinglist.
Anyway, thanks a lot guys, you've really helped out a lot.
Ron
"John Reiser" <jreiser@BitWagon.com> wrote in message
news:43C08114.305@BitWagon.com...
> > There isn't really a problem. LinuxThreads does this:
> >
> > struct pthread_request {
> > ...
> > enum { ... } req_kind;
> > union { ... fields that depend on req_kind };
> > };
> >
> > struct pthread_request req;
> > req.req_kind = ...;
> >
> > // code that fills some, *but not all* of the other fields
> >
> > write(pipe_to_thread_manager, &req, sizeof(req)); // triggers:
> >
> >
> >>==17229== Syscall param write(buf) points to uninitialised byte(s)
> >
> >
> > because some of the bytes in req are uninitialized.
>
> So, you can safely write a suppression for this error.
> If you want to adjust libpthread itself so that it never
> uses uninit bytes, then see
> http://bitwagon.com/glibc-audit/glibc-audit.html
> for suitable patches. In this case, the fix uses
> memset(&req, 0, sizeof(req)); /* 2003-04-15 be kind to auditors */
> shortly after declaration but before any assignments to the struct.
> Besides eliminating the message from memcheck, the change also
> observes proper hygiene with respect to information leaks
> from the stack of one thread to another thread.
>
> --
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
|
|
From: Ron K. <ro...@ko...> - 2006-01-08 07:55:32
|
I read the glibc-audit page which answers that very question. Thank you, Ron "Ron Korving" <ro...@ko...> wrote in message news:dpqeti$9eu$1...@se...... ... > I wonder why the patches in glibc-audit > haven't been made final in glibc? But that's > probably a subject that's not > meant for this mailinglist. ... |