Home / Browse / Valgrind, an open-source memory debugger / Mail / Archive

Valgrind, an open-source memory debugger

Email Archive: valgrind-users (read-only)

[Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Benny Cheung <bwlcheung@gm...> - 2005-03-24 18:33

Nicholas Nethercote <njn <at> cs.utexas.edu> writes:

> Even if that's the case, Valgrind should die with a helpful error message 
> rather than just seg faulting.  Benny, can you file a Bugzilla bug report? 
> (see http://www.valgrind.org/support/bug_reports.html).

Hi Nicholas,

Here is my bug report. Hope it is of the right format and gives clear enough
description, since I am writing such report for the first time. Please
let me know if
you need further information. Thanks a lot!

Best Regards,
Benny.

========= Bug Report: Segmentation fault with valgrind 2.4.0-rc4 ==========

Valgrind version: 2.4.0-rc4
Linux version: Fedora Core 1
Kernel version (uname -r): 2.4.22-1.2115.nptl
Compilation command: g++ -o ad65536 -g -O -DN=65536 -Wno-deprecated
dsminit-add.cpp dsmlock.cpp dsmcomm.cpp dsmmem.cpp dsmall.cpp
g++ (gcc) version: gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)

My application program is a parallel program. I run it using 8 machines, they
communicate with each other through Linux sockets. SIGIO handler is installed
and file I/O is possible. However, when error occurs, there should not
be any SIGIO
signal invoking (signals may be invoked during my self-implemented barrier, but
they should have been served). There are no file I/O yet at the point
of valgrind
crash, except the program needs to read in the machine list at the start.

This is the error log obtained using valgrind -v:

[benny@... benny]$ vg/bin/valgrind -v --tool=memcheck
--error-limit=no ./ad65536
==6859== Memcheck, a memory error detector for x86-linux.
==6859== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==6859== Using valgrind-2.4.0.rc4, a program supervision framework for
x86-linux.
==6859== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==6859== Valgrind library directory: /home/benny/vg/lib/valgrind
==6859== Command line
==6859==    ./ad65536
==6859== Startup, with flags:
==6859==    -v
==6859==    --tool=memcheck
==6859==    --error-limit=no
==6859== Contents of /proc/version:
==6859==   Linux version 2.4.22-1.2115.nptl
(bhcompile@...) (gcc version 3.2.3 20030422 (Red Hat
Linux 3.2.3-6)) #1 Wed Oct 29 15:42:51 EST 2003
==6859== Reading syms from /home/benny/ad65536 (0x8048000)
==6859== Warning: set address range perms: large range 285949952, a 0, v 0
==6859== Reading syms from /mnt/nfsroot/lib/ld-2.3.2.so (0x1B8E4000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /home/benny/vg/lib/valgrind/stage2 (0xB0000000)
==6859== Reading syms from /mnt/nfsroot/lib/ld-2.3.2.so (0xB1000000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/libdl-2.3.2.so (0xB1016000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libc-2.3.2.so (0xB1019000)
==6859==    object doesn't have any debug info
==6859== Reading syms from
/home/benny/vg/lib/valgrind/vgskin_memcheck.so (0xB1152000)
==6859== Reading suppressions file: /home/benny/vg/lib/valgrind/default.supp
==6859==
==6859== Reading syms from /home/benny/vg/lib/valgrind/vg_inject.so (0x1B8FD000)
==6859== Reading syms from
/home/benny/vg/lib/valgrind/vgpreload_memcheck.so (0x1B900000)
==6859== Reading syms from /mnt/nfsroot/usr/lib/libstdc++.so.5.0.5 (0x1B918000)
==6859==    object doesn't have a symbol table
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libm-2.3.2.so (0x1B9D1000)
==6859==    object doesn't have any debug info
==6859== Reading syms from
/mnt/nfsroot/lib/libgcc_s-3.3.2-20031023.so.1 (0x1B9F4000)
==6859==    object doesn't have a symbol table
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libc-2.3.2.so (0x1B9FD000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/libdl-2.3.2.so (0x1BB39000)
==6859==    object doesn't have any debug info
==6859== TRANSLATE: 0x1BA731D0 redirected to 0x1B9045A8
==6859== TRANSLATE: 0x1B8E4C30 redirected to 0x52BFF020
start
==6859== TRANSLATE: 0x1BA6C080 redirected to 0x1B9034E0
The file has 8 lines
==6859== TRANSLATE: 0x1BA6C200 redirected to 0x1B9039F0
ID is 0
ID 0: Hostname is GD074A
rsh -l benny GD075A "./ad65536 dsmid 1 port 17767 " &
rsh -l benny GD076A "./ad65536 dsmid 2 port 17767 " &
rsh -l benny GD077A "./ad65536 dsmid 3 port 17767 " &
rsh -l benny GD078A "./ad65536 dsmid 4 port 17767 " &
rsh -l benny GD079A "./ad65536 dsmid 5 port 17767 " &
rsh -l benny GD080A "./ad65536 dsmid 6 port 17767 " &
rsh -l benny GD081A "./ad65536 dsmid 7 port 17767 " &
First 0 is 0x8212020
Final 2047 is 0x10212000
End bound is 0x10222020
ID 0: Comm Init Okay
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
maddr[0] is 0x1c7fc028
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
maddr[1] is 0x2c7fe028
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
maddr[2] is 0x3c800028
start
The file has 8 lines
ID is 2
ID 2: Hostname is GD076A
start
The file has 8 lines
ID is 1
ID 1: Hostname is GD075A
start
The file has 8 lines
ID is 3
ID 3: Hostname is GD077A
start
The file has 8 lines
ID is 4
ID 4: Hostname is GD078A
start
The file has 8 lines
ID is 5
ID 5: Hostname is GD079A
start
The file has 8 lines
ID is 6
ID 6: Hostname is GD080A
start
The file has 8 lines
ID is 7
ID 7: Hostname is GD081A
==6859== TRANSLATE: 0x1B9A8600 redirected to 0x1B903881
==6859== TRANSLATE: 0x1B9A6F50 redirected to 0x1B903D08
xbcount = 1, linec = 8, from 0
barr(): now at barrwait
xbcount = 2, linec = 8, from 2
xbcount = 3, linec = 8, from 5
xbcount = 4, linec = 8, from 7
xbcount = 5, linec = 8, from 1
xbcount = 6, linec = 8, from 3
xbcount = 7, linec = 8, from 6
xbcount = 8, linec = 8, from 4
Into barrgrant sending routine
Sending Barrgrant message to 0
Sending Barrgrant message to 1
Sending Barrgrant message to 2
Sending Barrgrant message to 3
Sending Barrgrant message to 4
Sending Barrgrant message to 5
Sending Barrgrant message to 6
Sending Barrgrant message to 7
barr(): barrwait says 0, passed barrier
Debug: Allocating 65536 elements on obj 128, address in object map is 0x1c7fc220
Debug: id = 128, objid = 128, #segment = 16
Debug: first segment address 0x1e7bc028
Debug: Allocating 65536 elements on obj 256, address in object map is 0x1c7fc420
Debug: id = 256, objid = 256, #segment = 16
Debug: first segment address 0x207bc028
Debug: Allocating 65536 elements on obj 384, address in object map is 0x1c7fc620
Debug: id = 384, objid = 384, #segment = 16
Debug: first segment address 0x227bc028
Debug: Allocating 65536 elements on obj 512, address in object map is 0x1c7fc820
Debug: id = 512, objid = 512, #segment = 16
Debug: first segment address 0x247bc028
Debug: Allocating 65536 elements on obj 640, address in object map is 0x1c7fca20
Debug: id = 640, objid = 640, #segment = 16
Debug: first segment address 0x267bc028
Debug: Allocating 65536 elements on obj 768, address in object map is 0x1c7fcc20
Debug: id = 768, objid = 768, #segment = 16
Debug: first segment address 0x287bc028
Debug: Allocating 65536 elements on obj 896, address in object map is 0x1c7fce20
Debug: id = 896, objid = 896, #segment = 16
Debug: first segment address 0x2a7bc028
Segmentation fault
[benny@... benny]$ exit

Script done on Thu 24 Mar 2005 07:48:32 PM HKT

(Using valgrind 2.2.0, the above error does not occur. Or, if my
program allocates
three chunks of 64MB of memory instead of 256MB, the above error does not
occur either with valgrind 2.4.0-rc4).

Thread View

Thread	Author	Date
[Valgrind-users] Newbie Question about Valgrind Address Relocation	Benny Cheung <bwlcheung@gm...>

Re: [Valgrind-users] Newbie Question about Valgrind Address Relocation

From: Tom Hughes <tom@co...> - 2005-03-20 14:52

In message <loom.20050320T140108-459@...>
          Benny Cheung <bwlcheung@...> wrote:

> I am trying to use the latest stable version of Valgrind to debug
> my parallel program, which tends to use quite a lot of (virtual)
> memory. The 0x60000000 - 0x90000000 region is allocated using mmap().

How do you know what address the region will be mapped at? If you're
trying to use MAP_FIXED to force it then be aware that valgrind will
fail attempts to map memory at some high addresses as only part of the
address space is available for your program - some is reserved for
valgrind to use.

> My program works to finish for a small problem size without invoking
> the debugger, but having problems on large problem size. However,
> when Valgrind is invoked, I get this error no matter the problem size
> is small or large:
> 
> ==21397== TRANSLATE: 0x2129C1D0 redirected to 0x2112C68C
> ==21397== TRANSLATE: 0x1B8E4C30 redirected to 0x52BFF040
> start
> ==21397== TRANSLATE: 0x21295080 redirected to 0x2112CCBC
> The file has 4 lines
> ==21397== TRANSLATE: 0x21295200 redirected to 0x2112D1E8
> ID is 0
> ID 0: Hostname is GD033A
> rsh -l benny GD034A "./sor1022 dsmid 1 port 17767 " &
> rsh -l benny GD035A "./sor1022 dsmid 2 port 17767 " &
> rsh -l benny GD036A "./sor1022 dsmid 3 port 17767 " &
> ==21397==
> ==21397== Process terminating with default action of signal 11 (SIGSEGV)
> ==21397==  Bad permissions for mapped region at address 0x1B8E9444
> ==21397==    at 0x80548B6: comm_init() (dsmcomm.cpp:903)
> ==21397==    by 0x8049405: main (dsminit-sor.cpp:121)
> =
> 
> The faulting statement is just an initialization of some array structures:
> 
> for (i = 0; i < BUFFSLOT; i++)
>    multbuff[i].ref = 0;
> 
> At running this statement, the region 0x60000000 - 0x90000000 has not been
> mmap() yet.
> 
> I'd like to ask is the address 0x1B8E9444 relocated to some place after
> 0x52BFF040 and then got the error? How to avoid this problem, and is it
> possible to manually instruct address redirection destination?

What makes you think 0x1B8E9444 is relocated? As far as I can see
valgrind is saing that your programs tried to write to that location
but that it was mapped read-only.

If you're talking about the TRANSLATE line for 0x1B8E4C30 then that
is a function intercept and is nothing to do with any data access in
your program.

You need to look at how/when multibuff is allocated and what sort of
memory it is pointing at.

Tom

-- 
Tom Hughes (tom@...)
http://www.compton.nu/

[Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Benny Cheung <bwlcheung@gm...> - 2005-03-20 16:22

Hi Tom,

Tom Hughes <tom <at> compton.nu> writes:

> How do you know what address the region will be mapped at? If you're
> trying to use MAP_FIXED to force it then be aware that valgrind will
> fail attempts to map memory at some high addresses as only part of the
> address space is available for your program - some is reserved for
> valgrind to use.

Yes I did. But after I remove the MAP_FIXED in mmap() the memory 
(in 64MB chunks) still cannot be allocated. Maybe I need to change 
it back to malloc().

> If you're talking about the TRANSLATE line for 0x1B8E4C30 then that
> is a function intercept and is nothing to do with any data access in
> your program.

I see. That clears my doubt. Thanks a lot!

> You need to look at how/when multibuff is allocated and what sort of
> memory it is pointing at.

Turns out multibuff is not needed anyway (it is declared as 
struct dsmmsg multibuff[BUFFSLOT] as global and then initialized 
at a init function that causes the fault), but I still doubt why 
the fault does not happen without using Valgrind.

Best Regards,
Benny.

Re: [Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Julian Seward <jseward@ac...> - 2005-03-21 12:05

Basically it is a mistake to use MAP_FIXED at all, unless you have
complete control of the address space.  Which, in almost all programs
you don't.  A few years ago I worked on a project which did this, and
our program started to fail on obscure Linux distros.  We realised
our mistake and reworked it to get rid of MAP_FIXED.

J


On Sunday 20 March 2005 16:19, Benny Cheung wrote:
> Hi Tom,
>
> Tom Hughes <tom <at> compton.nu> writes:
> > How do you know what address the region will be mapped at? If you're
> > trying to use MAP_FIXED to force it then be aware that valgrind will
> > fail attempts to map memory at some high addresses as only part of the
> > address space is available for your program - some is reserved for
> > valgrind to use.
>
> Yes I did. But after I remove the MAP_FIXED in mmap() the memory
> (in 64MB chunks) still cannot be allocated. Maybe I need to change
> it back to malloc().
>
> > If you're talking about the TRANSLATE line for 0x1B8E4C30 then that
> > is a function intercept and is nothing to do with any data access in
> > your program.
>
> I see. That clears my doubt. Thanks a lot!
>
> > You need to look at how/when multibuff is allocated and what sort of
> > memory it is pointing at.
>
> Turns out multibuff is not needed anyway (it is declared as
> struct dsmmsg multibuff[BUFFSLOT] as global and then initialized
> at a init function that causes the fault), but I still doubt why
> the fault does not happen without using Valgrind.
>
> Best Regards,
> Benny.
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Benny Cheung <bwlcheung@gm...> - 2005-03-22 03:59

Julian Seward <jseward <at> acm.org> writes:

> 
> Basically it is a mistake to use MAP_FIXED at all, unless you have
> complete control of the address space.  Which, in almost all programs
> you don't.  A few years ago I worked on a project which did this, and
> our program started to fail on obscure Linux distros.  We realised
> our mistake and reworked it to get rid of MAP_FIXED.
> 
> J

Thanks Julian. I have changed the mmap() back to malloc(), and the program can 
run under Valgrind, but with such errors:

==5504== Syscall param write(buf) contains uninitialised or unaddressable byte
(s)
==5504==    at 0x1BACA743: __write_nocancel (in /mnt/nfsroot/lib/tls/libc-
2.3.2.so)
==5504==    by 0x1BA65D4D: new_do_write (in /mnt/nfsroot/lib/tls/libc-2.3.2.so)
==5504==    by 0x1BA66F3F: _IO_file_xsputn@... 
(in /mnt/nfsroot/lib/tls/libc-2.3.2.so)
==5504==    by 0x1BA5C2CE: _IO_fwrite_internal (in /mnt/nfsroot/lib/tls/libc-
2.3.2.so)
==5504==  Address 0x1C83E028 is 294912 bytes inside a block of size 268435456 
alloc'd
==5504==    at 0x1B903D48: malloc (vg_replace_malloc.c:131)
==5504==    by 0x8054F38: dm_init() (dsmmem.cpp:181)
==5504==    by 0x804931D: main (dsminit-add.cpp:123)

<Program Execution Continues for some time...>

valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed.
==5504==    at 0xB002A954: vgPlain_skin_assert_fail (vg_mylibc.c:1137)   
==5504==    by 0xB002A953: assert_fail (vg_mylibc.c:1133)
==5504==    by 0xB002A991: vgPlain_core_assert_fail (vg_mylibc.c:1144)
==5504==    by 0xB0028238: vgPlain_unmap_range (vg_memory.c:245)

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==5504==    at 0x52BFF042: ???
==5504==    by 0x1BA65569: _IO_file_close_it@... 
(in /mnt/nfsroot/lib/tls/libc-2.3.2.so)
==5504==    by 0x1BA5AF38: _IO_fclose@... (in /mnt/nfsroot/lib/tls/libc-
2.3.2.so)
==5504==    by 0x804C21F: swapoutobj(int, int, int, int, int) (dsm.h:836)

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: valgrind.kde.org

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


I am particularly concerned about the error message "Address 0x1C83E028 is 
294912 bytes inside a block of size 268435456 alloc'd". Seems the malloc() 
gives me a chunk of memory already allocated in another malloc()'ed chunk.

Does it suggest that Valgrind has some problems under the Linux version I am 
using? I am using Fedora core 1. 

Thanks and Best Regards,
Benny.

Re: [Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Tom Hughes <tom@co...> - 2005-03-22 07:13

In message <loom.20050322T045018-708@...>
          Benny Cheung <bwlcheung@...> wrote:

> <Program Execution Continues for some time...>
> 
> valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed.
> ==5504==    at 0xB002A954: vgPlain_skin_assert_fail (vg_mylibc.c:1137)
> ==5504==    by 0xB002A953: assert_fail (vg_mylibc.c:1133)
> ==5504==    by 0xB002A991: vgPlain_core_assert_fail (vg_mylibc.c:1144)
> ==5504==    by 0xB0028238: vgPlain_unmap_range (vg_memory.c:245)

If you're using 2.2.0 then that looks like a known bug that is fixed
in the CVS code the 2.4.0 release candidates so you might want to try
that.

> I am particularly concerned about the error message "Address 0x1C83E028 is
> 294912 bytes inside a block of size 268435456 alloc'd". Seems the malloc()
> gives me a chunk of memory already allocated in another malloc()'ed chunk.

That's just telling you where the first undefined byte is relative to
the start of the malloced block.

Tom

-- 
Tom Hughes (tom@...)
http://www.compton.nu/

[Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Benny Cheung <bwlcheung@gm...> - 2005-03-22 08:51

Hi,

Tom Hughes <tom <at> compton.nu> writes:

> > valgrind: vg_memory.c:229 (vgPlain_unmap_range): Assertion `rs == s' failed.
> > ==5504==    at 0xB002A954: vgPlain_skin_assert_fail (vg_mylibc.c:1137)
> > ==5504==    by 0xB002A953: assert_fail (vg_mylibc.c:1133)
> > ==5504==    by 0xB002A991: vgPlain_core_assert_fail (vg_mylibc.c:1144)
> > ==5504==    by 0xB0028238: vgPlain_unmap_range (vg_memory.c:245)
> 
> If you're using 2.2.0 then that looks like a known bug that is fixed
> in the CVS code the 2.4.0 release candidates so you might want to try
> that.

Thanks, I have tried installed 2.4.0-rc4, but not long after the execution 
starts I got a "Segmentation Fault" without any further Valgrind messages.
I invoked the program like this:

vg/bin/valgrind -v --tool=memcheck --error-limit=no ./ad64k

Is there a more stable 2.4.0 release, or any version that fixed the 2.2.0 
bug you mentioned at this moment? Thanks!

Best Regards,
Benny.

Re: [Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Jeremy Fitzhardinge <jeremy@go...> - 2005-03-22 17:46

Benny Cheung wrote:

>Is there a more stable 2.4.0 release, or any version that fixed the 2.2.0 
>bug you mentioned at this moment? Thanks!
>
2.4.0.rc4 is very close to what we're intending to release as 2.4.0.  
Could you go into a bit more detail about this crash (like the full 
output of valgrind -v)?

Thanks,
    J

[Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Benny Cheung <bwlcheung@gm...> - 2005-03-24 12:26

Hi Jeremy,

Jeremy Fitzhardinge <jeremy <at> goop.org> writes:

> 2.4.0.rc4 is very close to what we're intending to release as 2.4.0.  
> Could you go into a bit more detail about this crash (like the full 
> output of valgrind -v)?

Thank you very much for your response.
Below shows the log file (including all output by valgrind, the printout 
from my program has been suppressed), as you can see, the program suddenly 
gets a SEGV fault without going back to valgrind before exit.

I am wondering if this happens because my program makes use of too much 
virtual memory. As you can see, I have allocated 768MB at the start of the 
program. So I think it may not be a bug of the new version, but only that 
valgrind does not have enough virtual memory, thus causing the SEGV fault.

For your information, the same program can go through (runs longer before 
error, perhaps my own program bug) when I am using valgrind 2.2.0, and it can 
also run longer if I allocate a smaller chunk of memory (I have tried 
allocating 192MB instaed of 768MB, my program still works but theoretically 
will be slower).

I noticed that you are the author of the valgrind software. I appreciate a lot 
about your work, and I sincerely hope that you will keep it up with this good 
work. :)

Best Regards,
Benny.


==6859== Memcheck, a memory error detector for x86-linux.
==6859== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==6859== Using valgrind-2.4.0.rc4, a program supervision framework for x86-
linux.
==6859== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==6859== Valgrind library directory: /home/benny/vg/lib/valgrind
==6859== Command line
==6859==    ./ad65536
==6859== Startup, with flags:
==6859==    -v
==6859==    --tool=memcheck
==6859==    --error-limit=no
==6859== Contents of /proc/version:
==6859==   Linux version 2.4.22-1.2115.nptl (bhcompile@...) 
(gcc version 3.2.3 20030422 (Red Hat Linux 3.2.3-6)) #1 Wed Oct 29 15:42:51 EST 
2003
==6859== Reading syms from /home/benny/ad65536 (0x8048000)
==6859== Warning: set address range perms: large range 285949952, a 0, v 0
==6859== Reading syms from /mnt/nfsroot/lib/ld-2.3.2.so (0x1B8E4000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /home/benny/vg/lib/valgrind/stage2 (0xB0000000)
==6859== Reading syms from /mnt/nfsroot/lib/ld-2.3.2.so (0xB1000000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/libdl-2.3.2.so (0xB1016000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libc-2.3.2.so (0xB1019000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /home/benny/vg/lib/valgrind/vgskin_memcheck.so 
(0xB1152000)
==6859== Reading suppressions file: /home/benny/vg/lib/valgrind/default.supp
==6859== 
==6859== Reading syms from /home/benny/vg/lib/valgrind/vg_inject.so (0x1B8FD000)
==6859== Reading syms from /home/benny/vg/lib/valgrind/vgpreload_memcheck.so 
(0x1B900000)
==6859== Reading syms from /mnt/nfsroot/usr/lib/libstdc++.so.5.0.5 (0x1B918000)
==6859==    object doesn't have a symbol table
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libm-2.3.2.so (0x1B9D1000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/libgcc_s-3.3.2-20031023.so.1 
(0x1B9F4000)
==6859==    object doesn't have a symbol table
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libc-2.3.2.so (0x1B9FD000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/libdl-2.3.2.so (0x1BB39000)
==6859==    object doesn't have any debug info
==6859== TRANSLATE: 0x1BA731D0 redirected to 0x1B9045A8
==6859== TRANSLATE: 0x1B8E4C30 redirected to 0x52BFF020
==6859== TRANSLATE: 0x1BA6C080 redirected to 0x1B9034E0
==6859== TRANSLATE: 0x1BA6C200 redirected to 0x1B9039F0
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
==6859== TRANSLATE: 0x1B9A8600 redirected to 0x1B903881
==6859== TRANSLATE: 0x1B9A6F50 redirected to 0x1B903D08

Re: [Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Nicholas Nethercote <njn@cs...> - 2005-03-24 14:10

On Thu, 24 Mar 2005, Benny Cheung wrote:

> Below shows the log file (including all output by valgrind, the printout
> from my program has been suppressed), as you can see, the program suddenly
> gets a SEGV fault without going back to valgrind before exit.
>
> I am wondering if this happens because my program makes use of too much
> virtual memory. As you can see, I have allocated 768MB at the start of the
> program. So I think it may not be a bug of the new version, but only that
> valgrind does not have enough virtual memory, thus causing the SEGV fault.

Even if that's the case, Valgrind should die with a helpful error message 
rather than just seg faulting.  Benny, can you file a Bugzilla bug report? 
(see http://www.valgrind.org/support/bug_reports.html).

Jeremy, I wonder if it's a problem with the secondary map changes?

N

Re: [Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Jeremy Fitzhardinge <jeremy@go...> - 2005-03-24 17:22

Nicholas Nethercote wrote:

> Jeremy, I wonder if it's a problem with the secondary map changes? 

No, that would print something.  I'm guessing recursive allocation,
which likely means a leak.

    J

[Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Benny Cheung <bwlcheung@gm...> - 2005-03-24 18:33

Nicholas Nethercote <njn <at> cs.utexas.edu> writes:

> Even if that's the case, Valgrind should die with a helpful error message 
> rather than just seg faulting.  Benny, can you file a Bugzilla bug report? 
> (see http://www.valgrind.org/support/bug_reports.html).

Hi Nicholas,

Here is my bug report. Hope it is of the right format and gives clear enough
description, since I am writing such report for the first time. Please
let me know if
you need further information. Thanks a lot!

Best Regards,
Benny.

========= Bug Report: Segmentation fault with valgrind 2.4.0-rc4 ==========

Valgrind version: 2.4.0-rc4
Linux version: Fedora Core 1
Kernel version (uname -r): 2.4.22-1.2115.nptl
Compilation command: g++ -o ad65536 -g -O -DN=65536 -Wno-deprecated
dsminit-add.cpp dsmlock.cpp dsmcomm.cpp dsmmem.cpp dsmall.cpp
g++ (gcc) version: gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)

My application program is a parallel program. I run it using 8 machines, they
communicate with each other through Linux sockets. SIGIO handler is installed
and file I/O is possible. However, when error occurs, there should not
be any SIGIO
signal invoking (signals may be invoked during my self-implemented barrier, but
they should have been served). There are no file I/O yet at the point
of valgrind
crash, except the program needs to read in the machine list at the start.

This is the error log obtained using valgrind -v:

[benny@... benny]$ vg/bin/valgrind -v --tool=memcheck
--error-limit=no ./ad65536
==6859== Memcheck, a memory error detector for x86-linux.
==6859== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==6859== Using valgrind-2.4.0.rc4, a program supervision framework for
x86-linux.
==6859== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==6859== Valgrind library directory: /home/benny/vg/lib/valgrind
==6859== Command line
==6859==    ./ad65536
==6859== Startup, with flags:
==6859==    -v
==6859==    --tool=memcheck
==6859==    --error-limit=no
==6859== Contents of /proc/version:
==6859==   Linux version 2.4.22-1.2115.nptl
(bhcompile@...) (gcc version 3.2.3 20030422 (Red Hat
Linux 3.2.3-6)) #1 Wed Oct 29 15:42:51 EST 2003
==6859== Reading syms from /home/benny/ad65536 (0x8048000)
==6859== Warning: set address range perms: large range 285949952, a 0, v 0
==6859== Reading syms from /mnt/nfsroot/lib/ld-2.3.2.so (0x1B8E4000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /home/benny/vg/lib/valgrind/stage2 (0xB0000000)
==6859== Reading syms from /mnt/nfsroot/lib/ld-2.3.2.so (0xB1000000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/libdl-2.3.2.so (0xB1016000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libc-2.3.2.so (0xB1019000)
==6859==    object doesn't have any debug info
==6859== Reading syms from
/home/benny/vg/lib/valgrind/vgskin_memcheck.so (0xB1152000)
==6859== Reading suppressions file: /home/benny/vg/lib/valgrind/default.supp
==6859==
==6859== Reading syms from /home/benny/vg/lib/valgrind/vg_inject.so (0x1B8FD000)
==6859== Reading syms from
/home/benny/vg/lib/valgrind/vgpreload_memcheck.so (0x1B900000)
==6859== Reading syms from /mnt/nfsroot/usr/lib/libstdc++.so.5.0.5 (0x1B918000)
==6859==    object doesn't have a symbol table
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libm-2.3.2.so (0x1B9D1000)
==6859==    object doesn't have any debug info
==6859== Reading syms from
/mnt/nfsroot/lib/libgcc_s-3.3.2-20031023.so.1 (0x1B9F4000)
==6859==    object doesn't have a symbol table
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/tls/libc-2.3.2.so (0x1B9FD000)
==6859==    object doesn't have any debug info
==6859== Reading syms from /mnt/nfsroot/lib/libdl-2.3.2.so (0x1BB39000)
==6859==    object doesn't have any debug info
==6859== TRANSLATE: 0x1BA731D0 redirected to 0x1B9045A8
==6859== TRANSLATE: 0x1B8E4C30 redirected to 0x52BFF020
start
==6859== TRANSLATE: 0x1BA6C080 redirected to 0x1B9034E0
The file has 8 lines
==6859== TRANSLATE: 0x1BA6C200 redirected to 0x1B9039F0
ID is 0
ID 0: Hostname is GD074A
rsh -l benny GD075A "./ad65536 dsmid 1 port 17767 " &
rsh -l benny GD076A "./ad65536 dsmid 2 port 17767 " &
rsh -l benny GD077A "./ad65536 dsmid 3 port 17767 " &
rsh -l benny GD078A "./ad65536 dsmid 4 port 17767 " &
rsh -l benny GD079A "./ad65536 dsmid 5 port 17767 " &
rsh -l benny GD080A "./ad65536 dsmid 6 port 17767 " &
rsh -l benny GD081A "./ad65536 dsmid 7 port 17767 " &
First 0 is 0x8212020
Final 2047 is 0x10212000
End bound is 0x10222020
ID 0: Comm Init Okay
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
maddr[0] is 0x1c7fc028
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
maddr[1] is 0x2c7fe028
==6859== Warning: set address range perms: large range 268435456, a 0, v 1
maddr[2] is 0x3c800028
start
The file has 8 lines
ID is 2
ID 2: Hostname is GD076A
start
The file has 8 lines
ID is 1
ID 1: Hostname is GD075A
start
The file has 8 lines
ID is 3
ID 3: Hostname is GD077A
start
The file has 8 lines
ID is 4
ID 4: Hostname is GD078A
start
The file has 8 lines
ID is 5
ID 5: Hostname is GD079A
start
The file has 8 lines
ID is 6
ID 6: Hostname is GD080A
start
The file has 8 lines
ID is 7
ID 7: Hostname is GD081A
==6859== TRANSLATE: 0x1B9A8600 redirected to 0x1B903881
==6859== TRANSLATE: 0x1B9A6F50 redirected to 0x1B903D08
xbcount = 1, linec = 8, from 0
barr(): now at barrwait
xbcount = 2, linec = 8, from 2
xbcount = 3, linec = 8, from 5
xbcount = 4, linec = 8, from 7
xbcount = 5, linec = 8, from 1
xbcount = 6, linec = 8, from 3
xbcount = 7, linec = 8, from 6
xbcount = 8, linec = 8, from 4
Into barrgrant sending routine
Sending Barrgrant message to 0
Sending Barrgrant message to 1
Sending Barrgrant message to 2
Sending Barrgrant message to 3
Sending Barrgrant message to 4
Sending Barrgrant message to 5
Sending Barrgrant message to 6
Sending Barrgrant message to 7
barr(): barrwait says 0, passed barrier
Debug: Allocating 65536 elements on obj 128, address in object map is 0x1c7fc220
Debug: id = 128, objid = 128, #segment = 16
Debug: first segment address 0x1e7bc028
Debug: Allocating 65536 elements on obj 256, address in object map is 0x1c7fc420
Debug: id = 256, objid = 256, #segment = 16
Debug: first segment address 0x207bc028
Debug: Allocating 65536 elements on obj 384, address in object map is 0x1c7fc620
Debug: id = 384, objid = 384, #segment = 16
Debug: first segment address 0x227bc028
Debug: Allocating 65536 elements on obj 512, address in object map is 0x1c7fc820
Debug: id = 512, objid = 512, #segment = 16
Debug: first segment address 0x247bc028
Debug: Allocating 65536 elements on obj 640, address in object map is 0x1c7fca20
Debug: id = 640, objid = 640, #segment = 16
Debug: first segment address 0x267bc028
Debug: Allocating 65536 elements on obj 768, address in object map is 0x1c7fcc20
Debug: id = 768, objid = 768, #segment = 16
Debug: first segment address 0x287bc028
Debug: Allocating 65536 elements on obj 896, address in object map is 0x1c7fce20
Debug: id = 896, objid = 896, #segment = 16
Debug: first segment address 0x2a7bc028
Segmentation fault
[benny@... benny]$ exit

Script done on Thu 24 Mar 2005 07:48:32 PM HKT

(Using valgrind 2.2.0, the above error does not occur. Or, if my
program allocates
three chunks of 64MB of memory instead of 256MB, the above error does not
occur either with valgrind 2.4.0-rc4).

[Valgrind-users] Re: Newbie Question about Valgrind Address Relocation

From: Benny Cheung <bwlcheung@gm...> - 2005-03-24 18:42

Jeremy Fitzhardinge <jeremy <at> goop.org> writes:

> No, that would print something.  I'm guessing recursive allocation,
> which likely means a leak.

Perhaps it may help if I describe my program a bit.

What my program does is to make use of part of the VM area to act as my
own heap (the allocation of the 256MB big chunks are for this purpose), so that
objects of a particular class C (defined by me) will be stored in that
area instead of
the traditional heap.

C is a class written with type template T, and it serves as a wrapper
for objects of
type T. Thus, by declaring "C<T> obj;" and calls a member function of C, memory
is allocated for the object obj using "T* p = new T;", and then the
memory content
pointed to by p is copied to my designated area using "memcpy", and finally, a
member variable of C is pointed to that piece of designated memory (p is then
freed using "delete"). There are 3 big chunks of memory allocated, since I
want to make 3 copies for different purposes.

The error (SEGV fault without returning to valgrind) happens when I
try to create
many objects to fill my own "heap" area, and it occurs when nearly all objects
(about 16K in total, each 16KB in size) are created and moved to my own "heap".

I am trying to reproduce the same error with a simpler program, but
not succeeded,
instead I find this simple (but use up a lot of virtual memory)
program gets another
error in valgrind 2.4.0, while running fine in 2.2.0. The program is like this:

#include <stdlib.h>
#include <stdio.h>

int main()
{
  void *v, *t, *c;
  int i;
  v = malloc(256 * 1024 * 1024);
  t = malloc(256 * 1024 * 1024);
  c = malloc(256 * 1024 * 1024);
  for (i = 0; i < 64 * 1024 * 1024; i++) {
     *(int *)((unsigned int)v + i * 4) = 123;
     *(int *)((unsigned int)t + i * 4) = 456;
     *(int *)((unsigned int)c + i * 4) = 789;
  }
  printf("Ok\n");
  return 0;
}

And the error in 2.4.0 is:

valgrind: vg_skiplist.c:418 (vgPlain_SkipList_Insert): Assertion `nn
== ((void *)0) || (l->cmp)(key_of_node(l, nn), k) != 0' failed.
==4814==    at 0xB003623E: vgPlain_skin_assert_fail (vg_mylibc.c:1170)
==4814==    by 0xB003623D: assert_fail (vg_mylibc.c:1166)
==4814==    by 0xB0036298: vgPlain_core_assert_fail (vg_mylibc.c:1177)
==4814==    by 0xB004452C: vgPlain_SkipList_Insert (vg_skiplist.c:164)
==4814==    by 0xB0032DA5: vgPlain_map_file_segment (vg_memory.c:394)
==4814==    by 0xB0032F66: vgPlain_map_fd_segment (vg_memory.c:465)
==4814==    by 0xB0034F09: vgPlain_mmap (vg_mylibc.c:313)
==4814==    by 0xB0036E0A: vgPlain_get_memory_from_mmap (vg_mylibc.c:1705)
==4814==    by 0xB0030724: newSuperblock (vg_malloc2.c:479)
==4814==    by 0xB00316D4: vgPlain_arena_malloc (vg_malloc2.c:983)
==4814==    by 0xB004401C: vgPlain_SkipNode_Alloc (vg_skiplist.c:226)
==4814==    by 0xB003270C: vgPlain_split_segment (vg_memory.c:106)

sched status:
 running_tid=1

Thread 1: status = VgTs_Runnable
==4814==    at 0x804840C: main (trybug.cpp:13)

Does valgrind 2.4.0 use up more (virtual) memory than 2.2.0?

Best Regards,
Benny.