|
From: Rafael F. <rfo...@pr...> - 2010-10-28 20:13:30
|
Hello list, I have recently used valgrind macros for tracking mempools (the following blog post tells a little about it http://15experience.wordpress.com/2010/10/22/make-valgrind-track-your-mempool/). The library on which I am using valgrind provides basic data structures used by other libraries on top of it including some graphical ones. Well it is known that when running under valgrind our programs run slower than normal. But I am having an strange issue when I compile that library with valgrind macros enabled (i.e NVALGRIND undefined): a graphical program runs even slower than just running it without the macros in a way it becomes unusable. For example, running a graphical test without the macros: real 0m10.537s user 0m10.036s sys 0m0.117s and with the macros: real 0m15.226s user 0m14.462s sys 0m0.097s So I would like to know whether that kind of behavior is expected. Maybe am I doing something wrong? Thank you for the help. B.R. -- Rafael Fonseca ProFUSION embedded systems http://www.profusion.mobi |
|
From: David W. <dw...@in...> - 2010-10-28 20:54:23
|
On Thu, 2010-10-28 at 18:13 -0200, Rafael Fonseca wrote: > So I would like to know whether that kind of behavior is expected. > Maybe am I doing something wrong? FWIW I think I saw something similar when adding mempool annotations to the glib 'GSlice' allocator -- it was *extremely* slow. But then I concluded that the mempool tracking is broken anyway, so stopped bothering with it. (Bug 254420) -- David Woodhouse Open Source Technology Centre Dav...@in... Intel Corporation |
|
From: Julian S. <js...@ac...> - 2010-10-30 11:37:36
|
> For example, running a graphical test without the macros: > > real 0m10.537s > user 0m10.036s > sys 0m0.117s > > and with the macros: > > real 0m15.226s > user 0m14.462s > sys 0m0.097s I would have thought the mempool stuff might be a couple of percent slower than using normal malloc/free, but certainly not 50% slower. After all, the same work needs to be done by Valgrind in both cases. If you can make a test case I can use to investigate, I'll have a look. Also, please file this as a bug report at https://bugs.kde.org/enter_valgrind_bug.cgi. Bugs reported on the mailing lists tend to get forgotten about. Bugzilla is a much safer place for them. J |
|
From: Shi, Y. <Yun...@ls...> - 2010-11-03 14:30:16
|
Hi there, I am trying to measure a process running by spawn fast cgi. Spawn fcgi will fork a child process to run my application. Like this: spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 ./restactivator while restactivator is my application. How to perform dynamic analysis using Valgrind in this case? I tried several thing, none of them works. spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "valgrind --leak-check=yes ./restactivator > memoryCheck.txt" // spawn-fcgi: child exited with: 2 spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 valgrind --leak-check=yes ./restactivator // spawn can't recognize the parameters spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "valgrind --leak-check=yes ./restactivator" // child exit 2 spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 /usr/local/bin/valgrind --leak-check=yes /root/nxtcore-yshi/nxtcore/nxtrestfwk/restactivator // parameter not recognized spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "/usr/local/bin/valgrind --leak-check=yes /root/nxtcore-yshi/nxtcore/nxtrestfwk/restactivator" // exit 2 Thank you, Yuning |
|
From: Julian S. <js...@ac...> - 2010-11-03 15:23:49
|
--trace-children=yes. Also see --trace-children-skip= J On Wednesday, November 03, 2010, Shi, Yuning wrote: > Hi there, > > I am trying to measure a process running by spawn fast cgi. Spawn fcgi will > fork a child process to run my application. Like this: > > spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 ./restactivator > > while restactivator is my application. > > How to perform dynamic analysis using Valgrind in this case? I tried > several thing, none of them works. > > spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "valgrind --leak-check=yes > ./restactivator > memoryCheck.txt" // spawn-fcgi: child exited with: 2 > spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 valgrind --leak-check=yes > ./restactivator // spawn can't recognize the parameters spawn-fcgi -p 9001 > -a 127.0.0.1 -F 1 "valgrind --leak-check=yes ./restactivator" // child > exit 2 > > spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 /usr/local/bin/valgrind > --leak-check=yes /root/nxtcore-yshi/nxtcore/nxtrestfwk/restactivator // > parameter not recognized > > spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "/usr/local/bin/valgrind > --leak-check=yes /root/nxtcore-yshi/nxtcore/nxtrestfwk/restactivator" // > exit 2 > > Thank you, > Yuning > > > > --------------------------------------------------------------------------- > --- Achieve Improved Network Security with IP and DNS Reputation. > Defend against bad network traffic, including botnets, malware, > phishing sites, and compromised hosts - saving your company time, > money, and embarrassment. Learn More! > http://p.sf.net/sfu/hpdev2dev-nov > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: John R. <jr...@bi...> - 2010-11-03 15:30:29
|
> spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 ./restactivator
>
> while restactivator is my application.
>
> How to perform dynamic analysis using Valgrind in this case? I tried several thing, none of them works.
>
> spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "valgrind --leak-check=yes ./restactivator > memoryCheck.txt" // spawn-fcgi: child exited with: 2
> spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 valgrind --leak-check=yes ./restactivator // spawn can't recognize the parameters
> spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "valgrind --leak-check=yes ./restactivator" // child exit 2
>
> spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 /usr/local/bin/valgrind --leak-check=yes /root/nxtcore-yshi/nxtcore/nxtrestfwk/restactivator
> // parameter not recognized
>
> spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 "/usr/local/bin/valgrind --leak-check=yes /root/nxtcore-yshi/nxtcore/nxtrestfwk/restactivator"
> // exit 2
_If_ the problem is that spawn-fcgi expects exactly one argument
[what is the meaning of "-F 1", anyway?]
then make an executable shell script that invokes valgrind:
-----my-script.sh; chmod +x (r-xr-xr-x)
#!/bin/sh
exec /usr/local/bin/valgrind --leak-check=yes /root/nxtcore-yshi/nxtcore/nxtrestfwk/restactivator
-----
Invoke as (for example):
spawn-fcgi -p 9001 -a 127.0.0.1 -F 1 ./my-script.sh
--
|
|
From: Rafael F. <rfo...@pr...> - 2010-11-03 13:53:34
|
> If you can make a test case I can use to investigate, I'll have a look. > > Also, please file this as a bug report at > https://bugs.kde.org/enter_valgrind_bug.cgi. Bugs reported on the > mailing lists tend to get forgotten about. Bugzilla is a much > safer place for them. Julian, thank you for your reply. I have just filled the bug report and attached there a test case: https://bugs.kde.org/show_bug.cgi?id=255966. If you want to check the annotations I added, take a look at src/modules/mp/chained_pool/eina_chained_mempool.c in the eina directory. B.R. -- Rafael Fonseca ProFUSION embedded systems http://www.profusion.mobi |