From: Julian Seward Date: Thu, 13 Jun 2002 20:37:25 +0000 (+0000) Subject: First round of manual update for 1.0. X-Git-Tag: svn/VALGRIND_1_0_3~62 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c797c7e5f9610a04afee2c5ae0fd8fc5ccb60eb1;p=thirdparty%2Fvalgrind.git First round of manual update for 1.0. git-svn-id: svn://svn.valgrind.org/valgrind/trunk@417 --- diff --git a/cachegrind/docs/manual.html b/cachegrind/docs/manual.html index 9756d38088..8c61ce4956 100644 --- a/cachegrind/docs/manual.html +++ b/cachegrind/docs/manual.html @@ -24,9 +24,8 @@   -

Valgrind, snapshot 20020522

-
This manual was majorly updated on 20020501
-
This manual was minorly updated on 20020603
+

Valgrind, version 1.0

+
This manual was majorly updated on 20020613

@@ -105,7 +104,9 @@ detect problems such as:
  • Reading/writing inappropriate areas on the stack
  • Memory leaks -- where pointers to malloc'd blocks are lost forever
    • -
  • Mismatched use of malloc/new/new [] vs free/delete/delete []
    • +
  • Mismatched use of malloc/new/new [] vs free/delete/delete + []
    • +
  • Some misuses of the POSIX pthreads API
    • Problems like these can be difficult to find by other means, often @@ -116,12 +117,12 @@ difficult-to-diagnose crashes. Valgrind is closely tied to details of the CPU, operating system and to a less extent, compiler and basic C libraries. This makes it difficult to make it portable, so I have chosen at the outset to -concentrate on what I believe to be a widely used platform: Red Hat -Linux 7.2, on x86s. Valgrind uses the standard Unix -./configure, make, make install -mechanism, and I have attempted to ensure that it works on machines -with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover -the vast majority of modern Linux installations. +concentrate on what I believe to be a widely used platform: Linux on +x86s. Valgrind uses the standard Unix ./configure, +make, make install mechanism, and I have +attempted to ensure that it works on machines with kernel 2.2 or 2.4 +and glibc 2.1.X or 2.2.X. This should cover the vast majority of +modern Linux installations.

    @@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of higher optimisation levels anyway, so you don't lose much there.

    -Note that as of 1 May 2002 Valgrind does not understand the DWARF -debugging format, which is unfortunate since the upcoming gcc-3.1 uses -it by default. Valgrind only knows about the older "stabs" format. -If you use gcc-3.1 or above, you can still ask for stabs-format debug -info by passing -gstabs to gcc. +Valgrind understands both the older "stabs" debugging format, used by +gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1 +and later.

    Then just run your application, but place the word @@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These limits are defined in vg_include.h and can be increased if necessary. +

    To avoid this cutoff you can use the +--error-limit=no flag. Then valgrind will always show +errors, regardless of how many there are. Use this flag carefully, +since it may have a dire effect on performance. + +

    2.4  Suppressing errors

    @@ -553,15 +558,23 @@ follows: Note that gcc 2.96 is the default compiler on some popular Linux distributions (RedHat 7.X, Mandrake) and so you may well need to use this flag. Do not use it if you do not have to, as it can - cause real errors to be overlooked. A better option is to use a - gcc/g++ which works properly; 2.95.3 seems to be a good choice. + cause real errors to be overlooked. Another option is to use a + gcc/g++ which does not generate accesses below the stack + pointer. 2.95.3 seems to be a good choice in this respect.

    - Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly - buggy, so you may need to issue this flag if you use 3.0.4. A + Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar + bug, so you may need to issue this flag if you use 3.0.4. A while later (early Apr 02) this is confirmed as a scheduling bug in g++-3.0.4.

    +

  • --error-limit=yes [default]
    + --error-limit=no

    When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.


    • +

  • --cachesim=no [default]
    --cachesim=yes

    When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.

    -

  • Warning: client exiting by calling exit(<number>). - Bye! -
    - Your program has called the exit system call, which - will immediately terminate the process. You'll get no exit-time - error summaries or leak checks. Note that this is not the same - as your program calling the ANSI C function exit() - -- that causes a normal, controlled shutdown of Valgrind. -

  • Warning: client switching stacks?
    Valgrind spotted such a large change in the stack pointer, %esp, @@ -961,19 +965,6 @@ Most of these only appear if you run in verbose mode (enabled by The call will still have gone through, but you may get spurious errors after this as a result of the non-update of the memory info.

    -

  • Warning: unblocking signal <number> due to - sigprocmask -
    - Really just a diagnostic from the signal simulation machinery. - This message will appear if your program handles a signal by - first longjmping out of the signal handler, - and then unblocking the signal with sigprocmask - -- a standard signal-handling idiom. -

    -

  • Warning: bad signal number <number> in __NR_sigaction. -
    - Probably indicates a bug in the signal simulation machinery. -

  • Warning: set address range perms: large range <number>
    Diagnostic message, mostly for my benefit, to do with memory @@ -988,7 +979,7 @@ A suppression file describes a bunch of errors which, for one reason or another, you don't want Valgrind to tell you about. Usually the reason is that the system libraries are buggy but unfixable, at least within the scope of the current debugging session. Multiple -suppresions files are allowed. By default, Valgrind uses +suppressions files are allowed. By default, Valgrind uses $PREFIX/lib/valgrind/default.supp.

    @@ -1206,8 +1197,8 @@ A brief description of the available macros:

    2.9  Support for POSIX Pthreads

    As of late April 02, Valgrind supports programs which use POSIX -pthreads. Doing this has proved technically challenging and is still -in progress, but it works well enough, for significant threaded +pthreads. Doing this has proved technically challenging but is now +mostly complete. It works well enough for significant threaded applications to work.

    It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.

    Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.

    -The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:

    • Mutexes, condition variables, thread-specific data, - pthread_once and basic semaphore functions - (sem_*) currently work. -

      -

    • Various attribute-like calls are handled but ignored. - You get a warning message. -

      -

    • The main big omission is proper cleanup support for cancellation. - pthread_cancel works, but instantly nukes the target - thread without giving it any chance to clean up. Also, when a - thread exits, it does not run any cleanup handlers. -

      -

    • Other omissions are: the detachedness state of threads is ignored. - This means detached threads hang around and clog up scheduler - slots forever when they finish. Calls for reader-writer locks are - have dummy stubs with no functionality right now. You get a + pthread_once, reader-writer locks, semaphores, + cleanup stacks, cancellation and thread detaching currently work. + Various attribute-like calls are handled but ignored; you get a warning message.

    • Currently the following syscalls are thread-safe (nonblocking): write read nanosleep - sleep select and poll. + sleep select poll + recvmsg and + accept.

      -

    • The POSIX requirement that each thread have its own - signal-blocking mask is now implemented. +
    • Signals in pthreads are now handled properly(ish): pthread_sigmask, pthread_kill, - pthread_sigwait and raise should all now - work as POSIX requires. + sigwait and raise are now implemented. + Each thread has its own signal mask, as POSIX requires. + It's a bit kludgey -- there's a system-wide pending signal set, + rather than one for each thread. But hey.
    As of 18 May 02, the following threaded programs now work fine on my RedHat 7.2 box: Opera 6.0Beta2, KNode in KDE 3.0, Mozilla-0.9.2.1 and Galeon-0.11.3, both as supplied with RedHat 7.2. Also Mozilla 1.0RC2. - +OpenOffice 1.0. MySQL 3.something (the current stable release).

    2.10  Building and installing

    @@ -1279,8 +1259,18 @@ attempted to ensure that it works on machines with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. I don't think there is much else to say. There are no options apart from the usual --prefix that you should give to ./configure. +

    -Let me know if you have build problems. +The configure script tests the version of the X server +currently indicated by the current $DISPLAY. This is a +known bug. The intention was to detect the version of the current +XFree86 client libraries, so that correct suppressions could be +selected for them, but instead the test checks the server version. +This is just plain wrong. + +

    +Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +

    • --I1=<size>,<associativity>,<line_size>
      --D1=<size>,<associativity>,<line_size>
      --L2=<size>,<associativity>,<line_size>

      diff --git a/coregrind/docs/manual.html b/coregrind/docs/manual.html index 9756d38088..8c61ce4956 100644 --- a/coregrind/docs/manual.html +++ b/coregrind/docs/manual.html @@ -24,9 +24,8 @@   -

      Valgrind, snapshot 20020522

      -
      This manual was majorly updated on 20020501
      -
      This manual was minorly updated on 20020603
      +

      Valgrind, version 1.0

      +
      This manual was majorly updated on 20020613

      @@ -105,7 +104,9 @@ detect problems such as:
    • Reading/writing inappropriate areas on the stack
    • Memory leaks -- where pointers to malloc'd blocks are lost forever
      • -
    • Mismatched use of malloc/new/new [] vs free/delete/delete []
      • +
    • Mismatched use of malloc/new/new [] vs free/delete/delete + []
      • +
    • Some misuses of the POSIX pthreads API
    Problems like these can be difficult to find by other means, often @@ -116,12 +117,12 @@ difficult-to-diagnose crashes. Valgrind is closely tied to details of the CPU, operating system and to a less extent, compiler and basic C libraries. This makes it difficult to make it portable, so I have chosen at the outset to -concentrate on what I believe to be a widely used platform: Red Hat -Linux 7.2, on x86s. Valgrind uses the standard Unix -./configure, make, make install -mechanism, and I have attempted to ensure that it works on machines -with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover -the vast majority of modern Linux installations. +concentrate on what I believe to be a widely used platform: Linux on +x86s. Valgrind uses the standard Unix ./configure, +make, make install mechanism, and I have +attempted to ensure that it works on machines with kernel 2.2 or 2.4 +and glibc 2.1.X or 2.2.X. This should cover the vast majority of +modern Linux installations.

    @@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of higher optimisation levels anyway, so you don't lose much there.

    -Note that as of 1 May 2002 Valgrind does not understand the DWARF -debugging format, which is unfortunate since the upcoming gcc-3.1 uses -it by default. Valgrind only knows about the older "stabs" format. -If you use gcc-3.1 or above, you can still ask for stabs-format debug -info by passing -gstabs to gcc. +Valgrind understands both the older "stabs" debugging format, used by +gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1 +and later.

    Then just run your application, but place the word @@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These limits are defined in vg_include.h and can be increased if necessary. +

    To avoid this cutoff you can use the +--error-limit=no flag. Then valgrind will always show +errors, regardless of how many there are. Use this flag carefully, +since it may have a dire effect on performance. + +

    2.4  Suppressing errors

    @@ -553,15 +558,23 @@ follows: Note that gcc 2.96 is the default compiler on some popular Linux distributions (RedHat 7.X, Mandrake) and so you may well need to use this flag. Do not use it if you do not have to, as it can - cause real errors to be overlooked. A better option is to use a - gcc/g++ which works properly; 2.95.3 seems to be a good choice. + cause real errors to be overlooked. Another option is to use a + gcc/g++ which does not generate accesses below the stack + pointer. 2.95.3 seems to be a good choice in this respect.

    - Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly - buggy, so you may need to issue this flag if you use 3.0.4. A + Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar + bug, so you may need to issue this flag if you use 3.0.4. A while later (early Apr 02) this is confirmed as a scheduling bug in g++-3.0.4.


    • +

  • --error-limit=yes [default]
    + --error-limit=no

    When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.


    • +

  • --cachesim=no [default]
    --cachesim=yes

    When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.

    -

  • Warning: client exiting by calling exit(<number>). - Bye! -
    - Your program has called the exit system call, which - will immediately terminate the process. You'll get no exit-time - error summaries or leak checks. Note that this is not the same - as your program calling the ANSI C function exit() - -- that causes a normal, controlled shutdown of Valgrind. -

  • Warning: client switching stacks?
    Valgrind spotted such a large change in the stack pointer, %esp, @@ -961,19 +965,6 @@ Most of these only appear if you run in verbose mode (enabled by The call will still have gone through, but you may get spurious errors after this as a result of the non-update of the memory info.

    -

  • Warning: unblocking signal <number> due to - sigprocmask -
    - Really just a diagnostic from the signal simulation machinery. - This message will appear if your program handles a signal by - first longjmping out of the signal handler, - and then unblocking the signal with sigprocmask - -- a standard signal-handling idiom. -

    -

  • Warning: bad signal number <number> in __NR_sigaction. -
    - Probably indicates a bug in the signal simulation machinery. -

  • Warning: set address range perms: large range <number>
    Diagnostic message, mostly for my benefit, to do with memory @@ -988,7 +979,7 @@ A suppression file describes a bunch of errors which, for one reason or another, you don't want Valgrind to tell you about. Usually the reason is that the system libraries are buggy but unfixable, at least within the scope of the current debugging session. Multiple -suppresions files are allowed. By default, Valgrind uses +suppressions files are allowed. By default, Valgrind uses $PREFIX/lib/valgrind/default.supp.

    @@ -1206,8 +1197,8 @@ A brief description of the available macros:

    2.9  Support for POSIX Pthreads

    As of late April 02, Valgrind supports programs which use POSIX -pthreads. Doing this has proved technically challenging and is still -in progress, but it works well enough, for significant threaded +pthreads. Doing this has proved technically challenging but is now +mostly complete. It works well enough for significant threaded applications to work.

    It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.

    Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.

    -The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:

    • Mutexes, condition variables, thread-specific data, - pthread_once and basic semaphore functions - (sem_*) currently work. -

      -

    • Various attribute-like calls are handled but ignored. - You get a warning message. -

      -

    • The main big omission is proper cleanup support for cancellation. - pthread_cancel works, but instantly nukes the target - thread without giving it any chance to clean up. Also, when a - thread exits, it does not run any cleanup handlers. -

      -

    • Other omissions are: the detachedness state of threads is ignored. - This means detached threads hang around and clog up scheduler - slots forever when they finish. Calls for reader-writer locks are - have dummy stubs with no functionality right now. You get a + pthread_once, reader-writer locks, semaphores, + cleanup stacks, cancellation and thread detaching currently work. + Various attribute-like calls are handled but ignored; you get a warning message.

    • Currently the following syscalls are thread-safe (nonblocking): write read nanosleep - sleep select and poll. + sleep select poll + recvmsg and + accept.

      -

    • The POSIX requirement that each thread have its own - signal-blocking mask is now implemented. +
    • Signals in pthreads are now handled properly(ish): pthread_sigmask, pthread_kill, - pthread_sigwait and raise should all now - work as POSIX requires. + sigwait and raise are now implemented. + Each thread has its own signal mask, as POSIX requires. + It's a bit kludgey -- there's a system-wide pending signal set, + rather than one for each thread. But hey.
    As of 18 May 02, the following threaded programs now work fine on my RedHat 7.2 box: Opera 6.0Beta2, KNode in KDE 3.0, Mozilla-0.9.2.1 and Galeon-0.11.3, both as supplied with RedHat 7.2. Also Mozilla 1.0RC2. - +OpenOffice 1.0. MySQL 3.something (the current stable release).

    2.10  Building and installing

    @@ -1279,8 +1259,18 @@ attempted to ensure that it works on machines with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. I don't think there is much else to say. There are no options apart from the usual --prefix that you should give to ./configure. +

    -Let me know if you have build problems. +The configure script tests the version of the X server +currently indicated by the current $DISPLAY. This is a +known bug. The intention was to detect the version of the current +XFree86 client libraries, so that correct suppressions could be +selected for them, but instead the test checks the server version. +This is just plain wrong. + +

    +Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +

    • --I1=<size>,<associativity>,<line_size>
      --D1=<size>,<associativity>,<line_size>
      --L2=<size>,<associativity>,<line_size>

      diff --git a/docs/manual.html b/docs/manual.html index 9756d38088..8c61ce4956 100644 --- a/docs/manual.html +++ b/docs/manual.html @@ -24,9 +24,8 @@   -

      Valgrind, snapshot 20020522

      -
      This manual was majorly updated on 20020501
      -
      This manual was minorly updated on 20020603
      +

      Valgrind, version 1.0

      +
      This manual was majorly updated on 20020613

      @@ -105,7 +104,9 @@ detect problems such as:
    • Reading/writing inappropriate areas on the stack
    • Memory leaks -- where pointers to malloc'd blocks are lost forever
      • -
    • Mismatched use of malloc/new/new [] vs free/delete/delete []
      • +
    • Mismatched use of malloc/new/new [] vs free/delete/delete + []
      • +
    • Some misuses of the POSIX pthreads API
    Problems like these can be difficult to find by other means, often @@ -116,12 +117,12 @@ difficult-to-diagnose crashes. Valgrind is closely tied to details of the CPU, operating system and to a less extent, compiler and basic C libraries. This makes it difficult to make it portable, so I have chosen at the outset to -concentrate on what I believe to be a widely used platform: Red Hat -Linux 7.2, on x86s. Valgrind uses the standard Unix -./configure, make, make install -mechanism, and I have attempted to ensure that it works on machines -with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover -the vast majority of modern Linux installations. +concentrate on what I believe to be a widely used platform: Linux on +x86s. Valgrind uses the standard Unix ./configure, +make, make install mechanism, and I have +attempted to ensure that it works on machines with kernel 2.2 or 2.4 +and glibc 2.1.X or 2.2.X. This should cover the vast majority of +modern Linux installations.

    @@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of higher optimisation levels anyway, so you don't lose much there.

    -Note that as of 1 May 2002 Valgrind does not understand the DWARF -debugging format, which is unfortunate since the upcoming gcc-3.1 uses -it by default. Valgrind only knows about the older "stabs" format. -If you use gcc-3.1 or above, you can still ask for stabs-format debug -info by passing -gstabs to gcc. +Valgrind understands both the older "stabs" debugging format, used by +gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1 +and later.

    Then just run your application, but place the word @@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These limits are defined in vg_include.h and can be increased if necessary. +

    To avoid this cutoff you can use the +--error-limit=no flag. Then valgrind will always show +errors, regardless of how many there are. Use this flag carefully, +since it may have a dire effect on performance. + +

    2.4  Suppressing errors

    @@ -553,15 +558,23 @@ follows: Note that gcc 2.96 is the default compiler on some popular Linux distributions (RedHat 7.X, Mandrake) and so you may well need to use this flag. Do not use it if you do not have to, as it can - cause real errors to be overlooked. A better option is to use a - gcc/g++ which works properly; 2.95.3 seems to be a good choice. + cause real errors to be overlooked. Another option is to use a + gcc/g++ which does not generate accesses below the stack + pointer. 2.95.3 seems to be a good choice in this respect.

    - Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly - buggy, so you may need to issue this flag if you use 3.0.4. A + Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar + bug, so you may need to issue this flag if you use 3.0.4. A while later (early Apr 02) this is confirmed as a scheduling bug in g++-3.0.4.


    • +

  • --error-limit=yes [default]
    + --error-limit=no

    When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.


    • +

  • --cachesim=no [default]
    --cachesim=yes

    When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.

    -

  • Warning: client exiting by calling exit(<number>). - Bye! -
    - Your program has called the exit system call, which - will immediately terminate the process. You'll get no exit-time - error summaries or leak checks. Note that this is not the same - as your program calling the ANSI C function exit() - -- that causes a normal, controlled shutdown of Valgrind. -

  • Warning: client switching stacks?
    Valgrind spotted such a large change in the stack pointer, %esp, @@ -961,19 +965,6 @@ Most of these only appear if you run in verbose mode (enabled by The call will still have gone through, but you may get spurious errors after this as a result of the non-update of the memory info.

    -

  • Warning: unblocking signal <number> due to - sigprocmask -
    - Really just a diagnostic from the signal simulation machinery. - This message will appear if your program handles a signal by - first longjmping out of the signal handler, - and then unblocking the signal with sigprocmask - -- a standard signal-handling idiom. -

    -

  • Warning: bad signal number <number> in __NR_sigaction. -
    - Probably indicates a bug in the signal simulation machinery. -

  • Warning: set address range perms: large range <number>
    Diagnostic message, mostly for my benefit, to do with memory @@ -988,7 +979,7 @@ A suppression file describes a bunch of errors which, for one reason or another, you don't want Valgrind to tell you about. Usually the reason is that the system libraries are buggy but unfixable, at least within the scope of the current debugging session. Multiple -suppresions files are allowed. By default, Valgrind uses +suppressions files are allowed. By default, Valgrind uses $PREFIX/lib/valgrind/default.supp.

    @@ -1206,8 +1197,8 @@ A brief description of the available macros:

    2.9  Support for POSIX Pthreads

    As of late April 02, Valgrind supports programs which use POSIX -pthreads. Doing this has proved technically challenging and is still -in progress, but it works well enough, for significant threaded +pthreads. Doing this has proved technically challenging but is now +mostly complete. It works well enough for significant threaded applications to work.

    It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.

    Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.

    -The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:

    • Mutexes, condition variables, thread-specific data, - pthread_once and basic semaphore functions - (sem_*) currently work. -

      -

    • Various attribute-like calls are handled but ignored. - You get a warning message. -

      -

    • The main big omission is proper cleanup support for cancellation. - pthread_cancel works, but instantly nukes the target - thread without giving it any chance to clean up. Also, when a - thread exits, it does not run any cleanup handlers. -

      -

    • Other omissions are: the detachedness state of threads is ignored. - This means detached threads hang around and clog up scheduler - slots forever when they finish. Calls for reader-writer locks are - have dummy stubs with no functionality right now. You get a + pthread_once, reader-writer locks, semaphores, + cleanup stacks, cancellation and thread detaching currently work. + Various attribute-like calls are handled but ignored; you get a warning message.

    • Currently the following syscalls are thread-safe (nonblocking): write read nanosleep - sleep select and poll. + sleep select poll + recvmsg and + accept.

      -

    • The POSIX requirement that each thread have its own - signal-blocking mask is now implemented. +
    • Signals in pthreads are now handled properly(ish): pthread_sigmask, pthread_kill, - pthread_sigwait and raise should all now - work as POSIX requires. + sigwait and raise are now implemented. + Each thread has its own signal mask, as POSIX requires. + It's a bit kludgey -- there's a system-wide pending signal set, + rather than one for each thread. But hey.
    As of 18 May 02, the following threaded programs now work fine on my RedHat 7.2 box: Opera 6.0Beta2, KNode in KDE 3.0, Mozilla-0.9.2.1 and Galeon-0.11.3, both as supplied with RedHat 7.2. Also Mozilla 1.0RC2. - +OpenOffice 1.0. MySQL 3.something (the current stable release).

    2.10  Building and installing

    @@ -1279,8 +1259,18 @@ attempted to ensure that it works on machines with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. I don't think there is much else to say. There are no options apart from the usual --prefix that you should give to ./configure. +

    -Let me know if you have build problems. +The configure script tests the version of the X server +currently indicated by the current $DISPLAY. This is a +known bug. The intention was to detect the version of the current +XFree86 client libraries, so that correct suppressions could be +selected for them, but instead the test checks the server version. +This is just plain wrong. + +

    +Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +

    • --I1=<size>,<associativity>,<line_size>
      --D1=<size>,<associativity>,<line_size>
      --L2=<size>,<associativity>,<line_size>

      diff --git a/memcheck/docs/manual.html b/memcheck/docs/manual.html index 9756d38088..8c61ce4956 100644 --- a/memcheck/docs/manual.html +++ b/memcheck/docs/manual.html @@ -24,9 +24,8 @@   -

      Valgrind, snapshot 20020522

      -
      This manual was majorly updated on 20020501
      -
      This manual was minorly updated on 20020603
      +

      Valgrind, version 1.0

      +
      This manual was majorly updated on 20020613

      @@ -105,7 +104,9 @@ detect problems such as:
    • Reading/writing inappropriate areas on the stack
    • Memory leaks -- where pointers to malloc'd blocks are lost forever
      • -
    • Mismatched use of malloc/new/new [] vs free/delete/delete []
      • +
    • Mismatched use of malloc/new/new [] vs free/delete/delete + []
      • +
    • Some misuses of the POSIX pthreads API
    Problems like these can be difficult to find by other means, often @@ -116,12 +117,12 @@ difficult-to-diagnose crashes. Valgrind is closely tied to details of the CPU, operating system and to a less extent, compiler and basic C libraries. This makes it difficult to make it portable, so I have chosen at the outset to -concentrate on what I believe to be a widely used platform: Red Hat -Linux 7.2, on x86s. Valgrind uses the standard Unix -./configure, make, make install -mechanism, and I have attempted to ensure that it works on machines -with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. This should cover -the vast majority of modern Linux installations. +concentrate on what I believe to be a widely used platform: Linux on +x86s. Valgrind uses the standard Unix ./configure, +make, make install mechanism, and I have +attempted to ensure that it works on machines with kernel 2.2 or 2.4 +and glibc 2.1.X or 2.2.X. This should cover the vast majority of +modern Linux installations.

    @@ -196,11 +197,9 @@ errors. -O gets you the vast majority of the benefits of higher optimisation levels anyway, so you don't lose much there.

    -Note that as of 1 May 2002 Valgrind does not understand the DWARF -debugging format, which is unfortunate since the upcoming gcc-3.1 uses -it by default. Valgrind only knows about the older "stabs" format. -If you use gcc-3.1 or above, you can still ask for stabs-format debug -info by passing -gstabs to gcc. +Valgrind understands both the older "stabs" debugging format, used by +gcc versions prior to 3.1, and the newer DWARF2 format used by gcc 3.1 +and later.

    Then just run your application, but place the word @@ -292,6 +291,12 @@ the 300/30000 limits apply after suppressed errors are removed. These limits are defined in vg_include.h and can be increased if necessary. +

    To avoid this cutoff you can use the +--error-limit=no flag. Then valgrind will always show +errors, regardless of how many there are. Use this flag carefully, +since it may have a dire effect on performance. + +

    2.4  Suppressing errors

    @@ -553,15 +558,23 @@ follows: Note that gcc 2.96 is the default compiler on some popular Linux distributions (RedHat 7.X, Mandrake) and so you may well need to use this flag. Do not use it if you do not have to, as it can - cause real errors to be overlooked. A better option is to use a - gcc/g++ which works properly; 2.95.3 seems to be a good choice. + cause real errors to be overlooked. Another option is to use a + gcc/g++ which does not generate accesses below the stack + pointer. 2.95.3 seems to be a good choice in this respect.

    - Unfortunately (27 Feb 02) it looks like g++ 3.0.4 is similarly - buggy, so you may need to issue this flag if you use 3.0.4. A + Unfortunately (27 Feb 02) it looks like g++ 3.0.4 has a similar + bug, so you may need to issue this flag if you use 3.0.4. A while later (early Apr 02) this is confirmed as a scheduling bug in g++-3.0.4.


    • +

  • --error-limit=yes [default]
    + --error-limit=no

    When enabled, valgrind stops + reporting errors after 30000 in total, or 300 different ones, + have been seen. This is to stop the error tracking machinery + from becoming a huge performance overhead in programs with many + errors.


    • +

  • --cachesim=no [default]
    --cachesim=yes

    When enabled, turns off memory checking, and turns on cache profiling. Cache profiling is @@ -921,18 +934,9 @@ Most of these only appear if you run in verbose mode (enabled by any more. It seems unlikely that collecting even more different ones would be of practical help to anybody, and it avoids the danger that Valgrind spends more and more of its time comparing - new errors against an ever-growing collection. As above, the 500 + new errors against an ever-growing collection. As above, the 300 number is a compile-time constant.

    -

  • Warning: client exiting by calling exit(<number>). - Bye! -
    - Your program has called the exit system call, which - will immediately terminate the process. You'll get no exit-time - error summaries or leak checks. Note that this is not the same - as your program calling the ANSI C function exit() - -- that causes a normal, controlled shutdown of Valgrind. -

  • Warning: client switching stacks?
    Valgrind spotted such a large change in the stack pointer, %esp, @@ -961,19 +965,6 @@ Most of these only appear if you run in verbose mode (enabled by The call will still have gone through, but you may get spurious errors after this as a result of the non-update of the memory info.

    -

  • Warning: unblocking signal <number> due to - sigprocmask -
    - Really just a diagnostic from the signal simulation machinery. - This message will appear if your program handles a signal by - first longjmping out of the signal handler, - and then unblocking the signal with sigprocmask - -- a standard signal-handling idiom. -

    -

  • Warning: bad signal number <number> in __NR_sigaction. -
    - Probably indicates a bug in the signal simulation machinery. -

  • Warning: set address range perms: large range <number>
    Diagnostic message, mostly for my benefit, to do with memory @@ -988,7 +979,7 @@ A suppression file describes a bunch of errors which, for one reason or another, you don't want Valgrind to tell you about. Usually the reason is that the system libraries are buggy but unfixable, at least within the scope of the current debugging session. Multiple -suppresions files are allowed. By default, Valgrind uses +suppressions files are allowed. By default, Valgrind uses $PREFIX/lib/valgrind/default.supp.

    @@ -1206,8 +1197,8 @@ A brief description of the available macros:

    2.9  Support for POSIX Pthreads

    As of late April 02, Valgrind supports programs which use POSIX -pthreads. Doing this has proved technically challenging and is still -in progress, but it works well enough, for significant threaded +pthreads. Doing this has proved technically challenging but is now +mostly complete. It works well enough for significant threaded applications to work.

    It works as follows: threaded apps are (dynamically) linked against @@ -1223,52 +1214,41 @@ multiprocessor version of Valgrind, but it does mean that threaded apps run only on one CPU, even if you have a multiprocessor machine.

    Valgrind schedules your threads in a round-robin fashion, with all -threads having equal priority. It switches threads every 20000 basic -blocks (typically around 120000 x86 instructions), which means you'll +threads having equal priority. It switches threads every 50000 basic +blocks (typically around 300000 x86 instructions), which means you'll get a much finer interleaving of thread executions than when run natively. This in itself may cause your program to behave differently if you have some kind of concurrency, critical race, locking, or similar, bugs.

    -The current (18 May 02) state of pthread support is as follows. Please -note that things are advancing rapidly, so the situation may have -improved by the time you read this -- check the web site for further -updates. +The current (valgrind-1.0 release) state of pthread support is as +follows:

    • Mutexes, condition variables, thread-specific data, - pthread_once and basic semaphore functions - (sem_*) currently work. -

      -

    • Various attribute-like calls are handled but ignored. - You get a warning message. -

      -

    • The main big omission is proper cleanup support for cancellation. - pthread_cancel works, but instantly nukes the target - thread without giving it any chance to clean up. Also, when a - thread exits, it does not run any cleanup handlers. -

      -

    • Other omissions are: the detachedness state of threads is ignored. - This means detached threads hang around and clog up scheduler - slots forever when they finish. Calls for reader-writer locks are - have dummy stubs with no functionality right now. You get a + pthread_once, reader-writer locks, semaphores, + cleanup stacks, cancellation and thread detaching currently work. + Various attribute-like calls are handled but ignored; you get a warning message.

    • Currently the following syscalls are thread-safe (nonblocking): write read nanosleep - sleep select and poll. + sleep select poll + recvmsg and + accept.

      -

    • The POSIX requirement that each thread have its own - signal-blocking mask is now implemented. +
    • Signals in pthreads are now handled properly(ish): pthread_sigmask, pthread_kill, - pthread_sigwait and raise should all now - work as POSIX requires. + sigwait and raise are now implemented. + Each thread has its own signal mask, as POSIX requires. + It's a bit kludgey -- there's a system-wide pending signal set, + rather than one for each thread. But hey.
    As of 18 May 02, the following threaded programs now work fine on my RedHat 7.2 box: Opera 6.0Beta2, KNode in KDE 3.0, Mozilla-0.9.2.1 and Galeon-0.11.3, both as supplied with RedHat 7.2. Also Mozilla 1.0RC2. - +OpenOffice 1.0. MySQL 3.something (the current stable release).

    2.10  Building and installing

    @@ -1279,8 +1259,18 @@ attempted to ensure that it works on machines with kernel 2.2 or 2.4 and glibc 2.1.X or 2.2.X. I don't think there is much else to say. There are no options apart from the usual --prefix that you should give to ./configure. +

    -Let me know if you have build problems. +The configure script tests the version of the X server +currently indicated by the current $DISPLAY. This is a +known bug. The intention was to detect the version of the current +XFree86 client libraries, so that correct suppressions could be +selected for them, but instead the test checks the server version. +This is just plain wrong. + +

    +Apart from that there is no excitement here. Let me know if you have +build problems. @@ -2148,6 +2138,7 @@ Cachegrind accepts all the options that Valgrind does, although some of them The interesting cache-simulation specific options are: +

    • --I1=<size>,<associativity>,<line_size>
      --D1=<size>,<associativity>,<line_size>
      --L2=<size>,<associativity>,<line_size>