|
From: Benny C. <bwl...@gm...> - 2005-03-20 13:42:44
|
Dear all, 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(). 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? Thanks in advance. Best Regards, Benny. |
|
From: Tom H. <to...@co...> - 2005-03-20 14:52:37
|
In message <loo...@po...>
Benny Cheung <bwl...@gm...> 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 (to...@co...)
http://www.compton.nu/
|
|
From: Benny C. <bwl...@gm...> - 2005-03-20 16:22:02
|
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. |
|
From: Julian S. <js...@ac...> - 2005-03-21 12:05:13
|
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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Benny C. <bwl...@gm...> - 2005-03-22 03:59:31
|
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@@GLIBC_2.1 (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@@GLIBC_2.1 (in /mnt/nfsroot/lib/tls/libc-2.3.2.so) ==5504== by 0x1BA5AF38: _IO_fclose@@GLIBC_2.1 (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. |
|
From: Tom H. <to...@co...> - 2005-03-22 07:13:12
|
In message <loo...@po...>
Benny Cheung <bwl...@gm...> 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 (to...@co...)
http://www.compton.nu/
|
|
From: Benny C. <bwl...@gm...> - 2005-03-22 08:51:04
|
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. |
|
From: Jeremy F. <je...@go...> - 2005-03-22 17:46:07
|
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
|
|
From: Benny C. <bwl...@gm...> - 2005-03-24 12:26:01
|
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 (bhc...@da...) (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 |
|
From: Nicholas N. <nj...@cs...> - 2005-03-24 14:10:18
|
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 www.valgrind.org/support/bug_reports.html). Jeremy, I wonder if it's a problem with the secondary map changes? N |
|
From: Jeremy F. <je...@go...> - 2005-03-24 17:22:14
|
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
|
|
From: Benny C. <bwl...@gm...> - 2005-03-24 18:42:18
|
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. |
|
From: Benny C. <bwl...@gm...> - 2005-03-24 18:33:13
|
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 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@GD074 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 (bhc...@da...) (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@GD074 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). |