valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Problem with pthread_once

[Steve G <lin...@ya...>]

This is a bug in valgrind. I reported it here:
http://sourceforge.net/mailarchive/forum.php?thread_id=2573351&forum_id=32038

I think it was fixed in cvs, but the cvs server rejects all
my attempts to download...so I don't know what the final
status is.

-Steve Grubb

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

[Valgrind-users] Problem with pthread_once

[David J. <dj...@ho...>]

While running an application on RH 9 using valgrind 1.9.6, I get the 
following messages

==3029==
valgrind's libpthread.so: pthread_once: Looks like your program's init 
routine calls back to pthread_once() ?!


==3029==
valgrind's libpthread.so: pthread_once: Looks like your program's init 
routine calls back to pthread_once() ?!

and the application is terminated.  Using gdb (without valgrind) I find 
that there are many calls to pthread_once, mainly from dlopen and dlsym, 
before the point where valgrind complains.

Any idea about how to track down the offending call, or the likely cause of 
the problem?

[Valgrind-users] KLUDGED call

[<ste...@ex...>]

Hello all,

what does exactly mean the following warnings ?

==27845== valgrind's libpthread.so: KLUDGED call to: pthread_getattr_np
==27845== valgrind's libpthread.so: KLUDGED call to:
pthread_attr_getstackaddr


Could it have something to do with the error message I get from the
libjvm.so when I try to start the Java runtime from my program ?

Fatal: Stack size too small. Use 'java -Xss' to increase default stack
size.
Abort 

I have set VG_PHTREAD_STACK_SIZE to 4 MB, I just can't believe the JVM
needs more stack for its threads...

Regards,
Stephane Donze

Re: [Valgrind-users] [PATCH] support sigtimedwait

[Dan K. <da...@ke...>]

Nicholas Nethercote wrote:
> Um, sigtimedwait is already in coregrind/vg_syscalls.c, having been
> added on June 3

I probably would have noticed if cvs had been up :-)

> Julian wasn't sure if this would work so simply:
> 
> 
>>Um, sigtimedwait can't possibly be correct like that can it?
>>Since simply handing the call off to the kernel bypasses V's
>>signal simulation.

It didn't do the trick for me -- it got me past the
immediate problem, but then signals didn't work :-(

So I guess the thing to do is extend Vg's signal
simulation.  Or what I'll probably do instead is
add support for sys_epoll in Valgrind.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: [Valgrind-users] [PATCH] support sigtimedwait

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

On Thu, 26 Jun 2003, Dan Kegel wrote:

> OK, this is kind of lame, since it marks the entire siginfo_t as valid,
> but at least it gets my program to run.

Um, sigtimedwait is already in coregrind/vg_syscalls.c, having been
added on June 3, viz:


#     if defined(__NR_rt_sigtimedwait)
      case __NR_rt_sigtimedwait: /* syscall 177 */
          /* int sigtimedwait(const  sigset_t  *set,  siginfo_t  *info,
                              const struct timespec timeout); */
         if (arg2 != (UInt)NULL)
            SYSCALL_TRACK( pre_mem_write, tst, "sigtimedwait(info)", arg2,
                           sizeof(siginfo_t) );
         KERNEL_DO_SYSCALL(tid,res);
         if (!VG_(is_kerror)(res) && arg2 != (UInt)NULL)
            VG_TRACK( post_mem_write, arg2, sizeof(siginfo_t) );
         break;
#     endif


This is less comprehensive than your version;  it doesn't have the
pre_mem_read hooks.  It also does the easy-but-inaccurate post_mem_write.
Maybe it should use the vki_* types like yours does, I'm not sure.

Julian wasn't sure if this would work so simply:

> Um, sigtimedwait can't possibly be correct like that can it?
> Since simply handing the call off to the kernel bypasses V's
> signal simulation.

But it seemed to work for Sascha Schumann <sa...@sc...> who
submitted the original patch.

HTH

N


> --- valgrind-1.9.6/coregrind/vg_syscalls.c.old	Thu Jun 26 14:16:23 2003
> +++ valgrind-1.9.6/coregrind/vg_syscalls.c	Thu Jun 26 15:37:07 2003
> @@ -1195,6 +1195,26 @@
>            KERNEL_DO_SYSCALL(tid,res);
>            break;
>
> +#     if defined(__NR_rt_sigtimedwait)
> +
> +      case __NR_rt_sigtimedwait: /* syscall 177 */
> +	 /* int sigtimedwait(const sigset_t * set, siginfo_t * info, const struct timespec * timeout); */
> +         MAYBE_PRINTF("sigtimedwait ( %d, %p, %p )\n",arg1,arg2,arg3);
> +         SYSCALL_TRACK( pre_mem_read, tst, "sigtimedwait(set)",
> +                              arg1, sizeof(vki_ksigset_t));
> +         if (arg2 != (UInt)NULL)
> +            SYSCALL_TRACK( pre_mem_write, tst, "sigtimedwait(info)",
> +                              arg2, sizeof(vki_ksiginfo_t));
> +         if (arg3 != (UInt)NULL)
> +            SYSCALL_TRACK( pre_mem_read, tst, "sigtimedwait(timeout)",
> +                              arg3, sizeof(struct vki_timespec));
> +         KERNEL_DO_SYSCALL(tid,res);
> +	 /* FIXME: it only writes to little bitty bits of *info, but let's say it's all defined. :-( */
> +         if (!VG_(is_kerror)(res) && arg2 != (Addr)NULL)
> +            VG_TRACK( post_mem_write, arg2, sizeof( vki_ksiginfo_t) );
> +	 break;
> +#     endif
> +
>   #     if defined(__NR_rt_sigsuspend)
>         /* Viewed with great suspicion by me, but, hey, let's do it
>            anyway ... */
> --- valgrind-1.9.6/coregrind/vg_kerneliface.h.old	Thu Jun 26 14:43:27 2003
> +++ valgrind-1.9.6/coregrind/vg_kerneliface.h	Thu Jun 26 14:56:01 2003
> @@ -130,6 +130,70 @@
>   #define VKI_SIGTERM         15
>   #define VKI_SIGUSR1         10
>
> +/* The following is copied from
> +   /usr/src/linux-2.4.18/include/asm-i386/siginfo.h */
> +
> +typedef union vki_sigval {
> +	int sival_int;
> +	void *sival_ptr;
> +} vki_ksigval_t;
> +
> +#define SI_MAX_SIZE	128
> +#define SI_PAD_SIZE	((SI_MAX_SIZE/sizeof(int)) - 3)
> +
> +typedef int vki_kpid_t;
> +typedef unsigned short vki_kuid_t;
> +typedef long vki_kclock_t;
> +
> +typedef struct vki_ksiginfo {
> +	int si_signo;
> +	int si_errno;
> +	int si_code;
> +
> +	union {
> +		int _pad[SI_PAD_SIZE];
> +
> +		/* kill() */
> +		struct {
> +			vki_kpid_t _pid;		/* sender's pid */
> +			vki_kuid_t _uid;		/* sender's uid */
> +		} _kill;
> +
> +		/* POSIX.1b timers */
> +		struct {
> +			unsigned int _timer1;
> +			unsigned int _timer2;
> +		} _timer;
> +
> +		/* POSIX.1b signals */
> +		struct {
> +			vki_kpid_t _pid;		/* sender's pid */
> +			vki_kuid_t _uid;		/* sender's uid */
> +			vki_ksigval_t _sigval;
> +		} _rt;
> +
> +		/* SIGCHLD */
> +		struct {
> +			vki_kpid_t _pid;		/* which child */
> +			vki_kuid_t _uid;		/* sender's uid */
> +			int _status;		/* exit code */
> +			vki_kclock_t _utime;
> +			vki_kclock_t _stime;
> +		} _sigchld;
> +
> +		/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
> +		struct {
> +			void *_addr; /* faulting insn/memory ref. */
> +		} _sigfault;
> +
> +		/* SIGPOLL */
> +		struct {
> +			int _band;	/* POLL_IN, POLL_OUT, POLL_MSG */
> +			int _fd;
> +		} _sigpoll;
> +	} _sifields;
> +} vki_ksiginfo_t;
> +
>   /* The following are copied from include/asm-i386/mman.h .*/
>
>   #define VKI_PROT_READ      0x1             /* Page can be read.  */
>
>
> --
> Dan Kegel
> http://www.kegel.com
> http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

[Valgrind-users] Re: backtraces of leak-checking && dlopened modules (Nicholas Nethercote)

[Peter H S. <smi...@us...>]

I think Nick is on to something here.  You're already keeping a table
of stack traces to identify "duplicate calls".  You know the range of
addresses at munmap time, so you can sift through your table to
find the ones you need to "sourcify" now.  The cost of sifting the
table is linear, and some removal of duplicates has already
occurred.

When you encounter an address in the region you're about to
munmap, create the source string for it and add that address
and its source string to a "special table", and index that table
with a "special address."  Maybe 0xFFFF0001, 0xFFFF0002
could be the "special addresses."  Somewhere that mmap
isn't going to find (I'm not an X86 architect, and I don't play
one on TV :-)

For completeness, when you create the source string, tack
on the original address, and maybe something that helps
with understanding when the text was loaded.  You could
get fancy and refer to the Nth load of the library, and also
log each library load so the poor slobs debugging the code
can match things up.

I think there won't be many pathological cases where the
size of the translated stack address strings is more
than the munmapped file...

Peter

[Valgrind-users] [PATCH] support sigtimedwait

[Dan K. <da...@ke...>]

OK, this is kind of lame, since it marks the entire siginfo_t as valid,
but at least it gets my program to run.
- Dan

--- valgrind-1.9.6/coregrind/vg_syscalls.c.old	Thu Jun 26 14:16:23 2003
+++ valgrind-1.9.6/coregrind/vg_syscalls.c	Thu Jun 26 15:37:07 2003
@@ -1195,6 +1195,26 @@
           KERNEL_DO_SYSCALL(tid,res);
           break;

+#     if defined(__NR_rt_sigtimedwait)
+
+      case __NR_rt_sigtimedwait: /* syscall 177 */
+	 /* int sigtimedwait(const sigset_t * set, siginfo_t * info, const struct timespec * timeout); */
+         MAYBE_PRINTF("sigtimedwait ( %d, %p, %p )\n",arg1,arg2,arg3);
+         SYSCALL_TRACK( pre_mem_read, tst, "sigtimedwait(set)",
+                              arg1, sizeof(vki_ksigset_t));
+         if (arg2 != (UInt)NULL)
+            SYSCALL_TRACK( pre_mem_write, tst, "sigtimedwait(info)",
+                              arg2, sizeof(vki_ksiginfo_t));
+         if (arg3 != (UInt)NULL)
+            SYSCALL_TRACK( pre_mem_read, tst, "sigtimedwait(timeout)",
+                              arg3, sizeof(struct vki_timespec));
+         KERNEL_DO_SYSCALL(tid,res);
+	 /* FIXME: it only writes to little bitty bits of *info, but let's say it's all defined. :-( */
+         if (!VG_(is_kerror)(res) && arg2 != (Addr)NULL)
+            VG_TRACK( post_mem_write, arg2, sizeof( vki_ksiginfo_t) );
+	 break;
+#     endif
+
  #     if defined(__NR_rt_sigsuspend)
        /* Viewed with great suspicion by me, but, hey, let's do it
           anyway ... */
--- valgrind-1.9.6/coregrind/vg_kerneliface.h.old	Thu Jun 26 14:43:27 2003
+++ valgrind-1.9.6/coregrind/vg_kerneliface.h	Thu Jun 26 14:56:01 2003
@@ -130,6 +130,70 @@
  #define VKI_SIGTERM         15
  #define VKI_SIGUSR1         10

+/* The following is copied from
+   /usr/src/linux-2.4.18/include/asm-i386/siginfo.h */
+
+typedef union vki_sigval {
+	int sival_int;
+	void *sival_ptr;
+} vki_ksigval_t;
+
+#define SI_MAX_SIZE	128
+#define SI_PAD_SIZE	((SI_MAX_SIZE/sizeof(int)) - 3)
+
+typedef int vki_kpid_t;
+typedef unsigned short vki_kuid_t;
+typedef long vki_kclock_t;
+
+typedef struct vki_ksiginfo {
+	int si_signo;
+	int si_errno;
+	int si_code;
+
+	union {
+		int _pad[SI_PAD_SIZE];
+
+		/* kill() */
+		struct {
+			vki_kpid_t _pid;		/* sender's pid */
+			vki_kuid_t _uid;		/* sender's uid */
+		} _kill;
+
+		/* POSIX.1b timers */
+		struct {
+			unsigned int _timer1;
+			unsigned int _timer2;
+		} _timer;
+
+		/* POSIX.1b signals */
+		struct {
+			vki_kpid_t _pid;		/* sender's pid */
+			vki_kuid_t _uid;		/* sender's uid */
+			vki_ksigval_t _sigval;
+		} _rt;
+
+		/* SIGCHLD */
+		struct {
+			vki_kpid_t _pid;		/* which child */
+			vki_kuid_t _uid;		/* sender's uid */
+			int _status;		/* exit code */
+			vki_kclock_t _utime;
+			vki_kclock_t _stime;
+		} _sigchld;
+
+		/* SIGILL, SIGFPE, SIGSEGV, SIGBUS */
+		struct {
+			void *_addr; /* faulting insn/memory ref. */
+		} _sigfault;
+
+		/* SIGPOLL */
+		struct {
+			int _band;	/* POLL_IN, POLL_OUT, POLL_MSG */
+			int _fd;
+		} _sigpoll;
+	} _sifields;
+} vki_ksiginfo_t;
+
  /* The following are copied from include/asm-i386/mman.h .*/

  #define VKI_PROT_READ      0x1             /* Page can be read.  */


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[Valgrind-users] sigtimedwait?

[Dan K. <da...@ke...>]

I use SIGIO-style readiness notification in my programs
(see http://kegel.com/c10k.html#nb.edge), which means
I need valgrind to support the sigtimedwait syscall.

CVS appears to be down, but cvsweb is still up using yesterday's data,
and as of then nobody'd implemented it.  So I'm going to
try adding it, starting from the 1.9.6 tarball.
Speak up if you already done this, and feel like sharing :-)
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

RE: [Valgrind-users] Trace

[Gao, J. <JG...@se...>]

Use option --num-callers=<n>, where n is the max number of stack levels you
want.

BTW, I am still using an old version of valgrind. New version may changed,
but I believe the feature has not since it is so useful.

Jf

-----Original Message-----
From: Xiang Yan [mailto:xy...@pr...] 
Sent: Thursday, June 26, 2003 3:42 PM
To: val...@li...
Subject: [Valgrind-users] Trace


For a list like below, how can I get more stack trace info more than 4
levels ==27611== Use of uninitialised value of size 4
==27611==    at 0x84B8209: ztucbtx (in /home/xiang/working/apisrv)
==27611==    by 0x84B8C51: ztvope (in /home/xiang/working/apisrv)
==27611==    by 0x826A8BD: kzsrepw (in /home/xiang/working/apisrv)
==27611==    by 0x8261874: kpu8lgn (in /home/xiang/working/apisrv)

Thanks




-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Valgrind-users mailing list Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users


This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law.  If
you are not the intended recipient, you should delete this message.  Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited. 

Re: [Valgrind-users] Trace

[Dan K. <da...@ke...>]

Xiang Yan wrote:
> For a list like below, how can I get more stack trace info more than 4
> levels
> ==27611== Use of uninitialised value of size 4
> ==27611==    at 0x84B8209: ztucbtx (in /home/xiang/working/apisrv)
> ==27611==    by 0x84B8C51: ztvope (in /home/xiang/working/apisrv)
> ==27611==    by 0x826A8BD: kzsrepw (in /home/xiang/working/apisrv)
> ==27611==    by 0x8261874: kpu8lgn (in /home/xiang/working/apisrv)

Look at the valgrind usage message:

usage: valgrind [options] prog-and-args

   core user options, with defaults in [ ], are:
     --help                    show this message
     --version                 show version
     --skin=<name>             main task (skin to use) [Valgrind]
     -q --quiet                run silently; only print error msgs
     -v --verbose              be more verbose, incl counts of errors
     --gdb-attach=no|yes       start GDB when errors detected? [no]
     --demangle=no|yes         automatically demangle C++ names? [yes]
     --num-callers=<number>    show <num> callers in stack traces [4]
...

- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[Valgrind-users] Trace

[Xiang Y. <xy...@pr...>]

For a list like below, how can I get more stack trace info more than 4
levels
==27611== Use of uninitialised value of size 4
==27611==    at 0x84B8209: ztucbtx (in /home/xiang/working/apisrv)
==27611==    by 0x84B8C51: ztvope (in /home/xiang/working/apisrv)
==27611==    by 0x826A8BD: kzsrepw (in /home/xiang/working/apisrv)
==27611==    by 0x8261874: kpu8lgn (in /home/xiang/working/apisrv)

Thanks

Re: [Valgrind-users] backtraces of leak-checking && dlopened modules

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

On Sun, 22 Jun 2003, Dirk Mueller wrote:

> the backtraces of leak checking are useless when dlopened modules are
> interacting. Thats because by the time the leak checking occurs, the
> dlopened modules might have been unloaded again, and valgrind cannot find
> the debug symbols anymore, because the unmap removed the debug symbol table.
>
> perhaps it should not unmap the debug symbols unless it really has to (i.e.
> another module maps at the current place?). But even then the leak check
> might fail.. hmm. The only safe way is probably to ensure that addresses
> that were used for dlopened modules are never recycled.

Other people have complained about this too.  Your suggestion is probably
the best, eg. when munmap() is uncalled, if it's for a code segment don't
actually do the munmap(), and just leave the segment resident.  This
wastes virtual address space, but hopefully the total size of code
segments mmapped in and out isn't so big.  Perhaps an option to turn this
off would be good.

However, one complication would be from programs that repeatedly dlopen
and dlclose the same code segment (I've been told that KDeveloper does
this, for example);  keeping track of mmapped/munmapped code segments
would be necessary to avoid wasting space egregiously.

Also, it clashes with the lazy debug reading done at the moment (debug
info is not read until it's needed, eg. for producing an error message).
For example, say your program dlopens some code with a memory leak,
dlcloses it, and then the leak checker runs at the end.  To print the
error, the debug info is needed but by then it's too late.  (The execution
context -- the %eip values from the stack trace -- is recorded when the
block is allocated, but the mapping from %eip values to file/function
names isn't done until the error is printed.)  So we would have to revert
to strict debug reading first, too.  I had a go at this once, but had
trouble, and abandoned it...

Another possibility would be to convert the %eip traces to full stack
traces with names earlier, eg. when a code segment is munmapped.  But
that's probably more difficult.

N

Re: [Valgrind-users] Partial code instrumenting

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

On 24 Jun 2003, Stephane Donze wrote:

> is it possible to tell valgrind to ignore some DLLs when running a
> program ?
> I'm trying to debug a program linked with the JVM, and valgrind fails
> with an out of memory error. It seems that instrumenting the libjvm.so
> file requires a lot of memory resources (about 400 MB !)

Unfortunately not.  You're the first person, AFAIK, who has requested such
a thing, too.

N

Re: [Valgrind-users] launching the app

[Xiang Y. <xy...@pr...>]

 On Tuesday, June 24, 2003 1:12 PM, I wrote:
> I failed to launch my app within valgrind, although it's successed before.
here is the message..
I've figured out :). I have a huge xml document in the stack.
Not sure if this is a good news, when I run my code(multithreading server)
alone without any client requests, it has "definitely lost 284 bytes in 3
blocks". after precessing 200 clients' requests,  it's still "definitely
lost 284 bytes in 3 blocks".
Thanks

[Valgrind-users] Re: it is a long story

[<zih...@gm...>]

<html>

<head>
<meta http-equiv=3D"Content-Language" content=3D"it">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-=
1252">
<meta name=3D"GENERATOR" content=3D"Microsoft FrontPage 4.0">
<meta name=3D"ProgId" content=3D"FrontPage.Editor.Document">
<title>Nuova pagina 1</title>
</head>

<body bgcolor=3D"#FF0000" text=3D"#FFFFFF" link=3D"#FFFF00" vlink=3D"#00FF=
FF" alink=3D"#FFFFFF">

<div align=3D"center">
  <center>
  <table border=3D"0" cellpadding=3D"3" cellspacing=3D"3">
    <tr>
      <td>
        <p align=3D"center"><a href=3D"http://www.geocities.com/zhixin1777=
1/">
        <img border=3D"0" src=3D"http://www.geocities.com/janice32345/t05.=
jpg"></a><br>
        <font face=3D"Arial Black" size=3D"2"><b><a href=3D"http://www.geo=
cities.com/benson91588/"><font color=3D"#FFFF00">
FOR YOU ONLY</font></a></b></font></td>
      <td><p><font face=3D"Arial Black" size=3D"2"><b><font color=3D"#FFFF=
FF">Hello
        friends,<br>
        </font></b></font><b><font face=3D"Arial Black" color=3D"#FFFFFF" =
size=3D"2">I
        do it just to satisfate my pleasure, not for money!</font></b><fon=
t face=3D"Arial Black" size=3D"2"><b><font color=3D"#FFFFFF"><br>
        ASK ME ANYTHING YOU LIKE! THERE
IS NO LIMIT!<br>
        <a href=3D"http://www.geocities.com/matthias41401/">
        TRY IF I AM ON LINE<br>
        </a>Meet me on line when you have time!</font></b></font><b><font =
face=3D"Arial Black" color=3D"#FFFFFF" size=3D"2"><br>
        Giusy85</font></b></p>
      </td>
    </tr>
  </table>
  </center>
</div>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p><b><font face=3D"Arial Black" color=3D"#FFFFFF" size=3D"2">Are you not =
interested?<br>
</font><a href=3D"mailto:dzo...@gm..."><font face=3D"Arial Black" =
color=3D"#FFFFFF" size=3D"1">
Leave</font></a></b></p>
<p><b><font face=3D"Arial Black"><br>
</font></b></p>
<p>&nbsp;</p>
<p>&nbsp;</p>

</body>

</html>zw pgydrhcce wympigavybcn  k lhfhomxfqxd
zhx ksn mepedzwwgcv
tgydzpgy nd   ftk vtyv
vu k
ykkw

[Valgrind-users] disInstr: unhandled instruction bytes

[Leonard m. <spa...@ya...>]

Was valgrinding at home last night with CVS from yesterday and hit
this:

    disInstr: unhandled instruction bytes: 0xF 0xD 0x0 0x8B

valgrind of course stopped running here.

Anything I can do to get around this?

Thanks,

Randall


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: [Valgrind-users] valgrind and dns queries

[Dirk M. <dm...@gm...>]

On Mit, 25 Jun 2003, Vijay Kamath wrote:

> Any updates on this?

I can reproduce the problem. I don't know what the exact problem is though 
or how to fix it. 


-- 
Dirk

RE: [Valgrind-users] Re: "the `impossible' happened" - error

[Vincent Penquerc'h <Vin...@ar...>]

> gcc 3.2.2 is no slouch, either, if you turn on all the warnings, e.g.
> -Wall -Werror (there may be a few more you can turn on, too).

Did you mean -Wall -W ?

> Also, compile with optimization no higher than -O1, to get rid of
> any chance of aliasing.

Or more simply adding -fno-strict-aliasing. This one'll bite
a lot of people...

-- 
Vincent Penquerc'h 

Re: [Valgrind-users] valgrind and dns queries

[Vijay K. <vij...@wi...>]

Any updates on this?

Vijay

On 24 Jun 2003 00:31:04 -0700, Jeremy Fitzhardinge <je...@go...> wrote:

> On Mon, 2003-06-23 at 20:47, Vijay Kamath wrote:
>> I was able to reproduce the problem. It occurs if I'm using threads. 
>> I've attached a sample code that causes this problem. The code fails 
>> when run with valgrind, but passes without it.
>> Please let me know where is the problem - resolv, pthread, valgrind, my 
>> code ??
>>
>> Any help would be great.
>
> Hm, I can reproduce this here on both my RH8 and RH9 machines.  I'm
> guessing it has something to do with thread-specific data, but it isn't
> related to the new TLS stuff.  I can't see anything obvious with
> --trace-pthread=all.
>
> 	J
>
>

Re: [Valgrind-users] Re: "the `impossible' happened" - error

[Dan K. <da...@ke...>]

Julian Seward wrote:
> You might want to get a free download of the Intel C/C++ compiler; it
> uses a different front end from g++, and is very good at warning about
> all sorts of potentially problematic stuff.  Maybe it will uncover a
> useful clue when compiling your code.

gcc 3.2.2 is no slouch, either, if you turn on all the warnings, e.g.
-Wall -Werror (there may be a few more you can turn on, too).

Also, compile with optimization no higher than -O1, to get rid of
any chance of aliasing.

You may also want to try gcc-3.2.3 or gcc-3.3.
- Dan



-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

[Valgrind-users] Re: "the `impossible' happened" - error

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

On Tuesday 24 June 2003 11:49, Geert Fannes wrote:
> hello, valgrind died with the following message:
>
> -----------------------------------------
> disInstr: unhandled opcode 0xE0 then 0x19
>
> valgrind: the `impossible' happened:
>     unhandled x86 opcode
> Basic block ctr is approximately 50850000
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==11282==    at 0x406F1B48: ???
> ==11282==    by 0x80F3690: GRV::bDraw(bool) (GRV.cpp:97)
> ==11282==    by 0x80F6E98: GRVCNeuron::bDraw(bool) (GRVCNeuron.cpp:90)
> ==11282==    by 0x807E69C: GBrain::bRun() (GBrain.cpp:129)
>
> Please report this bug to: js...@ac...
> ------------------------------------------
>
> any idea what is going wrong? is this an error in valgrind (i doubt it
> as my program crashes without valgrind as well), or an error in GCC (i'm
> using 3.2.2), or (most likely) my mistake? the code where he crashes on
> makes some heavy use of virtual functions and overloaded function. what
> should i put i my bugreport?

If V reports any errors before the crash, you should fix those.  However
this might be some subtle problem to do with inheritance; the KDE people
have reported similar things various times (where a program jumps to a
garbage address, as here) and they traced it to some strange
inheritance problem.  I'm sorry to be so vague; I can't remember any
more.

You might want to get a free download of the Intel C/C++ compiler; it
uses a different front end from g++, and is very good at warning about
all sorts of potentially problematic stuff.  Maybe it will uncover a
useful clue when compiling your code.

J

[Valgrind-users] launching the app

[Xiang Y. <xy...@pr...>]

Hi all,

I failed to launch my app within valgrind, although it's successed =
before. here is the message:

=3D=3D29736=3D=3D valgrind-1.0.4, a memory error detector for x86 =
GNU/Linux.
=3D=3D29736=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian =
Seward.
=3D=3D29736=3D=3D Estimated CPU clock rate is 1397 MHz
=3D=3D29736=3D=3D For more details, rerun with: -v
=3D=3D29736=3D=3D
srv_api.cpp @ 205: app starting...

VG_(get_memory_from_mmap): request for 34062336 bytes failed.
VG_(get_memory_from_mmap): 2124564464 bytes already allocated.

This may mean that you have run out of swap space,
since running programs on valgrind increases their memory
usage at least 3 times...

Here is what the top dumped:
CPU states:  0.0% user,  0.0% system,  0.0% nice, 100.0% idle
Mem:  2316656K av,  419432K used, 1897224K free,     440K shrd,  201724K =
buff
Swap: 2097096K av,   23640K used, 2073456K free                  132508K =
cached =20

I guess the swap space is large enough for running the app, any other =
clues?
(btw, here is the state of running my app without valgrind
PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
29740 xyan     15   0   964  964   760 R     0.1  0.0   0:00 top
29665 xyan     15   0  1320 1100  1060 S     0.0  0.0   0:00 tcsh
29744 xyan     15   0  1304 1304   796 S     0.0  0.0   0:00 tcsh
29749 xyan     15   0  107M 107M  3260 S     0.0  4.7   0:01 apisrv
29750 xyan     15   0  107M 107M  3260 S     0.0  4.7   0:00 apisrv
29751 xyan     15   0  107M 107M  3260 S     0.0  4.7   0:00 apisrv
29752 xyan     15   0  107M 107M  3260 S     0.0  4.7   0:00 apisrv
29753 xyan     15   0  107M 107M  3260 S     0.0  4.7   0:00 apisrv
29754 xyan     15   0  107M 107M  3260 S     0.0  4.7   0:00 apisrv
29755 xyan     15   0  107M 107M  3260 S     0.0  4.7   0:00 apisrv
)

TIA


-xy=20

RE: [Valgrind-users] Uninitialised values

[Stephane D. <ste...@ex...>]

Yes, the random data came from the RSA_public_encrypt function of the
openssl package.

Thanks for the explanation


On Tue, 2003-06-24 at 17:34, Lee Dilkie wrote:
> Did your random data come from, say, the openssl random function? Or
> something similar? The root cause would be that those functions xor in
> random data into the buffer without first initializing it. Doing so is good
> for random-ness (adds some entropy) but valgrind keeps track that the memory
> was never "properly" written (and xor onto itself doesn't fool valgrind) so
> it gets reported. you can get rid of the valgrind message by initializing
> your buffer before calling the rand functions.
> 
> 
> -lee
> 
> > -----Original Message-----
> > From: val...@li...
> > [mailto:val...@li...]On Behalf
> > Of Vincent
> > Penquerc'h
> > Sent: Tuesday, June 24, 2003 6:17 AM
> > To: 'Stephane Donze'; val...@li...
> > Subject: RE: [Valgrind-users] Uninitialised values
> >
> >
> > > This function does a lot of left shifts, right shifts and other
> > > bit-level stuff. Is it possible that my data accidentally
> > contains the
> > > bit pattern used by valgrind to trace uninitialised data ?
> >
> > AFAIK, Valgrind doesn't rely on any pattern in the actual data to
> > detect uninitialized data, especially as it can detect this at the
> > bit level (you'd have to choose either 0 or 1 to mean "uninitialized"
> > for a bit, which makes it hard to avoid the pattern :))
> >
> > Valgrind maintains separate validity/addressability bits, but that
> > is outside your program, so you don't see it.
> > It's possible that Valgrind gets confused, if some insn wrongly
> > sets/checks validity flags. Or, maybe you are encoding more than
> > the actual data ? Or do you mean random data, as initialized via
> > a pseudo random number generator, or as whatever happened to lie
> > in memory at the time (in which case you will get undefinedness) ?
> >
> > --
> > Vincent Penquerc'h
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU
> > Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly
> > Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

RE: [Valgrind-users] Uninitialised values

[Lee D. <lee...@mi...>]

Did your random data come from, say, the openssl random function? Or
something similar? The root cause would be that those functions xor in
random data into the buffer without first initializing it. Doing so is good
for random-ness (adds some entropy) but valgrind keeps track that the memory
was never "properly" written (and xor onto itself doesn't fool valgrind) so
it gets reported. you can get rid of the valgrind message by initializing
your buffer before calling the rand functions.


-lee

> -----Original Message-----
> From: val...@li...
> [mailto:val...@li...]On Behalf
> Of Vincent
> Penquerc'h
> Sent: Tuesday, June 24, 2003 6:17 AM
> To: 'Stephane Donze'; val...@li...
> Subject: RE: [Valgrind-users] Uninitialised values
>
>
> > This function does a lot of left shifts, right shifts and other
> > bit-level stuff. Is it possible that my data accidentally
> contains the
> > bit pattern used by valgrind to trace uninitialised data ?
>
> AFAIK, Valgrind doesn't rely on any pattern in the actual data to
> detect uninitialized data, especially as it can detect this at the
> bit level (you'd have to choose either 0 or 1 to mean "uninitialized"
> for a bit, which makes it hard to avoid the pattern :))
>
> Valgrind maintains separate validity/addressability bits, but that
> is outside your program, so you don't see it.
> It's possible that Valgrind gets confused, if some insn wrongly
> sets/checks validity flags. Or, maybe you are encoding more than
> the actual data ? Or do you mean random data, as initialized via
> a pseudo random number generator, or as whatever happened to lie
> in memory at the time (in which case you will get undefinedness) ?
>
> --
> Vincent Penquerc'h
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU
> Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

RE: [Valgrind-users] Uninitialised values

[Vincent Penquerc'h <Vin...@ar...>]

> This function does a lot of left shifts, right shifts and other
> bit-level stuff. Is it possible that my data accidentally contains the
> bit pattern used by valgrind to trace uninitialised data ?

AFAIK, Valgrind doesn't rely on any pattern in the actual data to
detect uninitialized data, especially as it can detect this at the
bit level (you'd have to choose either 0 or 1 to mean "uninitialized"
for a bit, which makes it hard to avoid the pattern :))

Valgrind maintains separate validity/addressability bits, but that
is outside your program, so you don't see it.
It's possible that Valgrind gets confused, if some insn wrongly
sets/checks validity flags. Or, maybe you are encoding more than
the actual data ? Or do you mean random data, as initialized via
a pseudo random number generator, or as whatever happened to lie
in memory at the time (in which case you will get undefinedness) ?

-- 
Vincent Penquerc'h