|
From: Chris P. <jud...@gm...> - 2008-08-11 02:57:33
|
Hi, I've used valgrind successfully on a number of applications running on our embedded linux system and I'm now running into problems with one particular application. It is a huge 3rd party app which for legal reasons I can't disclose much about, but I can say that I makes use of a large number of real-time threads and some kernel-to-user shared memory. When I run it under valgrind I start getting some random failures (program failures not valgrind reporting). I'm currently putting this down to the fact that valgrind supplies its own pthread implementation. I really only want to use the malloc debugging features of memcheck so at this point I'm not interested in using the thread debugging of helgrind. I found an old post http://article.gmane.org/gmane.comp.debugging.valgrind/1447/ where someone had inadvertently turned this feature off. Does anyone know a way of turning of valgrind's thread library in a controlled fashion? Is this even a good idea? Thanks, Chris |
|
From: Bart V. A. <bar...@gm...> - 2008-08-11 06:16:56
|
On Mon, Aug 11, 2008 at 4:57 AM, Chris Packham <jud...@gm...> wrote: > I've used valgrind successfully on a number of applications running on our > embedded linux system and I'm now running into problems with one particular > application. It is a huge 3rd party app which for legal reasons I can't > disclose much about, but I can say that I makes use of a large number of > real-time threads and some kernel-to-user shared memory. > > When I run it under valgrind I start getting some random failures (program > failures not valgrind reporting). I'm currently putting this down to the > fact that valgrind supplies its own pthread implementation. > > I really only want to use the malloc debugging features of memcheck so at > this point I'm not interested in using the thread debugging of helgrind. I > found an old post > http://article.gmane.org/gmane.comp.debugging.valgrind/1447/ where someone > had inadvertently turned this feature off. > > Does anyone know a way of turning of valgrind's thread library in a > controlled fashion? Is this even a good idea? Which Valgrind version do you use, and which Valgrind tool do you use ? Bart. |
|
From: Felix S. <fel...@we...> - 2008-08-11 14:47:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear, is there any possibility for thread scheduling in valgrind? Do you have a tutorial or example, please? Regards fs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkigUP8ACgkQmH8OAwYoDBlHmQCgjwRnchjMNt00poTcarhTR/De VEoAoLTWKigioiCDFZN6q/SvoXhUX2vJ =fvVh -----END PGP SIGNATURE----- |
|
From: Chris P. <jud...@gm...> - 2008-08-11 22:53:41
|
I've used valgrind 3.2.3 and 3.3.1 both with the same result. I want to use memcheck but I'm not explicitly passing --tool=memcheck (from reading the documentation memcheck should be selected by default). On Mon, Aug 11, 2008 at 6:17 PM, Bart Van Assche <bar...@gm...>wrote: > On Mon, Aug 11, 2008 at 4:57 AM, Chris Packham <jud...@gm...> > wrote: > > I've used valgrind successfully on a number of applications running on > our > > embedded linux system and I'm now running into problems with one > particular > > application. It is a huge 3rd party app which for legal reasons I can't > > disclose much about, but I can say that I makes use of a large number of > > real-time threads and some kernel-to-user shared memory. > > > > When I run it under valgrind I start getting some random failures > (program > > failures not valgrind reporting). I'm currently putting this down to the > > fact that valgrind supplies its own pthread implementation. > > > > I really only want to use the malloc debugging features of memcheck so at > > this point I'm not interested in using the thread debugging of helgrind. > I > > found an old post > > http://article.gmane.org/gmane.comp.debugging.valgrind/1447/ where > someone > > had inadvertently turned this feature off. > > > > Does anyone know a way of turning of valgrind's thread library in a > > controlled fashion? Is this even a good idea? > > Which Valgrind version do you use, and which Valgrind tool do you use ? > > Bart. > |
|
From: Tom H. <to...@co...> - 2008-08-11 06:58:06
|
Chris Packham wrote: > When I run it under valgrind I start getting some random failures > (program failures not valgrind reporting). I'm currently putting this > down to the fact that valgrind supplies its own pthread implementation. Valgrind hasn't provided it's own pthread implementation for several years, so if you are really using a version has it's own libpthread then the first thing you need to do is upgrade. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Chris P. <jud...@gm...> - 2008-08-11 23:01:40
|
I read http://valgrind.org/docs/manual/manual-core.html#manual-core.pthreadsand interpreted this as valgrind supplies its own pthreads. "Valgrind schedules your program's threads in a round-robin fashion, with all threads having equal priority." I guess this means even if it doesn't supply its own pthreads implementation it does alter the scheduling. I concluded, perhaps erroneously, that threading was causing my problems. What I'm really after is any guidance on running valgrind with a memory and CPU constrained environment. On Mon, Aug 11, 2008 at 6:58 PM, Tom Hughes <to...@co...> wrote: > Chris Packham wrote: > > When I run it under valgrind I start getting some random failures (program >> failures not valgrind reporting). I'm currently putting this down to the >> fact that valgrind supplies its own pthread implementation. >> > > Valgrind hasn't provided it's own pthread implementation for several years, > so if you are really using a version has it's own libpthread then the first > thing you need to do is upgrade. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > |
|
From: Tom H. <to...@co...> - 2008-08-11 23:45:37
|
In message <a03...@ma...>
"Chris Packham" <jud...@gm...> wrote:
> I read http://valgrind.org/docs/manual/manual-core.html#manual-core.pthreadsand
> interpreted this as valgrind supplies its own pthreads.
>
> "Valgrind schedules your program's threads in a round-robin fashion, with
> all threads having equal priority." I guess this means even if it doesn't
> supply its own pthreads implementation it does alter the scheduling.
>
> I concluded, perhaps erroneously, that threading was causing my problems.
> What I'm really after is any guidance on running valgrind with a memory and
> CPU constrained environment.
No, what that is saying is that valgrind effectively overrides the
kernel's normal scheduling of the threads and forces them to execute
one at a time in round-robin fashion.
Valgrind does not (these days) replace libpthread, nor does it alter
the mapping between user and kernel threads. There is still one kernel
thread for each pthread you create - the only change is the order in
which they execute and how many may execute at once.
If your program is reliant on the order in which threads execute or how
many threads execute at once then it is, by definition, broken.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Chris P. <jud...@gm...> - 2008-08-11 23:59:28
|
On Tue, Aug 12, 2008 at 11:45 AM, Tom Hughes <to...@co...> wrote: > Valgrind does not (these days) replace libpthread, nor does it alter > the mapping between user and kernel threads. There is still one kernel > thread for each pthread you create - the only change is the order in > which they execute and how many may execute at once. OK, I understand this now. If your program is reliant on the order in which threads execute or how > many threads execute at once then it is, by definition, broken. Yes its definitely not in a good state. I was just hoping not to have to deal with the threading issues at this point. I guess I may just have to fix those first. |
|
From: Chris P. <jud...@gm...> - 2008-08-12 00:50:33
|
On closer inspection I don't think the current error I'm seeing is a threading problem. There is some process monitoring SW on our system that is used to start the app in question and expects a callback within a period of time, which with valgrind is well and truly exceeded and the app is started multiple times, causing my error. Now I just need to figure out where to extend that timeout... On Tue, Aug 12, 2008 at 11:59 AM, Chris Packham <jud...@gm...>wrote: > On Tue, Aug 12, 2008 at 11:45 AM, Tom Hughes <to...@co...> wrote: > >> Valgrind does not (these days) replace libpthread, nor does it alter >> the mapping between user and kernel threads. There is still one kernel >> thread for each pthread you create - the only change is the order in >> which they execute and how many may execute at once. > > > OK, I understand this now. > > If your program is reliant on the order in which threads execute or how >> many threads execute at once then it is, by definition, broken. > > > Yes its definitely not in a good state. I was just hoping not to have to > deal with the threading issues at this point. I guess I may just have to fix > those first. > |