valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Swap Space Problem

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

Mitchell Kang wrote:
[snip]
> VG_(get_memory_from_mmap): request for 8192 bytes failed.
> VG_(get_memory_from_mmap): 2119042790 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.
[snip]

Insure++ ( http://www.parasoft.com/jsp/products/home.jsp?product=Insure )
for Linux/x86 has a "no preparation required" checking mode which for large
processes has a memory overhead factor close to 1/4 [total usage while
monitoring is a factor of about (1 + 1/4) times the non-monitored usage].
This may be small enough to succeed in checking your process even on x86.
A license for Insure++ does cost money, but the indicated domain of the
original posting assures me that such a cost cannot be a significant burden.

Regards,

Re: [Valgrind-users] Swap Space Problem

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

Mitchell Kang wrote:
> The setting is Redhat AS 2.1 server with 4 CPUs, 8 GB of RAM and 8 GB of swap.
[snip]
> When I ran the following command after changing the stack_size to 28 because of the same problem
> 
>  #define VG_PTHREAD_STACK_SIZE (1 << 28)
> 
> valgrind --alignment=8 --skin=addrcheck --error-limit=no --leak-check=yes --num-callers=1 binary
> 
[snip]
> ==23496== Warning: set address range perms: large range 268435424, a 1
>  
> VG_(get_memory_from_mmap): request for 8192 bytes failed.
> VG_(get_memory_from_mmap): 2119042790 bytes already allocated.
[snip]
> I believe I have enough swap space.  Is there anything I can try?


It's possible that your address space is fragmented by having TASK_UNMAPPED_BASE
at 0x40000000, and a pre-linked glibc at 0x42000000.  TASK_UNNMAPPED_BASE is the
default address where dynamic loading takes place, as well as the beginning
address to search for space to satisfy any mmap(0, ...) system call that does
not specify MAP_FIXED.  While the process is running, do "cat /proc/<pid>/maps"
to see the layout of its address space.

Search google groups for Message-ID: <bc5igc$fu9$1...@rz...>
(Re: 64-bit memory management) by Ulrich Weigand, 6/10/2003 02:27PM to see a
claim that RHAS has a patch that lets you set the map_base by writing an ASCII
hex numeral to /proc/<pid>/map_base.  The referenced patch is
http://kernelnewbies.org/kernels/rh21as/SOURCES/linux-2.4.9-task-map-base.patch
With some investigating on your part ("ldd ./my_app"), then you can pick a good
place for map_base.

Your next problem may be a pre-linked libc.so.6 at 0x42000000.
The runtime loader asks the kernel for mmap(0x42000000, ...) and most likely
the kernel grants that address, which means fragmentation.  Try to find a non-
prelinked glibc of the appropriate version.  If you are willing to try some
tricks, then see  http://www.bitwagon.com/tub.html  for experimental code which
lets you move even a pre-linked glibc.  This doesn't give you any more total
space; however it may reduce the fragmentation by enough to squeak by.  Else
you will have to use Insure++ or Purify on a 64-bit RISC machine, or help get
valgrind on an AMD x86_64.

Regards,

Re: [Valgrind-users] Swap Space Problem

[Mitchell K. <Mit...@mo...>]

I don't want to.  But when I used the default, 1<<20 for 1 MB, I got the same
error except the warning for large range is 134217696, followed by request for
134217712 bytes failed, 1992652422 bytes already allocated.  Any suggestions?
Thanks.

Mitch

Julian Seward wrote:

> On Monday 16 June 2003 21:37, Mitchell Kang wrote:
> > The setting is Redhat AS 2.1 server with 4 CPUs, 8 GB of RAM and 8 GB of
> > swap.
> >
> > The application is compiled with gcc 2.96-112.
> >
> > When I ran the following command after changing the stack_size to 28
> > because of the same problem
> >
> >  #define VG_PTHREAD_STACK_SIZE (1 << 28)
>
> Are you sure this is a good idea?  It means each thread stack occupies
> 256MB, and no sane piece of code is going to require that much.  It would
> be far too fragile and unportable.  This is probably why you've run
> out of 2GB of address space, by the look of it.
>
> J
>
> > valgrind --alignment=8 --skin=addrcheck --error-limit=no --leak-check=yes
> > --num-callers=1 binary
> >
> > ==23496== Warning: set address range perms: large range 268435424, a 1
> > ==23496== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
> > ==23496== valgrind's libpthread.so: IGNORED call to:
> > pthread_attr_setinheritsched ==23496== Warning: set address range perms:
> > large range 268435424, a 1 ==23496== Warning: set address range perms:
> > large range 268435424, a 1 ==23496== Warning: set address range perms:
> > large range 268435424, a 1 ==23496== Warning: set address range perms:
> > large range 268435424, a 1 ==23496== Warning: set address range perms:
> > large range 268435424, a 1
> >
> > VG_(get_memory_from_mmap): request for 8192 bytes failed.
> > VG_(get_memory_from_mmap): 2119042790 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.  You might want to use 'top'
> > to determine whether you really have run out of swap.
> > If so, you may be able to work around it by adding a
> > temporary swap file -- this is easier than finding a
> > new swap partition.  Go ask your sysadmin(s) [politely!]
> >
> > VG_(get_memory_from_mmap): out of memory!  Fatal!  Bye!
> >
> > I believe I have enough swap space.  Is there anything I can try?
> >
> > Thanks for your help.
> >
> > Mitch
> >
> > --
> > NOTICE: If received in error, please destroy and notify sender.  Sender
> > does not waive confidentiality or privilege, and use is prohibited.

--
NOTICE: If received in error, please destroy and notify sender.  Sender does
not waive confidentiality or privilege, and use is prohibited.

Re: [Valgrind-users] Swap Space Problem

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

On Monday 16 June 2003 21:37, Mitchell Kang wrote:
> The setting is Redhat AS 2.1 server with 4 CPUs, 8 GB of RAM and 8 GB of
> swap.
>
> The application is compiled with gcc 2.96-112.
>
> When I ran the following command after changing the stack_size to 28
> because of the same problem
>
>  #define VG_PTHREAD_STACK_SIZE (1 << 28)

Are you sure this is a good idea?  It means each thread stack occupies
256MB, and no sane piece of code is going to require that much.  It would
be far too fragile and unportable.  This is probably why you've run
out of 2GB of address space, by the look of it.

J


> valgrind --alignment=8 --skin=addrcheck --error-limit=no --leak-check=yes
> --num-callers=1 binary
>
> ==23496== Warning: set address range perms: large range 268435424, a 1
> ==23496== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
> ==23496== valgrind's libpthread.so: IGNORED call to:
> pthread_attr_setinheritsched ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==23496== Warning: set address range perms:
> large range 268435424, a 1
>
> VG_(get_memory_from_mmap): request for 8192 bytes failed.
> VG_(get_memory_from_mmap): 2119042790 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.  You might want to use 'top'
> to determine whether you really have run out of swap.
> If so, you may be able to work around it by adding a
> temporary swap file -- this is easier than finding a
> new swap partition.  Go ask your sysadmin(s) [politely!]
>
> VG_(get_memory_from_mmap): out of memory!  Fatal!  Bye!
>
> I believe I have enough swap space.  Is there anything I can try?
>
> Thanks for your help.
>
> Mitch
>
> --
> NOTICE: If received in error, please destroy and notify sender.  Sender
> does not waive confidentiality or privilege, and use is prohibited.

[Valgrind-users] Swap Space Problem

[Mitchell K. <Mit...@mo...>]

The setting is Redhat AS 2.1 server with 4 CPUs, 8 GB of RAM and 8 GB of swap.

The application is compiled with gcc 2.96-112.

When I ran the following command after changing the stack_size to 28 because of the same problem

 #define VG_PTHREAD_STACK_SIZE (1 << 28)

valgrind --alignment=8 --skin=addrcheck --error-limit=no --leak-check=yes --num-callers=1 binary

==23496== Warning: set address range perms: large range 268435424, a 1
==23496== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
==23496== valgrind's libpthread.so: IGNORED call to: pthread_attr_setinheritsched
==23496== Warning: set address range perms: large range 268435424, a 1
==23496== Warning: set address range perms: large range 268435424, a 1
==23496== Warning: set address range perms: large range 268435424, a 1
==23496== Warning: set address range perms: large range 268435424, a 1
==23496== Warning: set address range perms: large range 268435424, a 1

VG_(get_memory_from_mmap): request for 8192 bytes failed.
VG_(get_memory_from_mmap): 2119042790 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.  You might want to use 'top'
to determine whether you really have run out of swap.
If so, you may be able to work around it by adding a
temporary swap file -- this is easier than finding a
new swap partition.  Go ask your sysadmin(s) [politely!]

VG_(get_memory_from_mmap): out of memory!  Fatal!  Bye!

I believe I have enough swap space.  Is there anything I can try?

Thanks for your help.

Mitch

--
NOTICE: If received in error, please destroy and notify sender.  Sender does not waive confidentiality or privilege, and use is prohibited.

Re: [Valgrind-users] Re: --gen-suppressions prompting

[Madhu M K. <mm...@ya...>]

Hi,

Leonard mckinley <spa...@ya...> said:

> 
> Works well, thanks!  Just two buglets.  The "ask" and "yes" cases are
> reversed (that is, it asks when you say "yes", and doesn't ask when
> you say "ask").  

Aargh. Should have explained this better:

--gen-suppressions=no (obvious)
--gen-suppressions=yes (just like before, will ask you for each, dump to
stdout)
--gen-suppressions=filename (will create filename.pidX and dump there,
no prompting at all)
 
I wanted to maintain backward compat with the previous usage...

	Does that explain it?

Cheerio,
M

 Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com

[Valgrind-users] Re: --gen-suppressions prompting

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

> >What do you think of a --gen-suppressions={yes|no|ask} option. 
> >"yes" would generate suppressions without a prompt for every 
> >flagged issue, and "ask" would do what yes does now.  I just want 
> >it to dump everything in a file and when it prompts me I have to 
> >sit there and bang "y" on the keyboard.
> 
> Attached is a patch that does precisely that. It accumulates
> suppressions and dumps them into a file, sorted by frequency at
> which they were hit during the execution.

Works well, thanks!  Just two buglets.  The "ask" and "yes" cases are
reversed (that is, it asks when you say "yes", and doesn't ask when you
say "ask").  

Also, --help doesn't tell you about the new-and-improved
--gen-suppressions syntax.

I notice that it dumps suppressions in separate files for separate
subprocesses/threads in "yes" mode, but I guess that's the expected
behavior.

Randall


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

Re: [Valgrind-users] --gen-suppressions prompting

[Madhu M. K. <mm...@ya...>]

Hi,

Leonard mckinley wrote:
>What do you think of a --gen-suppressions={yes|no|ask} option.  "yes"
>would generate suppressions without a prompt for every flagged issue,
>and "ask" would do what yes does now.  I just want it to dump
>everything in a file and when it prompts me I have to sit there and
>bang "y" on the keyboard.

Attached is a patch that does precisely that. It accumulates suppressions
and dumps them into a file, sorted by frequency at which they were hit
during the execution.

	I've found this to be fairly useful by running through my programs
with the simplest startup/shutdown execution path. This captures all the
background noise. With the generated suppression file, I then try the
various options in the code to discover problems that I'm in a position to
fix. In addition, reading the low frequency count errors is a good idea :)

	Could you apply this patch and let me know how it goes?

Cheerio,
M

 Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com

Re: [Valgrind-users] Ouch!! what happenned here?

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

On Fri, 13 Jun 2003, Joshua Moore-Oliva wrote:

> I was running a lot of data through some stuff bugtesting, when I got this...
>
> I'm just duly reporting it.
>
> valgrind: the `impossible' happened:
>    add_waiting_fd: VG_N_WAITING_FDS is too low
> Basic block ctr is approximately 1200000

It's easy to fix, VG_N_WAITING_FDS is just a constant chosen for a table
size.  It's defined in coregrind/vg_include.h as 10, if you bump it up to
20 or 50 or something, hopefully that will fix the problem.  And we should
probably do likewise in the CVS head now that you've hit your head against
the limit.

Thanks for the report.

N

[Valgrind-users] Ouch!! what happenned here?

[Joshua Moore-O. <jo...@ch...>]

I was running a lot of data through some stuff bugtesting, when I got this...

I'm just duly reporting it.

Josh.

valgrind: the `impossible' happened:
   add_waiting_fd: VG_N_WAITING_FDS is too low
Basic block ctr is approximately 1200000

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x40181DD4: (within /usr/lib/valgrind/valgrind.so)
==5789==    by 0x40217C4C: __pthread_getspecific_addr (in 
/usr/lib/valgrind/libpthread.so)
==5789==    by 0x402181D0: libc_internal_tsd_address (in 
/usr/lib/valgrind/libpthread.so)
==5789==    by 0x402BCCF3: _IO_vfscanf_internal (in /lib/libc-2.3.1.so)
==5789==    by 0x402C50C4: _IO_vsscanf (in /lib/libc-2.3.1.so)
==5789==    by 0x402C17CC: __GI_sscanf (in /lib/libc-2.3.1.so)
==5789==    by 0x804E62A: ffm_load_data_pair (ffm_load_data_pair.c:5)
==5789==    by 0x804E5C8: ffm_fill (ffm_fill.c:10)
==5789==    by 0x804E19F: ffm_load_from_buffer (ffm_load_from_buffer.c:51)
==5789==    by 0x804DE1F: ffm_load_from_file (ffm_load_from_file.c:28)
==5789==    by 0x804D6AD: thread_data_init (thread_data_init.c:32)
==5789==    by 0x804C37F: main (main.c:73)
==5789==    by 0x40274DC3: __libc_start_main (in /lib/libc-2.3.1.so)
==5789==    by 0x804A2A0: (within 
/home/chatgris/code/mastermailings/code/daemons/sendparser/sendctrl)

Thread 2: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804D4BA: send_value_get_response 
(send_value_get_response.c:10)
==5789==    by 0x804D2C3: send_message_source (send_message_source.c:13)
==5789==    by 0x804CDCE: send_message (send_message.c:54)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 3: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804D4BA: send_value_get_response 
(send_value_get_response.c:10)
==5789==    by 0x804D2C3: send_message_source (send_message_source.c:13)
==5789==    by 0x804CDCE: send_message (send_message.c:54)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 4: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804D4BA: send_value_get_response 
(send_value_get_response.c:10)
==5789==    by 0x804D414: send_priority (send_priority.c:24)
==5789==    by 0x804CD85: send_message (send_message.c:47)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 5: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804D4BA: send_value_get_response 
(send_value_get_response.c:10)
==5789==    by 0x804D414: send_priority (send_priority.c:24)
==5789==    by 0x804CD85: send_message (send_message.c:47)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 6: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804CD3D: send_message (send_message.c:41)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 7: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804CD3D: send_message (send_message.c:41)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 8: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804CD3D: send_message (send_message.c:41)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 9: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804CD3D: send_message (send_message.c:41)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 10: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804CD3D: send_message (send_message.c:41)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 11: status = WaitFD, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804CD3D: send_message (send_message.c:41)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 12: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x4032D934: __GI___libc_read (in /lib/libc-2.3.1.so)
==5789==    by 0x804C586: netstring_get (netstring_get.c:10)
==5789==    by 0x804CD3D: send_message (send_message.c:41)
==5789==    by 0x40216569: thread_wrapper (in /usr/lib/valgrind/libpthread.so)
==5789==    by 0x40165C6E: do__quit (in /usr/lib/valgrind/valgrind.so)

Thread 13: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x402164BD: thread_wrapper (in /usr/lib/valgrind/libpthread.so)

Thread 14: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x402164BD: thread_wrapper (in /usr/lib/valgrind/libpthread.so)

Thread 15: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==5789==    at 0x402164BD: thread_wrapper (in /usr/lib/valgrind/libpthread.so)


Note: see also the FAQ.txt in the source distribution.
It contains workarounds to several common problems.

If that doesn't help, please report this bug to: js...@ac...

In the bug report, send all the above text, the valgrind
version, and what Linux distro you are using.  Thanks.

[Valgrind-users] Segment override again ?

[<yu...@ii...>]

I'm running on a Linux 2.5.70 Hyperthreading-aware P4 machine with the latest 
nvidia drivers and latest KDE cvs.  Should valgrind work with this setup? I 
know it worked with my older PIII/nvidia system a few weeks ago.  When I try 
'valgrind kwrite' I get

==693== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==693== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==693== Using valgrind-cvs-head-2003-04-23, a program supervision framework 
for x86-linux.
==693== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==693== Estimated CPU clock rate is 3087 MHz
==693== For more details, rerun with: -v
==693==
==693==
==693== Valgrind detected that your program requires
==693== the following unimplemented functionality:
==693==    x86 segment override (SEG=CS) prefix
==693== This may be because the functionality is hard to implement,
==693== or because no reasonable program would behave this way,
==693== or because nobody has yet needed it.  In any case, let me know
==693== (js...@ac...) and/or try to work around the problem, if you can.
==693==
==693== Valgrind has to exit now.  Sorry.  Bye!
==693==

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==693==    at 0x4000ABC9: call_init (in /lib/ld-2.3.2.so)
==693==    by 0x4000ADBE: _dl_init_internal (in /lib/ld-2.3.2.so)
==693==    by 0x400009EC: (within /lib/ld-2.3.2.so)

-Jesse

[Valgrind-users] Thanks!

[Beau D. S. <sim...@ha...>]

I wanted to thank everyone for their help a few nights ago w/ my thread
problem.

I decided to start over on the project and have been using valgrind from the
very beginning this time. I found lots of other nasty little problems as
I've gone along [apparently, char* something = strdup("Hello world"); delete
something; isn't quite right....] so it is already proving to be really
useful.

I might not go as far as try and figure out how to do this project w/o
threads, but I'll investigate my options when I get to that part again.

Thanks again!


Beau D. Simensen
http://www.halogen.org/

Re: [Valgrind-users] [ BUG ] pthread_once

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

On Don, 12 Jun 2003, Steve G wrote:

> Subsequent calls to pthread_once  with  the  same 
> once_control argument do nothing.

True, fixed. 


-- 
Dirk

[Valgrind-users] Kudos

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

     Thanks to all who've contributed for an awesome tool.  I've 
picked it up now and again, but I'm stuck on it this time.  No more 
wishing for the Sun/IRIX flavor of Purify on Linux.  valgrind has 
gotten good enough I'm going to make it SOP to run it on any program I 
work on of non-trivial length (especially if someone else wrote parts 
of it).  Once I double the memory in my box (a trivial expense by
comparison), I'm set for some serious valgrinding!

Randall


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

[Valgrind-users] [ BUG ] pthread_once

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

Hello,

I ran across a problem auditing a daemon. Appearantly, it
calls pthread_once() more than once and valgrind terminates
the run. In coregrind/vg_libpthread.c around line 1500 is
this code:

   res = __pthread_mutex_lock(&once_masterlock);
                                                           
                    
   if (res != 0) {
      barf("pthread_once: Looks like your program's "
           "init routine calls back to pthread_once() ?!");
   }
                                                           
                    
The man page for pthread_once says: 

Subsequent calls to pthread_once  with  the  same 
once_control argument do nothing.

So, I changed "barf()" to "return 0" and everything works
OK now. It seems that valgrind ought to store the
init_routine's address away and just return if they've
already been called/stored. FWIW, the daemon I'm testing is
/usr/sbin/named.

Best Regards,
Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] cry for assistanse

[Tristan V. B. <va...@to...>]

    This mail seems to follow me. I've been recieving it for a year now
every month or so from my sf.net alias, my free mail accounts and finally at
work. This is getting spooky man.

Cheers all,
        -Tristan

PS: Please excuse off-topic reply

Gao, Jiafu wrote:

>Hi,
>
>What is this email? Sounds to me it is a scam. Most importantly, this mail
>list is not for this purpose regardless the truth of the email. I was quite
>annoyed but this kind of emails. I believe this guys sent out such email
>more than once on this list.
>
>J
>
>-----Original Message-----
>From: . [mailto:la...@ne...] 
>Sent: Thursday, June 12, 2003 4:41 PM
>To: val...@li...
>Subject: [Valgrind-users] cry for assistanse
>
>
>FROM: AMSTERDAM-NETHERLANDS
>
>Dear friend,
>
>You may be surprised to receive this letter from me since 
>you do not know me personally. I am the first son of the 
>most popular black farmer in Zimbabwe who was 
>murdered in the land dispute in my country. I got your 
>contact through network online hence decided to write 
>you. Before the death of my father, he had taken me to 
>Johannesburg to deposit the sum of USD5.Million (Five 
>million United States dollars), in one of the private 
>security company, as he foresaw the looming danger in 
>Zimbabwe. This money was deposited in a box as gem 
>stones to avoid much demurrage from Security Company.
>
>This amount was meant for the purchase of new machines 
>and chemicals for the Farms and establishment of new 
>farms in Swaziland. This land problem came when 
>Zimbabwean President Mr. Robert Mugabe when he 
>introduced a new Land Act Reform wholly affecting the 
>rich white farmers and some few black farmers, and this 
>resulted to the killing and mob action by Zimbabwean 
>war veterans and some lunatics in the society. In fact a lot 
>of people were killed because of this Land reform Act for 
>which my father was one of the victims. it is against this 
>background that I and my family fled Zimbabwe to South 
>Africa for fear of our lives.
>
>After which I traveled to the Netherlands and I am 
>currently staying in the Netherlands where i am seeking 
>political asylum and more so have decided to transfer my 
>father's money to a more reliable foreign account. Since 
>the law of Europe prohibits a refugee (asylum seeker) to 
>open any bank account or to be involved in any financial 
>transaction throughout the territorial zone of European 
>Union. As the eldest child of my father, I am saddled with 
>the responsibility of seeking a genuine foreign account 
>where this money could be transferred without the 
>knowledge of my government who are bent on taking 
>everything we have got. 
>
>The South African government seems to be playing along 
>with them. I am faced with the dilemma of moving this 
>amount of money out of South Africa for fear of going 
>through the same experience in future. Both countries 
>have similar political history. I am seeking for a partner 
>who I have to entrust my future and that of my family in 
>his hands, I must let you know that this transaction is risk 
>free. If you accept to assist me and my family, all I want 
>you to do for me, is to make arrangements with the 
>security company to clear the Consignment (funds) from 
>their affiliate office here in the Netherlands as i have 
>already given directives for the consignment to be brought 
>to the Netherlands from South Africa.
>
>But before then all modalities will have to be put in place 
>like change of ownership to the consignment. I have two 
>options for you. Firstly you can choose to have certain 
>percentage of the money for nominating your account for 
>this transaction. Or you can go into partnership with me 
>for the proper profitable investment of the money in your 
>country. Whichever the option you want, feel free to 
>notify me. I have also mapped out 2% of this money for 
>all kinds of expenses incurred in the process of this 
>transaction. If you do not prefer a partnership I am willing 
>to give you 10% of the money while the remaining 88% 
>will be for my investment in your country. Contact with 
>me immediately while I implore you to maintain the 
>absolute secrecy required in this transaction. 
>
>Thanks, GOD BLESS YOU 
>
>Best regards,
>
>
>NOTE: 
>ON YOUR INABILITY TO HANDLE THIS 
>TRANSACTION RESPOND TO ME AND INFORM 
>ME SO I CAN LOOK FOR SOMEONE ELSE.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: eBay
>Great deals on office technology -- on eBay now! Click here:
>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
>_______________________________________________
>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. 
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by: eBay
>Great deals on office technology -- on eBay now! Click here:
>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
>_______________________________________________
>Valgrind-users mailing list
>Val...@li...
>https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
>  
>

RE: [Valgrind-users] cry for assistanse

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

Hi,

What is this email? Sounds to me it is a scam. Most importantly, this mail
list is not for this purpose regardless the truth of the email. I was quite
annoyed but this kind of emails. I believe this guys sent out such email
more than once on this list.

J

-----Original Message-----
From: . [mailto:la...@ne...] 
Sent: Thursday, June 12, 2003 4:41 PM
To: val...@li...
Subject: [Valgrind-users] cry for assistanse


FROM: AMSTERDAM-NETHERLANDS

Dear friend,

You may be surprised to receive this letter from me since 
you do not know me personally. I am the first son of the 
most popular black farmer in Zimbabwe who was 
murdered in the land dispute in my country. I got your 
contact through network online hence decided to write 
you. Before the death of my father, he had taken me to 
Johannesburg to deposit the sum of USD5.Million (Five 
million United States dollars), in one of the private 
security company, as he foresaw the looming danger in 
Zimbabwe. This money was deposited in a box as gem 
stones to avoid much demurrage from Security Company.

This amount was meant for the purchase of new machines 
and chemicals for the Farms and establishment of new 
farms in Swaziland. This land problem came when 
Zimbabwean President Mr. Robert Mugabe when he 
introduced a new Land Act Reform wholly affecting the 
rich white farmers and some few black farmers, and this 
resulted to the killing and mob action by Zimbabwean 
war veterans and some lunatics in the society. In fact a lot 
of people were killed because of this Land reform Act for 
which my father was one of the victims. it is against this 
background that I and my family fled Zimbabwe to South 
Africa for fear of our lives.

After which I traveled to the Netherlands and I am 
currently staying in the Netherlands where i am seeking 
political asylum and more so have decided to transfer my 
father's money to a more reliable foreign account. Since 
the law of Europe prohibits a refugee (asylum seeker) to 
open any bank account or to be involved in any financial 
transaction throughout the territorial zone of European 
Union. As the eldest child of my father, I am saddled with 
the responsibility of seeking a genuine foreign account 
where this money could be transferred without the 
knowledge of my government who are bent on taking 
everything we have got. 

The South African government seems to be playing along 
with them. I am faced with the dilemma of moving this 
amount of money out of South Africa for fear of going 
through the same experience in future. Both countries 
have similar political history. I am seeking for a partner 
who I have to entrust my future and that of my family in 
his hands, I must let you know that this transaction is risk 
free. If you accept to assist me and my family, all I want 
you to do for me, is to make arrangements with the 
security company to clear the Consignment (funds) from 
their affiliate office here in the Netherlands as i have 
already given directives for the consignment to be brought 
to the Netherlands from South Africa.

But before then all modalities will have to be put in place 
like change of ownership to the consignment. I have two 
options for you. Firstly you can choose to have certain 
percentage of the money for nominating your account for 
this transaction. Or you can go into partnership with me 
for the proper profitable investment of the money in your 
country. Whichever the option you want, feel free to 
notify me. I have also mapped out 2% of this money for 
all kinds of expenses incurred in the process of this 
transaction. If you do not prefer a partnership I am willing 
to give you 10% of the money while the remaining 88% 
will be for my investment in your country. Contact with 
me immediately while I implore you to maintain the 
absolute secrecy required in this transaction. 

Thanks, GOD BLESS YOU 

Best regards,


NOTE: 
ON YOUR INABILITY TO HANDLE THIS 
TRANSACTION RESPOND TO ME AND INFORM 
ME SO I CAN LOOK FOR SOMEONE ELSE.

























-------------------------------------------------------
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
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. 

[Valgrind-users] cry for assistanse

[. <la...@ne...>]

FROM: AMSTERDAM-NETHERLANDS

Dear friend,

You may be surprised to receive this letter from me since 
you do not know me personally. I am the first son of the 
most popular black farmer in Zimbabwe who was 
murdered in the land dispute in my country. I got your 
contact through network online hence decided to write 
you. Before the death of my father, he had taken me to 
Johannesburg to deposit the sum of USD5.Million (Five 
million United States dollars), in one of the private 
security company, as he foresaw the looming danger in 
Zimbabwe. This money was deposited in a box as gem 
stones to avoid much demurrage from Security Company.

This amount was meant for the purchase of new machines 
and chemicals for the Farms and establishment of new 
farms in Swaziland. This land problem came when 
Zimbabwean President Mr. Robert Mugabe when he 
introduced a new Land Act Reform wholly affecting the 
rich white farmers and some few black farmers, and this 
resulted to the killing and mob action by Zimbabwean 
war veterans and some lunatics in the society. In fact a lot 
of people were killed because of this Land reform Act for 
which my father was one of the victims. it is against this 
background that I and my family fled Zimbabwe to South 
Africa for fear of our lives.

After which I traveled to the Netherlands and I am 
currently staying in the Netherlands where i am seeking 
political asylum and more so have decided to transfer my 
father's money to a more reliable foreign account. Since 
the law of Europe prohibits a refugee (asylum seeker) to 
open any bank account or to be involved in any financial 
transaction throughout the territorial zone of European 
Union. As the eldest child of my father, I am saddled with 
the responsibility of seeking a genuine foreign account 
where this money could be transferred without the 
knowledge of my government who are bent on taking 
everything we have got. 

The South African government seems to be playing along 
with them. I am faced with the dilemma of moving this 
amount of money out of South Africa for fear of going 
through the same experience in future. Both countries 
have similar political history. I am seeking for a partner 
who I have to entrust my future and that of my family in 
his hands, I must let you know that this transaction is risk 
free. If you accept to assist me and my family, all I want 
you to do for me, is to make arrangements with the 
security company to clear the Consignment (funds) from 
their affiliate office here in the Netherlands as i have 
already given directives for the consignment to be brought 
to the Netherlands from South Africa.

But before then all modalities will have to be put in place 
like change of ownership to the consignment. I have two 
options for you. Firstly you can choose to have certain 
percentage of the money for nominating your account for 
this transaction. Or you can go into partnership with me 
for the proper profitable investment of the money in your 
country. Whichever the option you want, feel free to 
notify me. I have also mapped out 2% of this money for 
all kinds of expenses incurred in the process of this 
transaction. If you do not prefer a partnership I am willing 
to give you 10% of the money while the remaining 88% 
will be for my investment in your country. Contact with 
me immediately while I implore you to maintain the 
absolute secrecy required in this transaction. 

Thanks, GOD BLESS YOU 

Best regards,


NOTE: 
ON YOUR INABILITY TO HANDLE THIS 
TRANSACTION RESPOND TO ME AND INFORM 
ME SO I CAN LOOK FOR SOMEONE ELSE.

Re: [Valgrind-users] Suppression stack questions

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

On Thu, 12 Jun 2003, Leonard mckinley wrote:

> Couple questions.  How do I specify a wildcard for multiple
> stack frames in a suppression stack.  If anyone's used purify, I'm
> talking about the equivalent to its "..." syntax.
>
> For example, in the below error, I want to match on any stack that
> matches: <top> ..., __writev, ..., XQueryExtension, ... <bottom>

Valgrind doesn't support that, sorry.

> Also, is there a way to match on more than 5 stack frames?

Unfortunately no.

N

[Valgrind-users] XQueryExtension

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

Seeing a few strange things running valgrind on an app linked with X
(XFree86 4.2.0).

At one point this app calls XQueryExtension like this:

   XQueryExtension( display, XF86VIDMODENAME, 
                    &major_opcode, &first_event, &first_error )

I can print out all the arguments and they're fine (they don't trip
any valgrind errors at least), but when this routine its called, it
generates an uninitialized data used error down in the X send code.
However, if I put this call in a stand-alone program with just an
XOpenDisplay before it it works fine.

Any ideas?  This looks similar to a "Resulting from R H 8.0"
suppression in the default suppression files, so I'm hoping whoever
added it will see this and reply.

Thanks,

Randall


 Syscall param writev(vector[...]) contains uninitialised or
unaddressable byte(s)
    at 0x4017C281: vgAllRoadsLeadToRome_writev (vg_intercept.c:108)
    by 0x4017C2BE: __writev (vg_intercept.c:731)
    by 0x408210AF: _X11TransSocketWritev (in
/usr/X11R6/lib/libX11.so.6.2)
    by 0x40821CCE: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
    by 0x40801CF4: _XSend (in /usr/X11R6/lib/libX11.so.6.2)
    by 0x407F810A: XQueryExtension (in /usr/X11R6/lib/libX11.so.6.2)


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] Valgrind/Cachegrind stack overflow problem with Wine app

[Prashant V. <pra...@ya...>]

Julian,

--- Julian Seward <js...@ac...> wrote:
> On Tuesday 10 June 2003 14:39, John Reiser wrote:
> > Prashant Verma wrote:
...
> >  > disInstr: unhandled opcode 0x94 then 0x8B
> >
> > 0x94 is "xchg %eax,%esp", which is switching
> stacks: some form of threads
> > that is specific to the application.
> 
> In which case, the fix is ultra-trivial.  Find the
> following line
> in vg_to_ucode.c:
> 
>    case 0x91: /* XCHG eAX,eCX */
> 

I added 0x94 case to the switch statement, and
valgrind no longer displays the error message. There
are other problems however, but certainly not related
to this issue. The fix seems to work fine.

-Prashant


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

[Valgrind-users] Suppression stack questions

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

Couple questions.  How do I specify a wildcard for multiple
stack frames in a suppression stack.  If anyone's used purify, I'm
talking about the equivalent to its "..." syntax.

For example, in the below error, I want to match on any stack that
matches: <top> ..., __writev, ..., XQueryExtension, ... <bottom>

Also, is there a way to match on more than 5 stack frames?

Thanks,

Randall

Syscall param writev(vector[...]) contains uninitialised or
unaddressable byte(s)
    at 0x4017C281: vgAllRoadsLeadToRome_writev (vg_intercept.c:108)
    by 0x4017C2BE: __writev (vg_intercept.c:731)
    by 0x408210AF: _X11TransSocketWritev (in
/usr/X11R6/lib/libX11.so.6.2)
    by 0x40821CCE: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
    by 0x40801CF4: _XSend (in /usr/X11R6/lib/libX11.so.6.2)
    by 0x407F810A: XQueryExtension (in /usr/X11R6/lib/libX11.so.6.2)


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] Suppression bug with Memcheck:Value16

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

> > > ==2336== Use of uninitialised value of size 16
> > > ==2336==    at 0x40D64260: __nvsym04804 (in
> > > Memcheck: the `impossible' happened:
> >
> I just added support for "Value16" and "Addr16" suppressions to CVS. 
> I would appreciate it if you could test the changes.

Works fine.  With this suppression rule:

{
   nvidia_1.0_3123_008
   Memcheck:Value16
   fun:__nvsym04804
}

valgrind's log now just reports:

--17277-- supp:  306 nvidia_1.0_3123_008

in the suppression summary.

Thanks for the quick patch.

Randall


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] Re: Recommended gcc version

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

On Tue, 10 Jun 2003, Melchior FRANZ wrote:

> I can confirm that cvs/head gives hundreds of bogus error messages
> about mismatched allocation. I only checked one of them and saw that
> the concerned code creates an automatic variable of a c++ object.
> valgrind obviously complains when the auto var is to be destroyed
> at function end. The bug was introduced with "vg_replace_malloc.c"
> revision 1.7. (1.6 did still work.)

We've rolled back to 1.6 in CVS.  The change was intended to fix another
problem, but ended up breaking more things than it fixed, on some
machines.  Thanks for the feedback.

N

Re: [Valgrind-users] Suppression bug with Memcheck:Value16

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

On Wed, 11 Jun 2003, Nicholas Nethercote wrote:

> > Figuring I had the supression rule wrong, I reran with
> > --gen-suppressions=yes.  However, when valgrind hit this event in
> > the code, it crashed and said:
> >
> > ==2336== Thread 2:
> > ==2336== Use of uninitialised value of size 16
> > ==2336==    at 0x40D64260: __nvsym04804 (in
> > /usr/lib/libGLcore.so.1.0.3123)
> > ==2336==
> > ==2336== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----
> > Memcheck: the `impossible' happened:
> >    unexpected size for Value
> > Basic block ctr is approximately 104700000
>
> It's a bug/oversight -- Valgrind doesn't support suppressions for 16 byte
> value errors.  I will investigate, hopefully get back to you soon.

I just added support for "Value16" and "Addr16" suppressions to CVS.  I
would appreciate it if you could test the changes.

Note that three other value error sizes -- 10, 28, 108 -- are possible,
but not suppressible.  These strange sizes are for various floating point
ops, and we'll add support for suppressing them when someone needs it.

N