You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(2) |
2
|
3
|
|
4
|
5
|
6
|
7
(7) |
8
(8) |
9
(1) |
10
|
|
11
|
12
(3) |
13
(5) |
14
(4) |
15
(5) |
16
(4) |
17
(1) |
|
18
|
19
(4) |
20
(12) |
21
(6) |
22
(3) |
23
(2) |
24
|
|
25
|
26
(2) |
27
(4) |
28
(2) |
29
(22) |
30
(10) |
31
(3) |
|
From: Nicolas R. <Nic...@hm...> - 2010-07-15 19:01:01
|
Sorry for the late answer,
yes it could be that but as far as I remember it used to work a few
weeks ago, with the same application but on a different platform.
I will try to run valgrind on different platforms and I will let you
know if it is working or not.
Thanks
Nicolas
On Jul 13, 2010, at 4:33 PM, Dave Goodell wrote:
> Is your application multithreaded? Thread scheduling under valgrind
> is very different from running normally. AFAIK, only one thread
> runs at a time, which can both slow down threaded applications
> substantially and also increase the chances of hitting a deadlock
> bug in your code.
>
> -Dave
>
> On Jul 13, 2010, at 2:54 PM CDT, Nicolas Rannou wrote:
>
>> Hello,
>>
>> I'm experimenting some issues using valgrind.
>>
>> I would like to perform a memory leaks checking in my application.
>> I do:
>> _________________________________________________________________
>>
>> $ valgrind -v --leak-check=full --track-origins=yes ./bin/gofigure &>
>> log.txt
>> __________________________________________________________________
>>
>> where ./bin/gofigure is my application, STATIC-DEBUG build, on ubuntu
>> 10.04 - 64 bits.
>>
>> If I launch this command, it will just get stuck and I have to exit
>> valgrind manually (I let it running for one night to make sure that
>> it
>> is not a time issue).
>> If I run the program without valgrind it works properly (it opens and
>> closes automatically).
>>
>> I'm using valgrind 3.6.0
>> _____________________
>>
>> $ valgrind --version
>> valgrind-3.6.0.SVN
>> _____________________
>>
>> It use to work with a previous version of valgrind and a previous
>> version of ubuntu... (I'm not sure about which ones)
>>
>> Did somebody already experienced this issue?
>> Do you have any suggestion about how to solve/track this issue?
>>
>> Thanks,
>>
>> Nicolas
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Juan C. M. S. <jua...@gm...> - 2010-07-15 17:49:44
|
Hello every one, I am interested on doing program profiling. Lackey was my start point, but I see some limitation that I want to overcome. I need guidance!!! First, Lackey counts loads, stores, and alu ops, differentiated by IR types; I wonder how I can get more details about i.e. ALU operations (for example: add, mult, div, etc.). BTW, if I am working with the valgrind's IR, can I profile the binary code? Valgrind's IR is machine independent? so can I profile a binary code that in essence is machine dependent? Second, the memory map (stack - heap - data - code). In Lackey, I can trace all the memory references. I know that the address is a virtual address; however, I wonder if there is a memory map - for example, segment code starts at 0x100000, stack starts at 0x800000, and so on. My idea is to profile all data memory accesses - data access from data segment, stack, or heap. Third, system call arguments. I also want to profile system calls. I want to collect information about the arguments (syscall-ID, and parameters). In Valgrind's IR represtation, are the system all arguments passed using the register files or using the stack? If the arguments are passed using the stack, each argument has a memory location; however, the number of arguments depend on the system call. Where I can find more details about system call, and how Valgrind handles them? I will appreciate if someone can point me out what documentation read, what function or tool I can use, etc. Thanks in advance, -- Juan Carlos |
|
From: Julian S. <js...@ac...> - 2010-07-15 09:50:06
|
This is being tracked at https://bugs.kde.org/show_bug.cgi?id=205241#c80 J On Wednesday, July 14, 2010, Dave MacLachlan wrote: > ... > --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed > d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 > --33662:0:aspacem ...: .... 01197c5000-0119bc4fff 4194304 rwx.. ....... > d=0x000 i=0 o=0 (.) m=. (none) > --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: > --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed > d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 > --33662:0:aspacem ...: .... 0119bc5000-0119fc4fff 4194304 rwx.. ....... > d=0x000 i=0 o=0 (.) m=. (none) > --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: > --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed > d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 > --33662:0:aspacem ...: .... 0119fc5000-0119fc5fff 4096 ---.. ....... > d=0x000 i=0 o=0 (.) m=. (none) > --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: > --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed > d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 > --33662:0:aspacem ...: .... 0119fc6000-011a047fff 532480 rw-.. ....... > d=0x000 i=0 o=0 (.) m=. (none) > --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: > --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed > d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 > --33662:0:aspacem ...: .... 011a048000-011a447fff 4194304 rwx.. ....... > d=0x000 i=0 o=0 (.) m=. (none) > --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: > --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed > d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 > --33662:0:aspacem ...: .... 011a448000-011a847fff 4194304 rwx.. ....... > d=0x000 i=0 o=0 (.) m=. (none) > --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: > --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed > d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 > --33662:0:aspacem ...: .... 011a848000-011ac10fff 3969024 rwx.. ....... > d=0x000 i=0 o=0 (.) m=. (none) > --33662:0:aspacem sync check at wqthread_hijack:0 (after): FAILED > > While running valgrind on my app, I'm seeing a pile of these. Could > somebody be kind enough to explain what it means to me, and is it > something I need to fix? > > Cheers, > Dave |
|
From: Dave M. <dma...@gm...> - 2010-07-14 20:16:28
|
... --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 --33662:0:aspacem ...: .... 01197c5000-0119bc4fff 4194304 rwx.. ....... d=0x000 i=0 o=0 (.) m=. (none) --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 --33662:0:aspacem ...: .... 0119bc5000-0119fc4fff 4194304 rwx.. ....... d=0x000 i=0 o=0 (.) m=. (none) --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 --33662:0:aspacem ...: .... 0119fc5000-0119fc5fff 4096 ---.. ....... d=0x000 i=0 o=0 (.) m=. (none) --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 --33662:0:aspacem ...: .... 0119fc6000-011a047fff 532480 rw-.. ....... d=0x000 i=0 o=0 (.) m=. (none) --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 --33662:0:aspacem ...: .... 011a048000-011a447fff 4194304 rwx.. ....... d=0x000 i=0 o=0 (.) m=. (none) --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 --33662:0:aspacem ...: .... 011a448000-011a847fff 4194304 rwx.. ....... d=0x000 i=0 o=0 (.) m=. (none) --33662:0:aspacem segment mismatch: V's seg 1st, kernel's 2nd: --33662:0:aspacem 571: file 0116c68000-011aaf7fff 62m r-xT- SmFixed d=0x12b0f1e4 i=639 o=85987328 (148) m=0 /dev/ttys002 --33662:0:aspacem ...: .... 011a848000-011ac10fff 3969024 rwx.. ....... d=0x000 i=0 o=0 (.) m=. (none) --33662:0:aspacem sync check at wqthread_hijack:0 (after): FAILED While running valgrind on my app, I'm seeing a pile of these. Could somebody be kind enough to explain what it means to me, and is it something I need to fix? Cheers, Dave |
|
From: Felix S. <sch...@go...> - 2010-07-14 18:09:58
|
Hi folks, I know that Valgrind is a analyze tool for binary code but is it possible to use Valgrind especially Cachegrind with a Java application? Does anybody has any experiences with Valgrind and Java? Thanks a lot Felix |
|
From: Pramod <akp...@gm...> - 2010-07-14 12:08:48
|
Bart Van Assche <bvanassche <at> acm.org> writes: > > On Mon, Jun 21, 2010 at 8:03 AM, Pramod <akpramod <at> gmail.com> wrote: > >> > >> On Fri, Jun 18, 2010 at 1:18 PM, Pramod <akpramod <at> gmail.com> wrote: > >> > > >> > I have cross-compiled valgrind 3.5.0 to work on MontaVista Linux. > >> > > >> > After installing (copied bin, lib, > > include directories to montavista machine), > > > >> > and running valgrind with no arguments, > > I get a core file from memcheck. > >> > > >> > Using GDB, I see that the core occurs at line 251 in mc_leakcheck.c. > >> > > > Thanks Bart for the reply. > > As mentioned in my original post: > > I have not provided any input arguments to > > valgrind when it dumped core. > > > > Also, I cross-compiled valgrind on host Solaris > > for MontaVista Linux target. > > The fact that Valgrind has been cross-compiled shouldn't affect its behavior. > > Sorry, I had overlooked that no input arguments were provided. You can > see what happens while Valgrind starts by running the following > command: > > valgrind -v -d -d > > Bart. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > I ran valgirnd -v -d -d and following is the output. It still fails at the same point. [flx208]-> ./valgrind -v -d -d --7131:1:debuglog DebugLog system started by Stage 1, level 2 logging requested --7131:1:launcher no tool requested, defaulting to 'memcheck' --7131:1:launcher no client specified, defaulting platform to 'x86-linux' --7131:1:launcher launching /home/vg/lib/valgrind/memcheck-x86-linux Segmentation fault (core dumped) I used the following command to configure valgrind. Also, I had to do some changes (hack) configure to run it for cross compilation environment. ./configure --host=x86_64-linux --build=sparc CXX=/opt/mvista/cge5.1_p2/monta vista/cge/devkit/x86/em64t/bin/em64t-g++ CPP=/opt/mvista/cge5.1_p2/montavista/cge/devkit/x86/em64t/bin/em64t-cpp CC=/opt/mvista/cge5.1_p2/montavista/cge/devkit/x86/em64t/bin/em64t-gcc --prefix="/home/vg" --disable-tls Please help me solve this crash of memcheck. |
|
From: Reyko S. <re...@gm...> - 2010-07-14 10:07:29
|
Dear Valgrind users,
I have a problem I don't understand. When using the helgrind tool I get the message that there was a possible data race right when I open the parallel region:
==9596== Possible data race during write of size 1 at 0x403bb60 by thread #1
==9596== at 0x4EC833: gomp_barrier_wait_end (bar.c:39)
==9596== by 0x4EBCAE: gomp_team_start (team.c:431)
==9596== by 0x40AF12: CVectorInversion::calculateKernelMatrix(unsigned int) (vectorFieldInversion.cpp:636)
==9596== by 0x4018C7: main (vectorInvTest.cpp:297)
==9596== This conflicts with a previous read of size 1 by thread #5
==9596== at 0x4EC8ED: gomp_barrier_wait (bar.h:75)
==9596== by 0x4EB820: gomp_thread_start (team.c:109)
==9596== by 0x4F478C: start_thread (pthread_create.c:297)
==9596== by 0x539A48: clone (clone.S:112)
the according code segment is:
636: #pragma omp parallel for private (vesh, nSH, m, p, result)
637: for (unsigned i=0; i<M; i++){
Can anyone tell me why there can be a data race when I open the parallel region?
Thanks,
Reyko
___________________________________________________________
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
|
|
From: Dave G. <go...@mc...> - 2010-07-13 20:33:40
|
Is your application multithreaded? Thread scheduling under valgrind is very different from running normally. AFAIK, only one thread runs at a time, which can both slow down threaded applications substantially and also increase the chances of hitting a deadlock bug in your code. -Dave On Jul 13, 2010, at 2:54 PM CDT, Nicolas Rannou wrote: > Hello, > > I'm experimenting some issues using valgrind. > > I would like to perform a memory leaks checking in my application. > I do: > _________________________________________________________________ > > $ valgrind -v --leak-check=full --track-origins=yes ./bin/gofigure &> > log.txt > __________________________________________________________________ > > where ./bin/gofigure is my application, STATIC-DEBUG build, on ubuntu > 10.04 - 64 bits. > > If I launch this command, it will just get stuck and I have to exit > valgrind manually (I let it running for one night to make sure that it > is not a time issue). > If I run the program without valgrind it works properly (it opens and > closes automatically). > > I'm using valgrind 3.6.0 > _____________________ > > $ valgrind --version > valgrind-3.6.0.SVN > _____________________ > > It use to work with a previous version of valgrind and a previous > version of ubuntu... (I'm not sure about which ones) > > Did somebody already experienced this issue? > Do you have any suggestion about how to solve/track this issue? > > Thanks, > > Nicolas > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicolas R. <nic...@hm...> - 2010-07-13 19:54:07
|
Hello,
I'm experimenting some issues using valgrind.
I would like to perform a memory leaks checking in my application.
I do:
_________________________________________________________________
$ valgrind -v --leak-check=full --track-origins=yes ./bin/gofigure &>
log.txt
__________________________________________________________________
where ./bin/gofigure is my application, STATIC-DEBUG build, on ubuntu
10.04 - 64 bits.
If I launch this command, it will just get stuck and I have to exit
valgrind manually (I let it running for one night to make sure that it
is not a time issue).
If I run the program without valgrind it works properly (it opens and
closes automatically).
I'm using valgrind 3.6.0
_____________________
$ valgrind --version
valgrind-3.6.0.SVN
_____________________
It use to work with a previous version of valgrind and a previous
version of ubuntu... (I'm not sure about which ones)
Did somebody already experienced this issue?
Do you have any suggestion about how to solve/track this issue?
Thanks,
Nicolas
|
|
From: Stephen M. <mo...@gm...> - 2010-07-13 18:15:50
|
Hi Josef, It was exactly what you said in that /opt/Adobe/Reader9/bin/acroread is a script that sets up the environment. I have modified this and now all is good. Sorry, I should of realised that before bothering you. I am using Ubuntu (64bit Lucid, 10.04) by the way. One issue I do have though is that the true acroread binary is 32bit. I attempted to re-compile valgrind with only 32bit support for a test but configure complained that I did not have all the requirements for the '--enable-only32bit' option. Do you know if this is fairly straightforward to do in Ubuntu? If not, I shall do the analysis in a 32bit vmware image. Many thanks again, Steve On 12 July 2010 21:30, Josef Weidendorfer <Jos...@gm...> wrote: > On Monday 12 July 2010, Stephen Mortimer wrote: > > Many thanks for your reply. I did try it without the -w option and get > the > > error: > > > > /tmp$ callgrind_control -s > > No active callgrind runs detected. > > [Detection can fail on some systems; to work around this, > > specify the working directory of a callgrind run with '-w'] > > What distro is this? You either have the proc filesystem not mounted > (see output of "mount" for a line with "proc on ..."; if this does not > exist, run as root "mount /proc"), or somehow permissions are not set > to let you access your own processes under /proc. > > Anyway... if you can not change this, you have to use "-w". > > > I assumed that the callgrind working directory would be the directory > that I > > run "valgrind --tool=callgrind acroread" (in this case /tmp). > > For "acroread", yes. However, if acroread is a script and forks/execs > subprocesses, > these are not automatically run within Valgrind/Callgrind, and you only can > control > the script with callgrind_control - however, this script probably will just > sleep > and wait for the termination of the children processes. > > To also run Callgrind for the child processes, use "--trace-children=yes" > (this is > a generic Valgrind option). > > > I have tried moving the mouse and opening a file via the menu and still > see > > no output from callgrind_control. > > > > I notice that there are a number of callgrind.info.[PID] files created in > > /tmp, example is: > > > > steve@pen1:/tmp$ cat callgrind.info.21987 > > # This file is generated by Callgrind-3.6.0.SVN. > > # It is used to enable controlling the supervision of > > # '/opt/Adobe/Reader9/bin/acroread' > > # by external tools. > > > > version: 1.0 > > base: /tmp > > dumps: /tmp/callgrind.out.21987 > > control: /tmp/callgrind.cmd.21987 > > result: /tmp/callgrind.res.21987 > > cmd: /opt/Adobe/Reader9/bin/acroread > > > > This would suggest that the working directory is /tmp? I tried pointing > > callgrind_control to /tmp but still get no output. > > Yes. > > Can you check whether /opt/Adobe/Reader9/bin/acroread is a ELF binary > are actually a wrapper script? It would be better to just run the real > binary with > Callgrind; any wrapper script usually just sets some environment variables, > which > you need to do yourself before running any real binary. > > > Have you any tips as the how to find the actual working directory? I am > > afraid I am not very familiar with ptrace. > > Using "ptrace" as control method is not implemented yet... > > Best, > Josef > > > > > Steve > > > > > > On 12 July 2010 10:46, Josef Weidendorfer <Jos...@gm...> > wrote: > > > > > On Monday 12 July 2010, Stephen Mortimer wrote: > > > > I am trying to use Callgrind to run determine the code coverage of a > > > large > > > > number of PDF files opened in Adobe Reader to then provide me with a > much > > > > smaller set of files that have unique code coverage. > > > > > > > > The method is as follows: > > > > > > > > 1. I run Adobe Reader in Valgrind with the Callgrind tool enabled. > > > > 2. Then open the first file. > > > > 3. Now run Callgrind_Control (callgrind_control -w /tmp/ -s) > > > > 4. Note the number of "Basic Blocks" > > > > 5. Now close that file and open another > > > > 6. Repeat steps 3 to 5 for each file and only keep files that show > new > > > Basic > > > > blocks have been hit > > > > > > Interesting. > > > When no new translated BBs show up, no new code was executed, yes. > > > > > > > The issue I have is that this works fine if I use evince to read the > > > files > > > > but when I run Adobe Reader in the callgrind tool, callgrind_control > does > > > > not give me any output, just hangs with the "[requesting Status]" > prompt: > > > > > > > > /tmp$ callgrind_control -w /tmp/ -s > > > > [requesting 'Status'...] > > > > > > The "-w" options is only a workaround if callgrind_control is not able > > > to detect the current working directory of the callgrind process (by > > > checking /proc/*/cwd). Usually, you should not need it. > > > > > > Communication between callgrind_control and the callgrind process is > done > > > by creating command and result files in the working dir of the > callgrind > > > process. > > > Callgrind regularily polls for commands, but only every X executed BBs > of > > > the > > > client program. > > > > > > So if callgrind_control hangs, it can have two causes: > > > (1) the client code waits in an OS calls, thus does not executed any > client > > > code, > > > which effectively suspends command polling. You have to trigger code > > > execution > > > somehow, eg. by moving the mouse pointer into the Adobe Reader window. > > > (2) the working directory of the callgrind process is not /tmp, as you > > > suspect. > > > Just try out without "-w" option first, and if this fails, try to > detect > > > the > > > working dir yourself, and use this as argument for -w. > > > > > > > I suspect that this is because Adobe Reader is opening a number of > > > processes > > > > when run, but the main process callgrind.out file does not contain > any > > > > output, all output goes into the other process files. > > > > > > Perhaps the process doing the actual work does not have /tmp as working > > > directory? > > > > > > Josef > > > > > > PS: Command file polling is not really the best way for controlling > > > callgrind > > > processes from the outside. A better way seems to be using ptrace. > > > > > > > > > > > /tmp$ ps -ef |grep Adobe > > > > steve 20800 4754 1 10:07 pts/2 00:00:01 > > > > /opt/Adobe/Reader9/Reader/intellinux/bin/acroread > > > > /tmp$ ls -ltrh > > > > total 448K > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20800 > > > > -rw------- 1 steve steve 68K 2010-07-12 10:07 callgrind.out.20802 > > > > -rw------- 1 steve steve 67K 2010-07-12 10:07 callgrind.out.20801 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20807 > > > > -rw------- 1 steve steve 73K 2010-07-12 10:07 callgrind.out.20810 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20815 > > > > -rw------- 1 steve steve 74K 2010-07-12 10:07 callgrind.out.20805 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20817 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20819 > > > > -rw------- 1 steve steve 76K 2010-07-12 10:07 callgrind.out.20821 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20824 > > > > -rw------- 1 steve steve 80K 2010-07-12 10:07 callgrind.out.20827 > > > > -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20828 > > > > -rw-r--r-- 1 steve steve 6 2010-07-12 10:07 callgrind.cmd > > > > > > > > > > > > Is there a way around this issue? > > > > > > > > Many thanks, > > > > Steve Mortimer > > > > > > > > > > > > > > > > > > |
|
From: Christoph M. <chr...@gm...> - 2010-07-13 17:49:47
|
Hi List,
I've compiled Valgrind/Helgrind r11212 for PowerPC which works fine,
exept that Helgrind is not able to read
any symbols of my test application ("racy_static"), which has been
compiled with:
${CXX} -Wall -Werror -pthread -o racy_static racy_static.cpp -ggdb
Of course the file is not stripped. file says:
racy_static: ELF 32-bit MSB executable, PowerPC or cisco 4500, version
1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.4.3,
not stripped
Valgrind has been compiled with:
./configure --host=powerpc-linux --prefix=/home/cmuellner/valgrind
make
make install
Here is what Helgrind says:
...
==14308== Helgrind, a thread error detector
==14308== Copyright (C) 2007-2010, and GNU GPL'd, by OpenWorks LLP et al.
==14308== Using Valgrind-3.6.0.SVN and LibVEX; rerun with -h for copyright info
==14308== Command: ./racy_static
==14308== Parent PID: 3029
==14308==
--14308--
--14308-- Valgrind options:
--14308-- --tool=helgrind
--14308-- --read-var-info=yes
--14308-- --log-file=valgrind.log
--14308-- -v
--14308-- Contents of /proc/version:
--14308-- Linux version 2.6.21-4022-TX (---@---) (gcc version 4.0.0
(DENX ELDK 4.1 4.0.0)) #17 Fri Jun 11 12:23:35 CEST 2010
--14308-- Arch and hwcaps: PPC32, ppc32-int-flt-GX
--14308-- Page sizes: currently 4096, max supported 65536
--14308-- Valgrind library directory: /home/cmuellner/valgrind/lib/valgrind
--14308-- Reading syms from /lib/ld-2.3.5.so (0x4000000)
--14308-- object doesn't have a symbol table
--14308-- Reading syms from /path/to/racy_static (0x10000000)
--14308-- WARNING: Serious error when reading debug info
--14308-- When reading debug info from /path/to/racy_static:
--14308-- Can't make sense of .sdata section mapping
...
I found a question [1] on this list regarding this problem, but no solution.
My compiler is:
/opt/eldk-4.1/usr/bin/ppc_4xxFP-gcc -v
Reading specs from /opt/eldk-4.1/usr/bin/../lib/gcc/powerpc-linux/4.0.0/specs
Target: powerpc-linux
Configured with:
/opt/eldk/build/ppc-2007-01-19/work/usr/src/denx/BUILD/crosstool-0.35/build/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux/gcc-4.0.0/configure
--target=powerpc-linux --host=i686-host_pc-linux-gnu
--prefix=/var/tmp/eldk.HzYZNd/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux
--with-headers=/var/tmp/eldk.HzYZNd/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux/powerpc-linux/include
--with-local-prefix=/var/tmp/eldk.HzYZNd/usr/crosstool/gcc-4.0.0-glibc-2.3.5-eldk/powerpc-linux/powerpc-linux
--disable-nls --enable-threads=posix --enable-symvers=gnu
--enable-languages=c,c++ --enable-shared --enable-c99
--enable-long-long --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)
Has anyone an idea how to fix this issue, without rebuilding/updating
the toolchain?
Thanks in advance,
Christoph
[1] http://article.gmane.org/gmane.comp.debugging.valgrind/9703
|
|
From: Stephen M. <mo...@gm...> - 2010-07-12 09:15:47
|
Hi, I am trying to use Callgrind to run determine the code coverage of a large number of PDF files opened in Adobe Reader to then provide me with a much smaller set of files that have unique code coverage. The method is as follows: 1. I run Adobe Reader in Valgrind with the Callgrind tool enabled. 2. Then open the first file. 3. Now run Callgrind_Control (callgrind_control -w /tmp/ -s) 4. Note the number of "Basic Blocks" 5. Now close that file and open another 6. Repeat steps 3 to 5 for each file and only keep files that show new Basic blocks have been hit The issue I have is that this works fine if I use evince to read the files but when I run Adobe Reader in the callgrind tool, callgrind_control does not give me any output, just hangs with the "[requesting Status]" prompt: /tmp$ callgrind_control -w /tmp/ -s [requesting 'Status'...] I suspect that this is because Adobe Reader is opening a number of processes when run, but the main process callgrind.out file does not contain any output, all output goes into the other process files. /tmp$ ps -ef |grep Adobe steve 20800 4754 1 10:07 pts/2 00:00:01 /opt/Adobe/Reader9/Reader/intellinux/bin/acroread /tmp$ ls -ltrh total 448K -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20800 -rw------- 1 steve steve 68K 2010-07-12 10:07 callgrind.out.20802 -rw------- 1 steve steve 67K 2010-07-12 10:07 callgrind.out.20801 -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20807 -rw------- 1 steve steve 73K 2010-07-12 10:07 callgrind.out.20810 -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20815 -rw------- 1 steve steve 74K 2010-07-12 10:07 callgrind.out.20805 -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20817 -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20819 -rw------- 1 steve steve 76K 2010-07-12 10:07 callgrind.out.20821 -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20824 -rw------- 1 steve steve 80K 2010-07-12 10:07 callgrind.out.20827 -rw------- 1 steve steve 0 2010-07-12 10:07 callgrind.out.20828 -rw-r--r-- 1 steve steve 6 2010-07-12 10:07 callgrind.cmd Is there a way around this issue? Many thanks, Steve Mortimer |
|
From: Nicholas N. <n.n...@gm...> - 2010-07-09 02:27:18
|
On Wed, Jul 7, 2010 at 4:08 PM, Joerg Bergmann <em...@jb...> wrote: > > I have a problem with valgrind since I did convert > my program to use long double instead double on > critical points. This is bug 197915: https://bugs.kde.org/show_bug.cgi?id=197915 80-bit FP could be implemented, it's largely a matter of grunt work to add the new type and all the relevant operations to VEX. People complain sporadically but rarely enough that nobody has done this work yet. Nick |
|
From: Stefan K. <en...@ho...> - 2010-07-08 11:36:38
|
On 08.07.2010 13:23, Konstantin Serebryany wrote: > The stack trace from gdb suggests that your program is blocked on > pthread_cond_wait, which does not necessary mean there is a mutex > deadlock. > You might be waiting for some condition which never becomes true. > Thanks for the help. And this was actually the case. With some combinations of sort | uniq I found the cause. Stefan > --kcc > > On Thu, Jul 8, 2010 at 2:18 PM, Stefan Kost <en...@ho...> wrote: > >> On 08.07.2010 12:30, Konstantin Serebryany wrote: >> >>> On Thu, Jul 8, 2010 at 1:09 PM, Stefan Kost <en...@ho...> wrote: >>> >>> >>>> On 08.07.2010 11:34, Konstantin Serebryany wrote: >>>> >>>> >>>>> --tool=helgrind >>>>> >>>>> >>>>> >>>> Nope. helgrind does not complain. Does it run cycle checks on-the-fly? >>>> >>>> >>> Yes, http://valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders >>> >>> >> hm, then it should detect the problem indeed. >> >>> >>>> Or how would it detect that the app deadlocked. >>>> >>>> >>> helgrind finds cycles in lock ordering, deadlock does not have to >>> actually happen during the execution. >>> >>> Does your program use pthread_mutex_ or something else? >>> Is the program dynamically linked? >>> >>> >> The application is a benchmark for gstreamer, using glib's gthread >> (which uses pthread on linux). The program is dynamically linked. If I >> ctrl-c the app under gdb and dump all strackframes, I have a lot of >> stackframes like the two below: >> #0 0x0012d422 in __kernel_vsyscall () >> #1 0x00325af9 in __lll_lock_wait () at >> ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142 >> #2 0x00328e1c in _L_cond_lock_826 () from >> /lib/tls/i686/cmov/libpthread.so.0 >> #3 0x00328c40 in __pthread_mutex_cond_lock (mutex=0x824e6b0) at >> ../nptl/pthread_mutex_lock.c:61 >> #4 0x003230b3 in pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:203 >> ... >> and >> #0 0x0012d422 in __kernel_vsyscall () >> #1 0x00323015 in pthread_cond_wait@@GLIBC_2.3.2 () at >> ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 >> ... >> >> Stefan >> >> >> >>> --kcc >>> >>> >>> >>>> I was thinking of >>>> writing a LD_PRELOAD based toy, there I would ctrl-c the app and then >>>> run the cycle checks and dump the results. I have found no evidence in >>>> the docs that I can signal helgrind to tell that the app has no deadlocked. >>>> >>>> Stefan >>>> >>>> >>>> >>>> >>>>> On Thu, Jul 8, 2010 at 12:30 PM, Stefan Kost <en...@ho...> wrote: >>>>> >>>>> >>>>> >>>>>> hi, >>>>>> >>>>>> is anyone aware of a valgrind tool that can help me to debug a deadlock >>>>>> in a highly threaded program. The programm can easily create hundreds of >>>>>> threads. >>>>>> What I am locking for is a tool that tracks for each thread which >>>>>> mutexes are locked (incl. the strackframe of the lock) and if it is >>>>>> waiting on a mutex (also including the stackframe). When the app >>>>>> deadlocks, the collected data can be represented as a directed graph >>>>>> ("thread -> mutex" for a held lock and "mutex -> thread" for a pending >>>>>> lock) and one could run Tarjan's strongly connected components algorithm >>>>>> [1][2] to detect cycles. For each found cycle it could print the >>>>>> involved threads with the backtraces. >>>>>> >>>>>> Stefan >>>>>> >>>>>> >>>>>> [1] >>>>>> http://en.wikipedia.org/wiki/Tarjan%E2%80%99s_strongly_connected_components_algorithm >>>>>> [2] http://www.logarithmic.net/pfh/blog/01208083168 >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> This SF.net email is sponsored by Sprint >>>>>> What will you do first with EVO, the first 4G phone? >>>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>>>> _______________________________________________ >>>>>> Valgrind-users mailing list >>>>>> Val...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by Sprint >>>>> What will you do first with EVO, the first 4G phone? >>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>>> _______________________________________________ >>>>> Valgrind-users mailing list >>>>> Val...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by Sprint >>>> What will you do first with EVO, the first 4G phone? >>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>> _______________________________________________ >>>> Valgrind-users mailing list >>>> Val...@li... >>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>>> >>>> >>>> >>>> >>>> >> >> |
|
From: Konstantin S. <kon...@gm...> - 2010-07-08 10:24:14
|
The stack trace from gdb suggests that your program is blocked on pthread_cond_wait, which does not necessary mean there is a mutex deadlock. You might be waiting for some condition which never becomes true. --kcc On Thu, Jul 8, 2010 at 2:18 PM, Stefan Kost <en...@ho...> wrote: > On 08.07.2010 12:30, Konstantin Serebryany wrote: >> On Thu, Jul 8, 2010 at 1:09 PM, Stefan Kost <en...@ho...> wrote: >> >>> On 08.07.2010 11:34, Konstantin Serebryany wrote: >>> >>>> --tool=helgrind >>>> >>>> >>> Nope. helgrind does not complain. Does it run cycle checks on-the-fly? >>> >> Yes, http://valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders >> > hm, then it should detect the problem indeed. >> >>> Or how would it detect that the app deadlocked. >>> >> helgrind finds cycles in lock ordering, deadlock does not have to >> actually happen during the execution. >> >> Does your program use pthread_mutex_ or something else? >> Is the program dynamically linked? >> > > The application is a benchmark for gstreamer, using glib's gthread > (which uses pthread on linux). The program is dynamically linked. If I > ctrl-c the app under gdb and dump all strackframes, I have a lot of > stackframes like the two below: > #0 0x0012d422 in __kernel_vsyscall () > #1 0x00325af9 in __lll_lock_wait () at > ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142 > #2 0x00328e1c in _L_cond_lock_826 () from > /lib/tls/i686/cmov/libpthread.so.0 > #3 0x00328c40 in __pthread_mutex_cond_lock (mutex=0x824e6b0) at > ../nptl/pthread_mutex_lock.c:61 > #4 0x003230b3 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:203 > ... > and > #0 0x0012d422 in __kernel_vsyscall () > #1 0x00323015 in pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 > ... > > Stefan > > >> --kcc >> >> >>> I was thinking of >>> writing a LD_PRELOAD based toy, there I would ctrl-c the app and then >>> run the cycle checks and dump the results. I have found no evidence in >>> the docs that I can signal helgrind to tell that the app has no deadlocked. >>> >>> Stefan >>> >>> >>> >>>> On Thu, Jul 8, 2010 at 12:30 PM, Stefan Kost <en...@ho...> wrote: >>>> >>>> >>>>> hi, >>>>> >>>>> is anyone aware of a valgrind tool that can help me to debug a deadlock >>>>> in a highly threaded program. The programm can easily create hundreds of >>>>> threads. >>>>> What I am locking for is a tool that tracks for each thread which >>>>> mutexes are locked (incl. the strackframe of the lock) and if it is >>>>> waiting on a mutex (also including the stackframe). When the app >>>>> deadlocks, the collected data can be represented as a directed graph >>>>> ("thread -> mutex" for a held lock and "mutex -> thread" for a pending >>>>> lock) and one could run Tarjan's strongly connected components algorithm >>>>> [1][2] to detect cycles. For each found cycle it could print the >>>>> involved threads with the backtraces. >>>>> >>>>> Stefan >>>>> >>>>> >>>>> [1] >>>>> http://en.wikipedia.org/wiki/Tarjan%E2%80%99s_strongly_connected_components_algorithm >>>>> [2] http://www.logarithmic.net/pfh/blog/01208083168 >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF.net email is sponsored by Sprint >>>>> What will you do first with EVO, the first 4G phone? >>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>>> _______________________________________________ >>>>> Valgrind-users mailing list >>>>> Val...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by Sprint >>>> What will you do first with EVO, the first 4G phone? >>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>> _______________________________________________ >>>> Valgrind-users mailing list >>>> Val...@li... >>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >>> >>> >>> > > |
|
From: Stefan K. <en...@ho...> - 2010-07-08 10:18:17
|
On 08.07.2010 12:30, Konstantin Serebryany wrote: > On Thu, Jul 8, 2010 at 1:09 PM, Stefan Kost <en...@ho...> wrote: > >> On 08.07.2010 11:34, Konstantin Serebryany wrote: >> >>> --tool=helgrind >>> >>> >> Nope. helgrind does not complain. Does it run cycle checks on-the-fly? >> > Yes, http://valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders > hm, then it should detect the problem indeed. > >> Or how would it detect that the app deadlocked. >> > helgrind finds cycles in lock ordering, deadlock does not have to > actually happen during the execution. > > Does your program use pthread_mutex_ or something else? > Is the program dynamically linked? > The application is a benchmark for gstreamer, using glib's gthread (which uses pthread on linux). The program is dynamically linked. If I ctrl-c the app under gdb and dump all strackframes, I have a lot of stackframes like the two below: #0 0x0012d422 in __kernel_vsyscall () #1 0x00325af9 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142 #2 0x00328e1c in _L_cond_lock_826 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x00328c40 in __pthread_mutex_cond_lock (mutex=0x824e6b0) at ../nptl/pthread_mutex_lock.c:61 #4 0x003230b3 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:203 ... and #0 0x0012d422 in __kernel_vsyscall () #1 0x00323015 in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:122 ... Stefan > --kcc > > >> I was thinking of >> writing a LD_PRELOAD based toy, there I would ctrl-c the app and then >> run the cycle checks and dump the results. I have found no evidence in >> the docs that I can signal helgrind to tell that the app has no deadlocked. >> >> Stefan >> >> >> >>> On Thu, Jul 8, 2010 at 12:30 PM, Stefan Kost <en...@ho...> wrote: >>> >>> >>>> hi, >>>> >>>> is anyone aware of a valgrind tool that can help me to debug a deadlock >>>> in a highly threaded program. The programm can easily create hundreds of >>>> threads. >>>> What I am locking for is a tool that tracks for each thread which >>>> mutexes are locked (incl. the strackframe of the lock) and if it is >>>> waiting on a mutex (also including the stackframe). When the app >>>> deadlocks, the collected data can be represented as a directed graph >>>> ("thread -> mutex" for a held lock and "mutex -> thread" for a pending >>>> lock) and one could run Tarjan's strongly connected components algorithm >>>> [1][2] to detect cycles. For each found cycle it could print the >>>> involved threads with the backtraces. >>>> >>>> Stefan >>>> >>>> >>>> [1] >>>> http://en.wikipedia.org/wiki/Tarjan%E2%80%99s_strongly_connected_components_algorithm >>>> [2] http://www.logarithmic.net/pfh/blog/01208083168 >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by Sprint >>>> What will you do first with EVO, the first 4G phone? >>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>>> _______________________________________________ >>>> Valgrind-users mailing list >>>> Val...@li... >>>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>>> >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> >> |
|
From: Konstantin S. <kon...@gm...> - 2010-07-08 09:30:42
|
On Thu, Jul 8, 2010 at 1:09 PM, Stefan Kost <en...@ho...> wrote: > On 08.07.2010 11:34, Konstantin Serebryany wrote: >> --tool=helgrind >> > > Nope. helgrind does not complain. Does it run cycle checks on-the-fly? Yes, http://valgrind.org/docs/manual/hg-manual.html#hg-manual.lock-orders > Or how would it detect that the app deadlocked. helgrind finds cycles in lock ordering, deadlock does not have to actually happen during the execution. Does your program use pthread_mutex_ or something else? Is the program dynamically linked? --kcc > I was thinking of > writing a LD_PRELOAD based toy, there I would ctrl-c the app and then > run the cycle checks and dump the results. I have found no evidence in > the docs that I can signal helgrind to tell that the app has no deadlocked. > > Stefan > > >> On Thu, Jul 8, 2010 at 12:30 PM, Stefan Kost <en...@ho...> wrote: >> >>> hi, >>> >>> is anyone aware of a valgrind tool that can help me to debug a deadlock >>> in a highly threaded program. The programm can easily create hundreds of >>> threads. >>> What I am locking for is a tool that tracks for each thread which >>> mutexes are locked (incl. the strackframe of the lock) and if it is >>> waiting on a mutex (also including the stackframe). When the app >>> deadlocks, the collected data can be represented as a directed graph >>> ("thread -> mutex" for a held lock and "mutex -> thread" for a pending >>> lock) and one could run Tarjan's strongly connected components algorithm >>> [1][2] to detect cycles. For each found cycle it could print the >>> involved threads with the backtraces. >>> >>> Stefan >>> >>> >>> [1] >>> http://en.wikipedia.org/wiki/Tarjan%E2%80%99s_strongly_connected_components_algorithm >>> [2] http://www.logarithmic.net/pfh/blog/01208083168 >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by Sprint >>> What will you do first with EVO, the first 4G phone? >>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >>> >>> >>> >>> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Stefan K. <en...@ho...> - 2010-07-08 09:09:31
|
On 08.07.2010 11:34, Konstantin Serebryany wrote:
> --tool=helgrind
>
Nope. helgrind does not complain. Does it run cycle checks on-the-fly?
Or how would it detect that the app deadlocked. I was thinking of
writing a LD_PRELOAD based toy, there I would ctrl-c the app and then
run the cycle checks and dump the results. I have found no evidence in
the docs that I can signal helgrind to tell that the app has no deadlocked.
Stefan
> On Thu, Jul 8, 2010 at 12:30 PM, Stefan Kost <en...@ho...> wrote:
>
>> hi,
>>
>> is anyone aware of a valgrind tool that can help me to debug a deadlock
>> in a highly threaded program. The programm can easily create hundreds of
>> threads.
>> What I am locking for is a tool that tracks for each thread which
>> mutexes are locked (incl. the strackframe of the lock) and if it is
>> waiting on a mutex (also including the stackframe). When the app
>> deadlocks, the collected data can be represented as a directed graph
>> ("thread -> mutex" for a held lock and "mutex -> thread" for a pending
>> lock) and one could run Tarjan's strongly connected components algorithm
>> [1][2] to detect cycles. For each found cycle it could print the
>> involved threads with the backtraces.
>>
>> Stefan
>>
>>
>> [1]
>> http://en.wikipedia.org/wiki/Tarjan%E2%80%99s_strongly_connected_components_algorithm
>> [2] http://www.logarithmic.net/pfh/blog/01208083168
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>>
>>
>>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|
|
From: Konstantin S. <kon...@gm...> - 2010-07-08 08:34:57
|
--tool=helgrind
On Thu, Jul 8, 2010 at 12:30 PM, Stefan Kost <en...@ho...> wrote:
> hi,
>
> is anyone aware of a valgrind tool that can help me to debug a deadlock
> in a highly threaded program. The programm can easily create hundreds of
> threads.
> What I am locking for is a tool that tracks for each thread which
> mutexes are locked (incl. the strackframe of the lock) and if it is
> waiting on a mutex (also including the stackframe). When the app
> deadlocks, the collected data can be represented as a directed graph
> ("thread -> mutex" for a held lock and "mutex -> thread" for a pending
> lock) and one could run Tarjan's strongly connected components algorithm
> [1][2] to detect cycles. For each found cycle it could print the
> involved threads with the backtraces.
>
> Stefan
>
>
> [1]
> http://en.wikipedia.org/wiki/Tarjan%E2%80%99s_strongly_connected_components_algorithm
> [2] http://www.logarithmic.net/pfh/blog/01208083168
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>
|
|
From: Stefan K. <en...@ho...> - 2010-07-08 08:30:29
|
hi,
is anyone aware of a valgrind tool that can help me to debug a deadlock
in a highly threaded program. The programm can easily create hundreds of
threads.
What I am locking for is a tool that tracks for each thread which
mutexes are locked (incl. the strackframe of the lock) and if it is
waiting on a mutex (also including the stackframe). When the app
deadlocks, the collected data can be represented as a directed graph
("thread -> mutex" for a held lock and "mutex -> thread" for a pending
lock) and one could run Tarjan's strongly connected components algorithm
[1][2] to detect cycles. For each found cycle it could print the
involved threads with the backtraces.
Stefan
[1]
http://en.wikipedia.org/wiki/Tarjan%E2%80%99s_strongly_connected_components_algorithm
[2] http://www.logarithmic.net/pfh/blog/01208083168
|
|
From: Duncan S. <bal...@fr...> - 2010-07-08 08:21:33
|
Hi John, >> [My case] has nothing to do with tracking uninitialized bits etc in floating >> point numbers. In fact if valgrind ignored floating point numbers and >> just executed them natively that would be fine with me. > > What I distill from this is a request for a "FP mode" which checks > loads from memory to FP registers for valid [allocated] addresses > and [un]init bit values, but immediately marks the bits in the register > as all init or all uninit. FP operations track data flow, but again > the result bits are marked all init or all uninit. Stores from FP > registers to memory are checked for valid [allocated] addresses, > and copy the marking of the bits in register to the memory bytes. > FP modes (width, rounding, etc.) and operations never are changed > from user values. this sounds like a great plan. Best wishes, Duncan. |
|
From: John R. <jr...@bi...> - 2010-07-07 19:20:38
|
> [My case] has nothing to do with tracking uninitialized bits etc in floating > point numbers. In fact if valgrind ignored floating point numbers and > just executed them natively that would be fine with me. What I distill from this is a request for a "FP mode" which checks loads from memory to FP registers for valid [allocated] addresses and [un]init bit values, but immediately marks the bits in the register as all init or all uninit. FP operations track data flow, but again the result bits are marked all init or all uninit. Stores from FP registers to memory are checked for valid [allocated] addresses, and copy the marking of the bits in register to the memory bytes. FP modes (width, rounding, etc.) and operations never are changed from user values. -- |
|
From: Duncan S. <bal...@fr...> - 2010-07-07 16:55:54
|
Hi John, >> Due to that precision loss, I cannot further use valgrind. Some numeric >> integals etc. heavily depend on numeric precision... > > [This response is general and somewhat theoretical, but might aid > in understanding some big-picture aspects of memcheck and FP.] > > What is the expected benefit from a valgrind that handles FP that is > wider than 'double'? Memcheck handles uninit FP very simply: if any input > bit to an FP operation is uninit, then all output bits are uninit. > There is no bit-by-bit analysis for an FP op like there is for [most] > integer operations. [Integer divide and remainder are not handled as > precisely by memcheck as integer addition, subtraction, and boolean ops. > There are some cryptography apps where this matters.] the problem I have is that due to extra rounding when running under valgrind, eventually the program behaves differently, different code paths are taken, etc, which can make valgrind useless for trying to debug some failures, because the failure doesn't occur under valgrind. This has nothing to do with tracking uninitialized bits etc in floating point numbers. In fact if valgrind ignored floating point numbers and just executed them natively that would be fine with me. Ciao, Duncan. |
|
From: John R. <jr...@bi...> - 2010-07-07 15:52:08
|
> Due to that precision loss, I cannot further use valgrind. Some numeric > integals etc. heavily depend on numeric precision... [This response is general and somewhat theoretical, but might aid in understanding some big-picture aspects of memcheck and FP.] What is the expected benefit from a valgrind that handles FP that is wider than 'double'? Memcheck handles uninit FP very simply: if any input bit to an FP operation is uninit, then all output bits are uninit. There is no bit-by-bit analysis for an FP op like there is for [most] integer operations. [Integer divide and remainder are not handled as precisely by memcheck as integer addition, subtraction, and boolean ops. There are some cryptography apps where this matters.] In some respects memcheck of FP code is a schema operation where the width of FP is an independent variable. If you can force the code to execute the same path, then the width of FP does not matter to the memcheck results. It may be possible to evade the width issue by melding a code coverage analysis with the output of memcheck on the code for 'double'. -- |
|
From: John R. <jr...@bi...> - 2010-07-07 15:19:08
|
On 07/07/2010 05:23 AM, Duncan Sands wrote: >>> I have a problem with valgrind since I did convert >>> my program to use long double instead double on >>> critical points. Here is an example code: [snipped] > > I also have this problem with some programs: running under valgrind > eventually causes different program behaviour due to extra rounding. > >> If 53 bits of fractional precision are not enough, then the question >> becomes, "Why are 64 bits enough? Why aren't 2*53 bits, or 53+64 bits, >> or 2*64 bits, or more, required?" > > Perhaps because careful analysis has determined that 53 bits is not enough, > but some greater number of bits is? The original poster gave no indication that such careful analysis had been done, only that 53 bits apparently was not enough for the existing software. If no fixed upper bound on the necessary precision is known in advance, then it is possible that nothing will satisfy the original poster, and the payoff for attempting a solution might be low. >> If you must have both such high precision and valgrind, then convert >> to software double precision. Represent each quantity by the sum of >> two 'double's, such that the difference in exponents is near 53. >> [Have fun with the many corner cases: exponent underflow, ...] > > One of the great advantages of valgrind is that it doesn't require > modifying source code. Your rather dismissive answer of "rewrite > your software" is not very helpful. It's not always feasible to > rewrite software. I gave an explicit technical suggestion that was new to the discussion, can be done, and shows promise towards solving the apparent problem of providing more than 53 bits of precision while working with valgrind. I have implemented such software in the past, and indeed controlling exponent range is a problem. Nevertheless, it allowed me to achieve about 96 bits of precision in most cases [my particular application needed 78 bits], have moderate speed, and play nicely with the software tools of its day. (It was many years before valgrind; the software is not available for distribution.) -- |