|
From: Bart V. A. <bar...@gm...> - 2008-03-29 09:35:02
|
On Fri, Mar 28, 2008 at 8:34 PM, Dirk Stoecker <val...@ds...> wrote: > On Fri, 28 Mar 2008, bar...@gm... wrote: > > >> P.S. Is there a tool telling me stack usage for threads (I use Linux). > > > > Is it sufficient if stack usage is reported for all threads at the > > time a process terminates ? I can add such functionality easily to > > exp-drd if you want. > > Actually I want to know the maximum stack size a thread used. Because I > need to set the maximum stack size to a defined value and currently this > is based on guessing+some security margin. And this is never a good way. > Measurement+security margin would be much better. By this time I have added a command-line option --show-stack-usage to exp-drd. If enabled it is reported how many bytes a thread has used on its stack at the time it finished. An example: $ ./vg-in-place --tool=exp-drd --show-stack-usage=yes exp-drd/tests/matinv 200 -t4 ==30241== exp-drd, a data race detector. ==30241== NOTE: This is an Experimental-Class Valgrind Tool. ==30241== Copyright (C) 2006-2008, and GNU GPL'd, by Bart Van Assche. ==30241== Using LibVEX rev 1811, a library for dynamic binary translation. ==30241== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==30241== Using valgrind-3.4.0.SVN, a dynamic binary instrumentation framework. ==30241== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==30241== For more details, rerun with: -v ==30241== ==30241== thread 2/2 finished and used 4776 bytes out of 28672 on its stack. Margin: 23896 bytes. ==30241== thread 3/3 finished and used 4280 bytes out of 28672 on its stack. Margin: 24392 bytes. ==30241== thread 4/4 finished and used 4280 bytes out of 28672 on its stack. Margin: 24392 bytes. ==30241== thread 5/5 finished and used 4280 bytes out of 28672 on its stack. Margin: 24392 bytes. error = 1.08926e-16; epsilon = 2.22045e-16; error / (epsilon * n) = 0.00490557 Error within bounds. ==30241== thread 1/1 finished and used 8992 bytes out of 8388608 on its stack. Margin: 8379616 bytes. ==30241== ==30241== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 32 from 1) You can run the exp-drd tool by building the latest Valgrind SVN sources. For instructions, see also http://www.valgrind.org/downloads/repository.html Bart. |
|
From: Dirk S. <val...@ds...> - 2008-03-31 16:30:14
|
On Sat, 29 Mar 2008, Bart Van Assche wrote: >> Actually I want to know the maximum stack size a thread used. Because I >> need to set the maximum stack size to a defined value and currently this >> is based on guessing+some security margin. And this is never a good way. >> Measurement+security margin would be much better. > > By this time I have added a command-line option --show-stack-usage to > exp-drd. If enabled it is reported how many bytes a thread has used on > its stack at the time it finished. An example: Are the stats correct? I get below 20KB stack usage, but the tool crashs for sure, when I set the stack to 32KB. 64KB works. Are there any operating system or pthread overheads, which are not counted? BTW: Could you update drd_print_usage() ? Many options and the defaults are missing :-) And the Docs still state rwlocks are not supported, but you have --trace-rwlock as option. Are rwlocks supported? I get lots of "Conflicting load by thread 1/1". Could you add some little notes to the docs, how to interpret the output? I could not follow it. The first Statement and the first "Other segment start" matched, but the following ones point to totally different structures. Ciao -- http://www.dstoecker.eu/ (PGP key available) |
|
From: <bar...@gm...> - 2008-03-31 19:24:44
|
On 3/31/08, Dirk Stoecker <val...@ds...> wrote:
> Are the stats correct? I get below 20KB stack usage, but the tool crashs
> for sure, when I set the stack to 32KB. 64KB works. Are there any
> operating system or pthread overheads, which are not counted?
The exp-drd algorithm runs on the stack of the client threads, so when running a program under exp-drd (or any other Valgrind tool), more stack space is needed than when a program is run natively. I was not aware that exp-drd crashes when it runs out of stack space -- this it not very elegant.
> BTW: Could you update drd_print_usage() ? Many options and the defaults
> are missing :-) And the Docs still state rwlocks are not supported, but
> you have --trace-rwlock as option. Are rwlocks supported? I get lots
> of "Conflicting load by thread 1/1". Could you add some little notes to
> the docs, how to interpret the output? I could not follow it. The first
> Statement and the first "Other segment start" matched, but the following
> ones point to totally different structures.
Regarding reader-writer locks: I did not yet have the time to test reader-writer lock support in exp-drd thoroughly, so it is possible that the implementation of reader-writer locks in exp-drd is not yet correct. If you have a small sample program for which you think exp-drd's output is incorrect, you are welcome to post it to the valgrind-users mailing list.
Regarding interpreting exp-drd's output: there is now a section in exp-drd/docs/README.txt which explains how to interpret the data race reports.
Regarding exp-drd's command-line options: the output displayed for valgrind --tool=exp-drd -h should now be correct. It looks now as follows:
user options for exp-drd:
--segment-merging=yes|no Controls segment merging [yes].
Segment merging is an algorithm to limit memory usage of the
data race detection algorithm. Disabling segment merging may
improve the accuracy of the so-called 'other segments' displayed
in race reports but can also trigger an out of memory error.
--show-confl-seg=yes|no Show conflicting segments in race reports [yes].
--show-stack-usage=yes|no Print stack usage at thread exit time [no].
--var-info=yes|no Display the names of global, static and
stack variables when a race is reported on such a variable. This
information is by default not displayed since for big programs
reading in all debug information for all variables at once may
cause an out of memory error [no].
DRD options for monitoring process behavior:
--trace-address=<address> Trace all load and store activity for the.
specified address [off].
--trace-barrier=yes|no Trace all barrier activity [no].
--trace-cond=yes|no Trace all condition variable activity [no].
--trace-fork-join=yes|no Trace all thread fork/join activity [no].
--trace-mutex=yes|no Trace all mutex activity[no].
--trace-rwlock=yes|no Trace all reader-writer lock activity[no].
--trace-segment=yes|no Trace segment actions [no].
--trace-semaphore=yes|no Trace all semaphore activity [no].
Options for debugging DRD:
--drd-stats=yes|no Print statistics about DRD activity [no].
--trace-clientobj=yes|no Trace all client object activity [no].
--trace-csw=yes|no Trace all scheduler context switches [no].
--trace-danger-set=yes|no Trace all danger set updates [no].
--trace-suppression=yes|no Trace all address suppression actions [no].
Bart.
|
|
From: Dirk S. <val...@ds...> - 2008-04-01 06:09:34
|
On Mon, 31 Mar 2008, bar...@gm... wrote: >> Are the stats correct? I get below 20KB stack usage, but the tool crashs >> for sure, when I set the stack to 32KB. 64KB works. Are there any >> operating system or pthread overheads, which are not counted? > > The exp-drd algorithm runs on the stack of the client threads, so when > running a program under exp-drd (or any other Valgrind tool), more stack > space is needed than when a program is run natively. I was not aware > that exp-drd crashes when it runs out of stack space -- this it not very > elegant. No, the program crashs outside of valgrind. It SEGFAULTS somewhere, when I reduce the thread stack to 32KB. Thought I was not able to debug, where it crashs (actually I also do not have the time to find it out). I will do some more testing. Maybe there are code paths, which I did not check with the exp-drd runs. >> BTW: Could you update drd_print_usage() ? Many options and the defaults >> are missing :-) And the Docs still state rwlocks are not supported, but >> you have --trace-rwlock as option. Are rwlocks supported? I get lots >> of "Conflicting load by thread 1/1". Could you add some little notes to >> the docs, how to interpret the output? I could not follow it. The first >> Statement and the first "Other segment start" matched, but the following >> ones point to totally different structures. > > Regarding reader-writer locks: I did not yet have the time to test > reader-writer lock support in exp-drd thoroughly, so it is possible that > the implementation of reader-writer locks in exp-drd is not yet correct. > If you have a small sample program for which you think exp-drd's output > is incorrect, you are welcome to post it to the valgrind-users mailing > list. I will see. Actually at the moment I only have a medium sized closed source program I want to check. It is a server tool which works fine, but surely has some hidden problems. Ciao -- http://www.dstoecker.eu/ (PGP key available) |