valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Nicholas N. <nj...@ca...>]

On Wed, 7 May 2003, Troels Walsted Hansen wrote:

> This is the expected behavior of the program.
>
> rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
>
> This is what happens in Valgrind. RH8 and RH9 uses BerkeleyDB 4.0.14,

> rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
> nosuchfile.db: Resource temporarily unavailable')

It's possible that Valgrind's doing something slightly different with file
handling that means you get a different behaviour.  Do you have more
information about what exactly is happening to prompt this error?  Eg. is
it trying to open a file with the open() system call, or something like
that?  It's very difficult to know what the problem is from your
description so far.

N

[Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Troels W. H. <tr...@th...>]

Valgrind 1.9.6 runs much better on RH8+glibc 2.3.2/RH9, but it doesn't
appear to be perfect yet. I have reproduced this problem on both of the
mentioned platforms.

This is the expected behavior of the program.

$ python dbboguserrno.py
Traceback (most recent call last):
  File "dbboguserrno.py", line 4, in ?
    filetype = db.DB_BTREE)
  File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
    d.open(filename, dbname, filetype, flags, mode)
rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')

This is what happens in Valgrind. RH8 and RH9 uses BerkeleyDB 4.0.14,
with a custom compiled Python interpreter and BerkeleyDB 3.3.11 I get
"bsddb3._db.DBError: (9, 'Bad file descriptor -- nosuchfile.db: Bad file
descriptor')" errors instead.

$ valgrind -v python dbboguserrno.py
==7099== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==7099== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==7099== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.
==7099== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==7099== Startup, with flags:
==7099==    --suppressions=/usr/local/lib/valgrind/default.supp
==7099==    -v
==7099== Reading suppressions file: /usr/local/lib/valgrind/default.supp
==7099== Estimated CPU clock rate is 702 MHz
==7099==
==7099== Reading syms from /usr/bin/python
==7099==    object doesn't have any debug info
==7099== Reading syms from /lib/ld-2.3.2.so
==7099==    object doesn't have any debug info
==7099== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so
==7099== Reading syms from /usr/local/lib/valgrind/valgrind.so
==7099== Reading syms from /lib/libdl-2.3.2.so
==7099==    object doesn't have any debug info
==7099== Reading syms from /usr/local/lib/valgrind/libpthread.so
==7099== Reading syms from /lib/libutil-2.3.2.so
==7099==    object doesn't have any debug info
==7099== Reading syms from /lib/libm-2.3.2.so
==7099==    object doesn't have a symbol table
==7099==    object doesn't have any debug info
==7099== Reading syms from /lib/libc-2.3.2.so
==7099==    object doesn't have a symbol table
==7099==    object doesn't have any debug info
==7099== Reading syms from
/usr/lib/python2.2/lib-dynload/structmodule.so
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40008D55: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099==    by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40008D59: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099==    by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40009517: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099==
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40009565: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099== Reading syms from
/usr/lib/python2.2/lib-dynload/_codecsmodule.so
==7099== Reading syms from
/usr/lib/python2.2/site-packages/rpmdb/_rpmdb.so
==7099== Reading syms from /usr/lib/librpm-4.1.so
==7099== Reading syms from /usr/lib/librpmdb-4.1.so
==7099== Reading syms from /usr/lib/librpmio-4.1.so
==7099== Reading syms from /usr/lib/libpopt.so.0.0.0
==7099== Reading syms from /lib/librt-2.3.2.so
==7099==    object doesn't have any debug info
==7099== Reading syms from /usr/lib/libelf.so.0.8.2
==7099== Reading syms from /usr/lib/libbz2.so.1.0.2
==7099== Reading syms from /usr/lib/python2.2/lib-dynload/cPickle.so
==7099== Reading syms from /usr/lib/python2.2/lib-dynload/cStringIO.so
Traceback (most recent call last):
  File "dbboguserrno.py", line 4, in ?
    filetype = db.DB_BTREE)
  File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
    d.open(filename, dbname, filetype, flags, mode)
rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
nosuchfile.db: Resource temporarily unavailable')
==7099==
==7099== ERROR SUMMARY: 48 errors from 4 contexts (suppressed: 2 from 1)
==7099==
==7099== 12 errors in context 1 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40009565: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099==
==7099== 12 errors in context 2 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40009517: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x403774AE: _dl_open (in /lib/libc-2.3.2.so)
==7099==
==7099== 12 errors in context 3 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40008D59: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099==    by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
==7099==
==7099== 12 errors in context 4 of 4:
==7099== Conditional jump or move depends on uninitialised value(s)
==7099==    at 0x40008D55: elf_dynamic_do_rel.7 (in /lib/ld-2.3.2.so)
==7099==    by 0x4000942A: _dl_relocate_object_internal (in
/lib/ld-2.3.2.so)
==7099==    by 0x40377D90: (within /lib/libc-2.3.2.so)
==7099==    by 0x4000B115: _dl_catch_error_internal (in
/lib/ld-2.3.2.so)
--7099--
--7099-- supp:    2 __pthread_mutex_unlock/_IO_funlockfile
==7099==
==7099== IN SUMMARY: 48 errors from 4 contexts (suppressed: 2 from 1)
==7099==
==7099== malloc/free: in use at exit: 120602 bytes in 1147 blocks.
==7099== malloc/free: 31726 allocs, 30579 frees, 2322038 bytes
allocated.
==7099==
--7099--     TT/TC: 0 tc sectors discarded.
--7099--            11223 chainings, 0 unchainings.
--7099-- translate: new     14012 (209064 -> 2646829; ratio 126:10)
--7099--            discard 0 (0 -> 0; ratio 0:10).
--7099--  dispatch: 6900000 jumps (bb entries), of which 1304733 (18%)
were unchained.
--7099--            140/88816 major/minor sched events.  17845 tt_fast
misses.
--7099-- reg-alloc: 1950 t-req-spill, 497014+11920 orig+spill uis, 70141
total-reg-r.
--7099--    sanity: 141 cheap, 6 expensive checks.
--7099--    ccalls: 51904 C calls, 58% saves+restores avoided (178738
bytes)
--7099--            71568 args, avg 0.87 setup instrs each (17770 bytes)
--7099--            0% clear the stack (155712 bytes)
--7099--            19332 retvals, 34% of reg-reg movs avoided (12842
bytes)

-- 
Troels Walsted Hansen

Re: [Valgrind-users] valgrind exit messages.

[Nicholas N. <nj...@ca...>]

On Mon, 5 May 2003, Julian Seward wrote:

> > Below is the error summary at exit of my program.  I understand the
> > 195000 bytes in 3 block possibly lost, and it isn't a bug.  The part
> > that I don't understand, and can't seem to find an explanation for in
> > the documents, is the section running from the line of "TT/TC:" down to
> > "reg-alloc:".
>
> Ignore them; they are statistics about valgrind's internal workings and
> have nothing much to do with your program.

And don't use -v if you don't want to see them.

N

[Valgrind-users] Re: Emacs mode?

[Andreas O. <oe...@oe...>]

Hi Arnaud,

On Tue, 6 May 2003, Arnaud Desitter wrote:

> ;; Currently this regexp only matches the first error.
> ;; Thanks to Hans Petter Jansson <hp...@xi...> for his regexp wisdom.
> (setq compilation-error-regexp-alist
>   (append compilation-error-regexp-alist
>     '(("^==[0-9]+==[^(]+\(\\([^:]+\\):\\([0-9]+\\)"
>        1 2))))

thanks a lot! This works nicely when called from the
compilation-mode-hook, and despite the comment it works
for all lines matching the RE, not just the first one.

Regards,
--Andreas

Re: [Valgrind-users] Thanks, compilation problem, Emacs mode?

[Arnaud D. <arn...@ge...>]

----- Original Message -----
From: "Andreas Oesterhelt" <oe...@oe...>
To: <val...@li...>
Sent: Tuesday, May 06, 2003 6:50 PM
Subject: [Valgrind-users] Thanks, compilation problem, Emacs mode?

> Third, does anyone know of a (X)emacs mode that would parse valgrind
> output and jump to the right locations in the source files on click, just
> like the compilation mode does? If not, does anyone feel like writing one?
> ,-)

Try that in your .emacs:

;; from Ole Aamot (ol...@gn...)
;; Valgrind (memory debugger for x86 GNU/Linux):
;;  ==1332==    at 0x8008621: main (vtest.c:180)
;; Currently this regexp only matches the first error.
;; Thanks to Hans Petter Jansson <hp...@xi...> for his regexp wisdom.
(setq compilation-error-regexp-alist
  (append compilation-error-regexp-alist
    '(("^==[0-9]+==[^(]+\(\\([^:]+\\):\\([0-9]+\\)"
       1 2))))

Regards,

[Valgrind-users] Thanks, compilation problem, Emacs mode?

[Andreas O. <oe...@oe...>]

Hi,

..first of all: Thanks a lot for providing this extremely useful tool! The
per-allocation stack traces saved me a lot of work debugging!

Second, when compiling valgrind 1.9.6 I noticed a small problem which
might either be due to a weirdness in my local setup (quite possible!) or
valgrind's build process:
On my glibc 2.2 system which had been correctly recognized by the
configure script (#define GLIBC_2_2 1 set in config.h), compilation of
coregrind/vg_intercept.c failed with some type checking errors involving
struct timeval.  Moving the #include <sys/time.h> statement out of its
#ifdef GLIBC_2_1 resolved the issue.

Third, does anyone know of a (X)emacs mode that would parse valgrind
output and jump to the right locations in the source files on click, just
like the compilation mode does? If not, does anyone feel like writing one?
,-)

Cheers from a happy user!

Regards,
--Andreas

[Valgrind-users] Quick question about tracing children

[Crispin F. <cr...@th...>]

While performing some tests with valgrind, I have found a slight
difference between the documentation and the behaviour with regards to
tracing child processes. When a child process is fork'd and then exec'd
the tracing behaviour correctly follows the --trace-children flag.
However if the child process is created just by forking the main
program, then it is always traced. 

Is this the desired behaviour? I expected it to behave like strace and
ltrace and the like where they stop tracing after the fork, not after
the exec.

(attached is a small test program that demonstrates the tracing of
children created just be a fork)

Cheers

Crispin

[Valgrind-users] valgrind-1.9.6 is available

[Julian S. <js...@ac...>]

Version 1.9.6 (7 May 2003 or thereabouts)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Major changes in 1.9.6:

- Improved threading support for glibc >= 2.3.2 (SuSE 8.2,
  RedHat 9, to name but two ...)  It turned out that 1.9.5
  had problems with threading support on glibc >= 2.3.2,
  usually manifested by threaded programs deadlocking in system calls,
  or running unbelievably slowly.  Hopefully these are fixed now.  1.9.6
  is the first valgrind which gives reasonable support for
  glibc-2.3.2.  Also fixed a 2.3.2 problem with pthread_atfork().

- Majorly expanded FAQ.txt.  We've added workarounds for all
  common problems for which a workaround is known.

Minor changes in 1.9.6:

- Fix identification of the main thread's stack.  Incorrect
  identification of it was causing some on-stack addresses to not get
  identified as such.  This only affected the usefulness of some error
  messages; the correctness of the checks made is unchanged.

- Support for kernels >= 2.5.68.

- Dummy implementations of __libc_current_sigrtmin, 
  __libc_current_sigrtmax and __libc_allocate_rtsig, hopefully
  good enough to keep alive programs which previously died for lack of
  them.

- Fix bug in the VALGRIND_DISCARD_TRANSLATIONS client request.

- Fix bug in the DWARF2 debug line info loader, when instructions 
  following each other have source lines far from each other 
  (e.g. with inlined functions).

- Debug info reading: read symbols from both "symtab" and "dynsym"
  sections, rather than merely from the one that comes last in the
  file.

- New syscall support: prctl(), creat(), lookup_dcookie().

- When checking calls to accept(), recvfrom(), getsocketopt(),
  don't complain if buffer values are NULL.

- Try and avoid assertion failures in
  mash_LD_PRELOAD_and_LD_LIBRARY_PATH.

- Minor bug fixes in cg_annotate.

Re: [Valgrind-users] valgrind exit messages.

[Julian S. <js...@ac...>]

> Below is the error summary at exit of my program.  I understand the
> 195000 bytes in 3 block possibly lost, and it isn't a bug.  The part
> that I don't understand, and can't seem to find an explanation for in
> the documents, is the section running from the line of "TT/TC:" down to
> "reg-alloc:".

Ignore them; they are statistics about valgrind's internal workings and
have nothing much to do with your program.

J

[Valgrind-users] valgrind exit messages.

[Eric M. M. <emo...@be...>]

All,

I just started using valgrind to debug my program.  To date, the program 
has not crashed and so I have not seen if valgrind will flag any errors, 
but I am trying to understand the output for the normal case.

I run valgrind from within a shell script that I'll be asking my users 
to execute.  The shell script is as follows:

#!/bin/sh
LD_LIBRARY_PATH=/home/emonsler/usr/local/lib:/usr/lib:/usr/openwin/lib:/usr/local/lib
/home/emonsler/testing/bin/valgrind --num-callers=8 
--logfile=/tmp/LindaCrash --workaround-gcc296-bugs=yes --leak-check=yes 
--run-libc-freeres=no -v /home/emonsler/usr/local/bin/avdisplay2.55 $*


Below is the error summary at exit of my program.  I understand the 
195000 bytes in 3 block possibly lost, and it isn't a bug.  The part 
that I don't understand, and can't seem to find an explanation for in 
the documents, is the section running from the line of "TT/TC:" down to 
"reg-alloc:".

Where are those documented?  Are the values shown errors or warnings?

Thanks in advance, valgrind looks very promising and I wish that I had 
known about it when first debugging this program.

Please cc:me on responses, as I am not subscribed to the list.

TIA,

Eric Monsler


==9748== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 28 from 1)
--9748--
--9748-- supp:   28 
write(buf)/libc-2.2.4.so/libX11.so.6.2/libX11.so.6.2(Param)
==9748== malloc/free: in use at exit: 476605 bytes in 3358 blocks.
==9748== malloc/free: 13320394 allocs, 13317036 frees, 2516779165 bytes 
allocate
d.
==9748==
==9748== searching for pointers to 3358 not-freed blocks.
==9748== checked 8135900 bytes.
==9748==
==9748== 195000 bytes in 3 blocks are possibly lost in loss record 72 of 72
==9748==    at 0x40169340: malloc (vg_clientfuncs.c:103)
==9748==    by 0x40485AF6: g_malloc (gmem.c:177)
==9748==    by 0x80636EE: vReadIncomingUDP (avd_disp_msgs.c:1439)
==9748==    by 0x403B6A1B: gdk_io_invoke (gdkevents.c:882)
==9748==    by 0x4048274B: g_io_unix_dispatch (giounix.c:137)
==9748==    by 0x4048453B: g_main_dispatch (gmain.c:656)
==9748==    by 0x40484D6D: g_main_iterate (gmain.c:877)
==9748==    by 0x40484F5B: g_main_run (gmain.c:935)
==9748==
==9748== LEAK SUMMARY:
==9748==    definitely lost: 0 bytes in 0 blocks.
==9748==    possibly lost:   195000 bytes in 3 blocks.
==9748==    still reachable: 281605 bytes in 3355 blocks.
==9748==         suppressed: 0 bytes in 0 blocks.
==9748== Reachable blocks (those to which a pointer was found) are not 
shown.
==9748== To see them, rerun with: --show-reachable=yes
==9748==
--9748--     TT/TC: 0 tc sectors discarded.
--9748--            24798 chainings, 0 unchainings.
--9748-- translate: new     32046 (514035 -> 7150204; ratio 139:10)
--9748--            discard 0 (0 -> 0; ratio 0:10).
--9748--  dispatch: 8293450000 jumps (bb entries), of which 1422416883 
(17%) wer
e unchained.
--9748--            165870/31416415 major/minor sched events.  2408860 
tt_fast m
isses.
--9748-- reg-alloc: 4906 t-req-spill, 1313936+30807 orig+spill uis, 
158696 total
-reg-r.
--9748--    sanity: 165871 cheap, 6635 expensive checks.
--9748--    ccalls: 161306 C calls, 57% saves+restores avoided (544328 
bytes)
--9748--            205701 args, avg 0.88 setup instrs each (45330 bytes)
--9748--            0% clear the stack (483918 bytes)
--9748--            63626 retvals, 35% of reg-reg movs avoided (43554 bytes)
(

[Valgrind-users] program doesn't start

[Nehal <ne...@ca...>]

Hello,

im having problems running my program with valgrind.
when i type:

valgrind ./myprogram

it seems to work for a while then i get this last
error and it freezes... and i have to kill the xterm:

==947==
==947== Conditional jump or move depends on uninitialised value(s)
==947==    at 0x40160658: memchr (vg_clientfuncs.c:490)
==947==    by 0x403D1F3D: _IO_getline_info_internal (in /lib/libc-2.3.1.so)
==947==    by 0x403D1EC2: _IO_getline_internal (in /lib/libc-2.3.1.so)
==947==    by 0x403D0ECA: _IO_fgets (in /lib/libc-2.3.1.so)
==947==
==947== Use of uninitialised value of size 4
==947==    at 0x405137D6: (within /usr/X11R6/lib/libX11.so.6.2)
==947==    by 0x40513AC9: (within /usr/X11R6/lib/libX11.so.6.2)
==947==    by 0x40513F6A: _XlcResolveLocaleName (in 
/usr/X11R6/lib/libX11.so.6.2)
==947==    by 0x40517BCF: (within /usr/X11R6/lib/libX11.so.6.2)


i know its not doing anything because cpu usage is at 0%

btw, i got latest valgrind (1.9.5)

Nehal

[Valgrind-users] Signal handling and delivery of siginfo_t

[Raymond R. <ra...@co...>]

Hello,
	I have just recently started using valgrind and, I must
add, am impressed - the sheer audacity of the approach is great.
(Thanks to Messrs. Seward and Nethercote, and all the developers.)

I would like to use it on a program I have that does asynchronous
I/O without using select().  It registers a signal handler using
sigaction and, on receipt of SIGIO, extracts the file descriptor
that caused the signal from its second siginfo_t * argument.
Since valgrind passes a NULL pointer to applications when invoking
signal handlers, my program simply segfaults in its handler.


My question is this:  are there any plans to change the signal
handling to support the propagation of the siginfo_t * supplied by
the kernel to the application?  I am guessing that to do so would
be a fair bit of work.  Am I wrong is thinking that valgrind only
maintains a pending flag for each signal, rather than a true queue
of signals like the kernel does?

If this is in the works, I'd be interested to help if I can.  If
not, I'd be happy to start it.  Either way, who should I talk to
about this?


Regards,
	Raymond.

[Valgrind-users] Valgrind craches, but only with calltree

[Ravikiran R. <ra...@ee...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
  Valgrind seems to work fine with any program from KDE CVS HEAD, but the=20
calltree skin seems to crash for all programs with the following error:

eepc005:/<3>kde-cvs/other> calltree ksig
=3D=3D12401=3D=3D Calltree-0.2.95, a cache profiler for x86-linux.
=3D=3D12401=3D=3D Copyright (C) 2002, and GNU GPL'd, by N.Nethercote and=20
J.Weidendorfer.
=3D=3D12401=3D=3D Using valgrind-1.9.5, a program instrumentation system fo=
r=20
x86-linux.
=3D=3D12401=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
=3D=3D12401=3D=3D Estimated CPU clock rate is 1409 MHz
=3D=3D12401=3D=3D For more details, rerun with: -v
=3D=3D12401=3D=3D

valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 7) =
=3D=3D=20
7' failed.

sched status:

Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0x0
=3D=3D12401=3D=3D    at 0x42029D31: __new_exitfn (in /lib/tls/libc-2.3.2.so)
=3D=3D12401=3D=3D    by 0x42029CE8: __cxa_atexit_internal (in /lib/tls/libc=
=2D2.3.2.so)
=3D=3D12401=3D=3D    by 0x40F2E727: (within /usr/lib/libstdc++.so.5.0.3)
=3D=3D12401=3D=3D    by 0x40F2E779: (within /usr/lib/libstdc++.so.5.0.3)

Please report this bug to: js...@ac...

I am running on a stock Redhat 9 on an Athlon 1600+ XP with all RH patches=
=20
applied. Does calltree not support RH9?

Please cc any replies to me as I am not subscribed to the list.

Regards,
Ravi
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sx7NbI8Y8y0oVXcRAuliAJ9TMGA1m9xDKOYPgz33o2NFxDhE7wCfUgFy
2e77D4L2gixdZlsKx3X75xI=3D
=3DwPh7
=2D----END PGP SIGNATURE-----

Re: [Valgrind-users] REPE then 0xF

[Bastien C. <ba...@ch...>]

On Friday 02 May 2003 19:13, Dominic Mazzoni wrote:
> Was anyone else able to reproduce the REPE then 0xF problem using my test
> program?  Just curious...

Yes. Even if I could not run it natively (Athlon), valgrind dutifully choked 
when it encountered the 0xf problem :-)
Just thinking of it: valgrind should therefore also qualify as processor 
emulator, shouldn't it? Like letting run code specifically compiled for the 
PI-IV on Athlons and vice versa.

B.

-- 
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --

Re: [Valgrind-users] REPE then 0xF

[John R. <jr...@Bi...>]

Dominic Mazzoni wrote:
> Was anyone else able to reproduce the REPE then 0xF problem using my test 
> program?  Just curious...

 From IA-32 Intel Architecture Software Developer's Manual, Volume 2: Instruction
Set Reference (24547107.pdf on developer.intel.com; perhaps 2454108.pdf by now):

CMPSS -- Compare Scalar Single-Precision Floating-Point Values
   F3 0F C2 /r ib  CMPSS xmm1, xmm2/m32, imm8

CMPSD -- Compare Scalar Double-Precision Floating-Point Values
   F2 0F C2 /r ib  CMPSD xmm1, xmm3/m32, imm8

MOVQ2DQ -- Move Quadword from MMX to XMM Register
   F3 0F D6  MOVQ2DQ xmm, mm

MOVDQ2Q -- Move Quadword from XMM to MMX Register
   F2 0F D6  MOVDQ2Q mm, xmm

CVTDq2PD -- Convert Packed Doubleword Integers to Packed Double-Precision Floating-
       Point Values
   F3 0F E6  CVTDQ2PD xmm1, xmm2/m64

CVTD2DQ  -- Convert Packed Double-Precision Floating-Point Values to Packed
       Doubleword Integers
   F2 0F E6  CVTPD2DQ xmm1, xmm2/m128


So seeing "F3 0F ..." is not surprising: it is specified behavior, and very
reasonable for a compiler to generate CMPSS.

Furthermore, past generations of hardware always accepted prefixes in any order.
So in theory "0F F3 ..." would be equivalent.  Perhaps there is a move to
require that 0F be the last prefix (it might simplify decoding), but that
would break backwards compatibility in many cases.  0F could be required
as last only for new instructions, of which CMPSS certainly is one.  But
then the checking to require 0F last, only in these 6 cases, might cost more
than just allowing arbitrary order all the time.  [Basically, the opcode
space is over-full.]

-- 
John Reiser, jr...@Bi...

Re: [Valgrind-users] Can i get a warning to issue the stacktrace?

[Nicholas N. <nj...@ca...>]

On Thu, 1 May 2003, Tom Hughes wrote:

> > "Warning: src and dst overlap in memcpy (0xblah, 0xblah, a_length)"
> >
> > Is there any way to get valgrind to dump the call stack on this warning
> > like it does on errors so i could see where this is happening?
>
> I happen to have a patch to make it do that that I've been meaning
> to send it. I'm attaching it to this message...

Committed to CVS HEAD, thanks.

N

[Valgrind-users] REPE then 0xF

[Dominic M. <dma...@ai...>]

Was anyone else able to reproduce the REPE then 0xF problem using my test 
program?  Just curious...

- Dominic

> Message: 10
> Date: Mon, 28 Apr 2003 19:21:08 -0700 (PDT)
> From: Dominic Mazzoni <dma...@ai...>
> To: val...@li...
> Subject: Re: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled
>  REPE case
> 
> Here's a very short test program that produces this error for me.  I'm 
> using a Pentium 3, though, not a Pentium 4.  The problem only happens if I 
> use the -march=pentium3 option with gcc 3.x.
> 
> Test program:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main(int argc, char **argv)
> {
>    float f = rand() / (float)RAND_MAX;
>    printf("f=%f\n", f);
> 
>    return 0;
> }
> 
> Compilation line:
> 
>   gcc -march=pentium3 foo.c
> 
> > gcc -v
> Thread model: posix
> gcc version 3.2
> 
> > valgrind --version
> valgrind-1.9.4
> 
> I hope this helps!
> 
> - Dominic
> 
> ---------------------------------------------------------------
> 
> From: Julian Seward <js...@ac...>
> To: val...@li...
> Date: Sun, 27 Apr 2003 00:13:43 +0100
> Subject: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled 
> REPE
> case
> 
> 
> Hello.  I'm trying to put together bug fixes for 1.9.6.
> 
> Several people reported this panic:
> 
>    REPE then 0xF
> 
>    valgrind: the `impossible' happened:
>       Unhandled REPE case
> 
> I'd like to fix it, since it seems to afflict quite a number
> of people.  However, reading my Intel P4 documentation I can't
> figure out what instruction this is.
> 
> So: does anyone have a smallish test case I can use to reproduce
> this with?  Or (not so good, but it would be a help) can anyone
> tell me what the byte after the 0xF is?  You can find out
> by changing vg_to_ucode.c:4321 from
> 
>          VG_(printf)("REPE then 0x%x\n", (UInt)abyte);
> 
> to
> 
>          VG_(printf)("REPE then 0x%x 0x%x\n", (UInt)abyte,
>                                               (UInt)getUChar(eip));
> 
> I prefer a test case tho, so I can test any fix I make.
> 
> Thanks,
> 
> J
> 
> 
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> End of Valgrind-users Digest
> 

[Valgrind-users] [PATCH] JSIOCGNAME support

[Melchior F. <mf...@kd...>]

The JSIOCGNAME ioctl is currently not supported by valgrind. This function
returns human readable joystick names (like "SAITEK CYBORG 3D USB"). The ioctl
has two unconventional properties: it has a variable id (with the size of
the target buffer encoded in it), and it doesn't necessarily return zero
on success, but the number of actually written bytes. I suggest the following
patch.

m.



Index: coregrind/vg_syscalls.c
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_syscalls.c,v
retrieving revision 1.32
diff -u -p -r1.32 vg_syscalls.c
--- coregrind/vg_syscalls.c	2 May 2003 16:18:06 -0000	1.32
+++ coregrind/vg_syscalls.c	2 May 2003 16:24:03 -0000
@@ -2435,9 +2435,18 @@ void VG_(perform_assumed_nonblocking_sys
                }
                KERNEL_DO_SYSCALL(tid,res);
                if (size > 0 && (dir & _IOC_READ)
-                   && !VG_(is_kerror)(res) && res == 0
-                   && arg3 != (Addr)NULL)
-                  VG_TRACK( post_mem_write,arg3, size);
+                   && !VG_(is_kerror)(res)
+                   && arg3 != (Addr)NULL) {
+                  /* JSIOCGNAME() returns the number of actually
+                   * written bytes on success.
+                   */
+                  if ((arg2 & ~(_IOC_SIZEMASK << _IOC_SIZESHIFT))
+                      == JSIOCGNAME(0)) {
+                     if (res > 0)
+                        VG_TRACK( post_mem_write, arg3, res);
+                  } else if (res == 0)
+                     VG_TRACK( post_mem_write, arg3, size);
+               }
                break;
             }
          }
Index: coregrind/vg_unsafe.h
===================================================================
RCS file: /cvsroot/valgrind/valgrind/coregrind/vg_unsafe.h,v
retrieving revision 1.12
diff -u -p -r1.12 vg_unsafe.h
--- coregrind/vg_unsafe.h	15 Apr 2003 14:57:51 -0000	1.12
+++ coregrind/vg_unsafe.h	2 May 2003 16:24:04 -0000
@@ -60,8 +60,9 @@
 #include <sys/stat.h>     /* for struct stat */
 #undef __USE_LARGEFILE64
 
-#include <asm/ioctls.h>   /* for stuff for dealing with ioctl :( */
-#include <sys/soundcard.h> /* for various soundcard ioctl constants :( */
+#include <asm/ioctls.h>     /* for stuff for dealing with ioctl :( */
+#include <linux/joystick.h> /* for JSIOCGNAME joystick ioctl :( */
+#include <sys/soundcard.h>  /* for various soundcard ioctl constants :( */
 
 #ifndef GLIBC_2_1
 #  include <linux/rtc.h>   /* for RTC_* ioctls */

Re: [Valgrind-users] Patch for recvfrom()

[Nicholas N. <nj...@ca...>]

On 25 Mar 2003, Crispin Flowerday wrote:

> I noticed that with 1.9.4, calling recvfrom with a NULL 'from' argument
> returned an error by valgrind, the attached patch stops this error.

Committed to CVS HEAD, thanks.

N

Re: [Valgrind-users] NULL parameters in system calls

[Nicholas N. <nj...@ca...>]

On 30 Apr 2003, Tom Hughes wrote:

> > is it possible to patch the syscall wrappers so that they accept legal
> > NULL values in their parameters ? I tried to find out how to do that,
> > but I think I need some help to understant the many levels of
> > indirections in the wrapper invocation.
>
> This should do the trick:

Committed to CVS HEAD, thanks.

N

Re: [Valgrind-users] instruction trace

[Nicholas N. <nj...@ca...>]

On 1 May 2003, David Brumley wrote:

> >"Instructions issued" is almost meaningless for the hardware; certainly
> > no software could ever compute it.
>
> Thanks, that's good information but I'm not sure it completely answers
> my question.  What I want is the number of assembly instructions issued,

Um...

I think the hardware counters are the only way you're going to get
instructions issued (at least, in the sense that I understand the term).

Again, I think Rabbit can do the job if you have a Pentium II or III or
Athlon (not sure about P4s), and you don't need to recompile your program.
If you have a P4, I imagine Abyss/Brink could be used without recompiling
your program by creating a simple wrapper program like Rabbit's rabbit.c,
but I'm not certain.

N

Re: [Valgrind-users] suppressing still reachable errors

[Nicholas N. <nj...@ca...>]

On Fri, 2 May 2003, James Maynard wrote:

> I am trying to suppress, some of the, still reachable errors in our memory checking.
> I have used
> {
>     STL_Problem_One
>     Memcheck:Leak
>     fun:_STL::__node_alloc*
> }
>
> and nothing gets suppressed can anyone help

C++ names have to be _mangled_, is this one?  You can see the mangled
names in error messages using --demangle=no.  If you have a CVS HEAD
version, you can use --gen-suppressions=yes to automatically generate the
suppressions for you.

N

Re: [Valgrind-users] Can i get a warning to issue the stacktrace?

[Nicholas N. <nj...@ca...>]

On Fri, 2 May 2003, Bastien Chevreux wrote:

> On Thursday 01 May 2003 22:56, Nicholas Nethercote wrote:
> > Cool, thanks.  That was on my todo list, you've saved me some time :)
> > I will commit it some time soon.
> > (where "two days" < "soon" && "two weeks" < "soon")
>
> Shouldn't that be ... "two weeks" > "soon"? :-)

Unless I'm planning on never committing it, a ha ha...

You're right.  Lucky Tom wrote the patch instead of me :)

N

[Valgrind-users] Re: Valgrind RH RPM packages for RH62, RH72, RH80 and RH9

[Dag W. <da...@wi...>]

On Sun, 27 Apr 2003, Julian Seward wrote:

> > I also included a small C program that would check if NPTL threading =
was
> > supported (at runtime). But I superseded that with using getconf dire=
ctly.
> > (This works on all distributions and is much cleaner.)
> >
> > Using getconf was advised on a mailinglist somewhere (I can't remembe=
r
> > where exactly I read that.) However I have the source of the small C
> > program still in my SPEC file for educational purposes.)
> >
> > It would be nice though if valgrind could check for itself if NPTL
> > threading is supported at loadtime ? Or at least take over my changes=
 to
> > coregrind/valgrind.in so that it is check in runtime (instead of chec=
king
> > at compile-time)
>=20
> I'm trying to put together 1.9.6, which fixes some glibc-2.3.2+=20
> threading problems and so will be the first V which is properly usable
> for R H 9 and SuSE 8.2.
>=20
> It would be helpful therefore if you could send me the _minimal_ diffs
> against the VALGRIND_2_0_BRANCH in cvs at sourceforge (this is the 1.9.=
X
> stable branch) which allow you to build RPMs as you want.

> > perl -pi.orig -e 's|^nptl_threading=3D.*$|nptl_threading=3D"$(if getc=
onf
> > GNU_LIBPTHREAD_VERSION &>/dev/null; then echo "yes"; else echo "no"; =
fi)"|'
> > coregrind/valgrind.in

If you're going to adopt the change to the valgrind shellscript:

	Can't you just do this on a checkout and then commit ? Or just=20
	edit that one line by hand ? Doing a checkout seems so much work=20
	for so little change.

	You have to replace the nptl_threading=3D line with:

	nptl_threading=3D"$(if getconf GNU_LIBPTHREAD_VERSION &>/dev/null; then =
echo "yes"; else echo "no"; fi)"


If you're talking about the NPTL checking on loadtime:

	I am not a developer so I'm not sure where to commit the change.=20
	What's more it expects a define to be able to compile and I have=20
	no clue to make that compile on systems that don't have that=20
	getconf define (older glibcs).

	This is the code I used before I called getconf directly from the=20
	script. _CS_GNU_LIBPTHREAD_VERSION does not exist on older glibc !

		//#define _XOPEN_SOURCE
		#define _POSIX_C_SOURCE 2
		#include <unistd.h>
		#include <stdio.h>

		int main(void) {
			char *buf; size_t n;

			n=3Dconfstr(_CS_GNU_LIBPTHREAD_VERSION, NULL, (size_t) 0);
			if ((buf =3D (char *) malloc(n)) =3D=3D NULL) abort();
			confstr(_CS_GNU_LIBPTHREAD_VERSION, buf, n);
			fprintf(stdout, "%s\n", buf); exit(0);
		}


And if you're talking about the SPEC-file changes, I'm not sure what you=20
want to adopt from it and what not. You can find it at:

	http://dag.wieers.com/packages/valgrind/valgrind.spec


> > PS These packages still have a problem with some private GLIBC symbol=
s
> > that are in the dependencies of the package. I can't seem to fix this=
 by
> > doing:
> >
> > 	%define __find_provides() /usr/lib/rpm/find-provides %* | grep -v
> > '^libpthread.so' %define __find_requires() /usr/lib/rpm/find-requires=
 %* |
> > grep -v 'libc.so.6(GLIBC_PRIVATE)'
> >
> > So unless I find a clean way of doing this, you might have to install=
 with
> > --nodeps on some RH's (RH80 and RH73 afaik).

I still have to get this to work. Someone gave me a solution, but I didn'=
t=20
like it though, it should work from the spec-file directly IMO. Need to=20
check this on the rpm-list.

Kind regards,
--   dag wieers,  da...@wi...,  http://dag.wieers.com/   --
=ABAny errors in spelling, tact or fact are transmission errors=BB

Re: [Valgrind-users] Can i get a warning to issue the stacktrace?

[Bastien C. <ba...@ch...>]

On Thursday 01 May 2003 22:56, Nicholas Nethercote wrote:
> Cool, thanks.  That was on my todo list, you've saved me some time :)
> I will commit it some time soon.
> (where "two days" < "soon" && "two weeks" < "soon")

Shouldn't that be ... "two weeks" > "soon"? :-)

B.

-- 
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --