|
From: Christoph B. <bar...@or...> - 2005-07-19 08:31:32
|
Hi, is there a memory limit on the AMD64 in the current development branch of valgrind? I have an application which tries to load code (I guess via dlopen) and complains about not enough memory. [DCL-187]: (E) Failed to load DCM < /fs/data/asiclibs/tech/lin64opt>, msg=< /fs/data/asiclibs/tech/lin64opt: failed to map segment from shared object: Cannot allocate memory>. The process has at that time around 7.8 GB allocated. The machine has 64GB. Additionally the log file says. ------------------------------------------------------------------------------------------- valgrind: syswrap-main.c:658 (vgPlain_client_syscall): Assertion 'eq_SyscallArgs(&sci->args, &sci->orig_args)' failed. 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: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ----------------------------------------------------------------------------------- But I guess this is a message which is issued after the loading fails. Greets, Christoph Bartoschek |
|
From: Tom H. <to...@co...> - 2005-07-19 09:02:32
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> is there a memory limit on the AMD64 in the current development branch of
> valgrind? I have an application which tries to load code (I guess via dlopen)
> and complains about not enough memory.
Unfortunately there is, yes. In fact there tends to be less address
space available on AMD64 than on x86 because of limitations on what
address we can load valgrind at.
We do have a plan to fix this so that the address space does not have
to be rigidly partitioned between valgrind space and client space.
> Additionally the log file says.
> -------------------------------------------------------------------------------------------
> valgrind: syswrap-main.c:658 (vgPlain_client_syscall): Assertion
> 'eq_SyscallArgs(&sci->args, &sci->orig_args)' failed.
That's a bit nasty. Can you run with --trace-syscalls=yes and see
what the last system call it executed before that assertion was?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christoph B. <bar...@or...> - 2005-07-19 09:13:30
|
Am Dienstag 19 Juli 2005 11:02 schrieb Tom Hughes: > Unfortunately there is, yes. In fact there tends to be less address > space available on AMD64 than on x86 because of limitations on what > address we can load valgrind at. Hmm, less than on x86? An AMD64 port is fairly useless for me if it cannot run programms which require about 15GB. Greets, Christoph Bartoschek |
|
From: Tom H. <to...@co...> - 2005-07-19 09:25:12
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
> Am Dienstag 19 Juli 2005 11:02 schrieb Tom Hughes:
>> Unfortunately there is, yes. In fact there tends to be less address
>> space available on AMD64 than on x86 because of limitations on what
>> address we can load valgrind at.
>
>
> Hmm, less than on x86? An AMD64 port is fairly useless for me if it cannot
> run programms which require about 15GB.
Yes, valgrind has to load below 0x80000000 because of limitations on
which code models the toolchain supports. On x86 we load it as close
to the kernel as we can, and typically around 0xb0000000 or so.
The current scheme partitions the memory space so that everything
below the valgrind binary is for the client and everything above it
for valgrind.
The plan is to break the memory up into chunks instead which each
chunk being either a client chunk or a valgrind chunk. That way the
entire address space will be available.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-07-19 10:03:17
|
> Christoph Bartoschek <bar...@or...> wrote: > > Am Dienstag 19 Juli 2005 11:02 schrieb Tom Hughes: > >> Unfortunately there is, yes. In fact there tends to be less address > >> space available on AMD64 than on x86 because of limitations on what > >> address we can load valgrind at. > > > > Hmm, less than on x86? An AMD64 port is fairly useless for me if it > > cannot run programms which require about 15GB. > The plan is to break the memory up into chunks instead which each > chunk being either a client chunk or a valgrind chunk. That way the > entire address space will be available. Christoph Of course this is a limitation we're very aware of. As Tom says there is a plan to get rid of it. But our time is limited and rewriting the address space manager so it works well for both 32- and 64-bit platforms is a difficult and complicated exercise, and it hasn't happened yet. I hope to get to it in the next couple of months if nobody beats me to it. J |
|
From: Christoph B. <bar...@or...> - 2005-07-19 12:07:39
|
> That's a bit nasty. Can you run with --trace-syscalls=yes and see > what the last system call it executed before that assertion was? Here is the output for with --trace-syscalls=yes SYSCALL[13897,1]( 2) ... [async] --> Failure(0x2) SYSCALL[13897,1]( 2) sys_open ( 0x1191170D(/etc/ld.so.cache), 0 ) --> [async] ... SYSCALL[13897,1]( 2) ... [async] --> Success(0x8) SYSCALL[13897,1]( 5) sys_newfstat ( 8, 0x349F77B0 )[sync] --> Success(0x0) SYSCALL[13897,1]( 9) sys_mmap2 ( 0x0, 137887, 1, 2, 8, 0 )[sync] --> Success(0x34903000) SYSCALL[13897,1]( 3) sys_close ( 8 )[sync] --> Success(0x0) SYSCALL[13897,1]( 2) sys_open ( 0x349236F6(/usr/X11R6/lib64/libXcursor.so.1), 0 ) --> [async] ... SYSCALL[13897,1]( 2) ... [async] --> Success(0x8) SYSCALL[13897,1]( 0) sys_read ( 8, 0x349F7918, 640 ) --> [async] ... SYSCALL[13897,1]( 0) ... [async] --> Success(0x280) SYSCALL[13897,1]( 5) sys_newfstat ( 8, 0x349F77F0 )[sync] --> Success(0x0) SYSCALL[13897,1]( 9) sys_mmap2 ( 0x31D9A00000, 1087432, 5, 2050, 8, 0 ) --> [pre-fail] Failure(0xC) valgrind: syswrap-main.c:660 (vgPlain_client_syscall): Assertion 'eq_SyscallArgs(&sci->args, &sci->orig_args)' failed. ... Christoph Bartoschek |
|
From: Tom H. <to...@co...> - 2005-07-19 13:04:18
|
In message <200...@or...>
Christoph Bartoschek <bar...@or...> wrote:
>> That's a bit nasty. Can you run with --trace-syscalls=yes and see
>> what the last system call it executed before that assertion was?
>
> Here is the output for with --trace-syscalls=yes
>
> SYSCALL[13897,1]( 9) sys_mmap2 ( 0x31D9A00000, 1087432, 5, 2050, 8, 0 ) -->
> [pre-fail] Failure(0xC)
>
> valgrind: syswrap-main.c:660 (vgPlain_client_syscall): Assertion
> 'eq_SyscallArgs(&sci->args, &sci->orig_args)' failed.
The pre-handler for mmap2 was corrupting the arguments when it
returned a failure which it shouldn't do. I've committed a fix
for it now.
The
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|