|
From: Nicholas N. <nj...@ca...> - 2004-07-20 11:39:32
|
[cc'ing to valgrind-developers list] On Mon, 19 Jul 2004, Kingsley G. Morse Jr. wrote: > Here's a bug report. > > Immediately after installing version 2.1.1-4 of > debian's valgrind package, I typed: > > $ valgrind ls -l > > and got the error message: > > Executable is mapped outside of range 0x80d3000-0x3ffff000 > failed to load /usr/lib/valgrind/stage2: Cannot allocate memory > > Other info: > > $ uname -a > 2.4.19-aa1 (2.4.19 + aa's virtual memory patches) What are aa's virtual memory patches? They are almost certainly causing the problem. Can you send us what you see when you run "vim /proc/self/maps" (or the contents of any smallish /proc/<pid>/maps file)? That would be instructive. Thanks. N |
|
From: Jeremy F. <je...@go...> - 2004-07-20 23:36:16
|
On Tue, 2004-07-20 at 12:39 +0100, Nicholas Nethercote wrote: > What are aa's virtual memory patches? They are almost certainly causing > the problem. Not sure they would be - they're probably more to do with swapping/ paging policy than address space layout, but I'm not sure what Andrea's putting in there these days. > Can you send us what you see when you run "vim /proc/self/maps" (or the > contents of any smallish /proc/<pid>/maps file)? That would be > instructive. Thanks. Also "readelf -lh /bin/ls" would be interesting too. J |
|
From: Kingsley G. M. Jr. <ch...@na...> - 2004-07-21 20:29:49
|
Thanks for suggesting readelf.
I can tell that you're knowledgeable.
On 07/20/04 16:31, Jeremy Fitzhardinge wrote:
> On Tue, 2004-07-20 at 12:39 +0100, Nicholas Nethercote wrote:
> > What are aa's virtual memory patches? They are almost certainly causing
> > the problem.
>
> Not sure they would be - they're probably more to do with swapping/
> paging policy than address space layout, but I'm not sure what Andrea's
> putting in there these days.
For what it's worth, the patches that I applied are from 2002.
> > Can you send us what you see when you run "vim /proc/self/maps" (or the
> > contents of any smallish /proc/<pid>/maps file)? That would be
> > instructive. Thanks.
>
> Also "readelf -lh /bin/ls" would be interesting too.
OK, here it is:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x8049960
Start of program headers: 52 (bytes into file)
Start of section headers: 71460 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 7
Size of section headers: 40 (bytes)
Number of section headers: 25
Section header string table index: 24
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x11248 0x11248 R E 0x1000
LOAD 0x011260 0x0805a260 0x0805a260 0x003e4 0x00790 RW 0x1000
DYNAMIC 0x0113e4 0x0805a3e4 0x0805a3e4 0x000d8 0x000d8 RW 0x4
NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4
GNU_EH_FRAME 0x01121c 0x0805921c 0x0805921c 0x0002c 0x0002c R 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr
03 .data .eh_frame .dynamic .ctors .dtors .jcr .got .bss
04 .dynamic
05 .note.ABI-tag
06 .eh_frame_hdr
Thanks,
Kingsley
|
|
From: Kingsley G. M. Jr. <ch...@na...> - 2004-07-21 20:26:15
|
Thanks for your thoughts. My comments follow...
On 07/20/04 12:39, Nicholas Nethercote wrote:
>
> [cc'ing to valgrind-developers list]
>
> On Mon, 19 Jul 2004, Kingsley G. Morse Jr. wrote:
>
> >Here's a bug report.
> >
> >Immediately after installing version 2.1.1-4 of
> >debian's valgrind package, I typed:
> >
> > $ valgrind ls -l
> >
> >and got the error message:
> >
> > Executable is mapped outside of range 0x80d3000-0x3ffff000
> > failed to load /usr/lib/valgrind/stage2: Cannot allocate memory
> >
> >Other info:
> >
> > $ uname -a
> > 2.4.19-aa1 (2.4.19 + aa's virtual memory patches)
>
> What are aa's virtual memory patches?
Good question.
aa's virtual memory patches were written by Andrea
Arcangeli. They can be reviewed at
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/
> They are almost certainly causing the problem.
>
> Can you send us what you see when you run "vim /proc/self/maps"
OK, here it is:
08048000-08187000 r-xp 00000000 08:02 49498 /usr/bin/vim
08187000-08197000 rw-p 0013f000 08:02 49498 /usr/bin/vim
08197000-08263000 rwxp 00000000 00:00 0
15556000-1556c000 r-xp 00000000 08:02 703842 /lib/ld-2.3.2.so
1556c000-1556d000 rw-p 00015000 08:02 703842 /lib/ld-2.3.2.so
1556d000-1556e000 rw-p 00000000 00:00 0
1556e000-15570000 r-xp 00000000 08:02 33093 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
15570000-15571000 rw-p 00001000 08:02 33093 /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2
15571000-15579000 r-xp 00000000 08:02 704263 /lib/libnss_files-2.3.2.so
15579000-1557a000 rw-p 00008000 08:02 704263 /lib/libnss_files-2.3.2.so
15589000-1584f000 r-xp 00000000 08:02 606274 /usr/lib/libgtk-x11-2.0.so.0.400.3
1584f000-15858000 rw-p 002c5000 08:02 606274 /usr/lib/libgtk-x11-2.0.so.0.400.3
15858000-1585c000 rw-p 00000000 00:00 0
1585c000-158c8000 r-xp 00000000 08:02 605795 /usr/lib/libgdk-x11-2.0.so.0.400.3
158c8000-158cd000 rw-p 0006c000 08:02 605795 /usr/lib/libgdk-x11-2.0.so.0.400.3
158cd000-158e6000 r-xp 00000000 08:02 604457 /usr/lib/libatk-1.0.so.0.600.1
158e6000-158e8000 rw-p 00018000 08:02 604457 /usr/lib/libatk-1.0.so.0.600.1
158e8000-158e9000 rw-p 00000000 00:00 0
158e9000-158fd000 r-xp 00000000 08:02 605398 /usr/lib/libgdk_pixbuf-2.0.so.0.400.3
158fd000-158fe000 rw-p 00014000 08:02 605398 /usr/lib/libgdk_pixbuf-2.0.so.0.400.3
158fe000-1591f000 r-xp 00000000 08:02 704258 /lib/libm-2.3.2.so
1591f000-15920000 rw-p 00020000 08:02 704258 /lib/libm-2.3.2.so
15920000-15924000 r-xp 00000000 08:02 606271 /usr/lib/libpangoxft-1.0.so.0.399.1
15924000-15925000 rw-p 00003000 08:02 606271 /usr/lib/libpangoxft-1.0.so.0.399.1
15925000-15930000 r-xp 00000000 08:02 606270 /usr/lib/libpangox-1.0.so.0.399.1
15930000-15931000 rw-p 0000a000 08:02 606270 /usr/lib/libpangox-1.0.so.0.399.1
15931000-15961000 r-xp 00000000 08:02 603977 /usr/lib/libpango-1.0.so.0.399.1
15961000-15966000 rw-p 0002f000 08:02 603977 /usr/lib/libpango-1.0.so.0.399.1
15966000-1599e000 r-xp 00000000 08:02 606264 /usr/lib/libgobject-2.0.so.0.400.2
1599e000-1599f000 rw-p 00037000 08:02 606264 /usr/lib/libgobject-2.0.so.0.400.2
1599f000-159a1000 rw-p 00000000 00:00 0
159a1000-159a4000 r-xp 00000000 08:02 606266 /usr/lib/libgmodule-2.0.so.0.400.2
159a4000-159a5000 rw-p 00002000 08:02 606266 /usr/lib/libgmodule-2.0.so.0.400.2
159a5000-159a7000 r-xp 00000000 08:02 704257 /lib/libdl-2.3.2.so
159a7000-159a8000 rw-p 00002000 08:02 704257 /lib/libdl-2.3.2.so
159a8000-15a25000 r-xp 00000000 08:02 606263 /usr/lib/libglib-2.0.so.0.400.2
15a25000-15a26000 rw-p 0007d000 08:02 606263 /usr/lib/libglib-2.0.so.0.400.2
15a26000-15a73000 r-xp 00000000 08:02 489999 /usr/X11R6/lib/libXt.so.6.0
15a73000-15a76000 rw-p 0004d000 08:02 489999 /usr/X11R6/lib/libXt.so.6.0
15a76000-15a77000 rw-p 00000000 00:00 0
15a77000-15aad000 r-xp 00000000 08:02 702605 /lib/libncurses.so.5.4
15aad000-15ab6000 rw-p 00035000 08:02 702605 /lib/libncurses.so.5.4
15ab6000-15abb000 r-xp 00000000 08:02 605177 /usr/lib/libgpm.so.1.19.6
15abb000-15abc000 rw-p 00004000 08:02 605177 /usr/lib/libgpm.so.1.19.6
15abc000-15abd000 rw-p 00000000 00:00 0
15abd000-15be5000 r-xp 00000000 08:02 704255 /lib/libc-2.3.2.so
15be5000-15bed000 rw-p 00127000 08:02 704255 /lib/libc-2.3.2.so
15bed000-15bf0000 rw-p 00000000 00:00 0
15bf0000-15cb4000 r-xp 00000000 08:02 490820 /usr/X11R6/lib/libX11.so.6.2
15cb4000-15cb7000 rw-p 000c4000 08:02 490820 /usr/X11R6/lib/libX11.so.6.2
15cb7000-15cbf000 r-xp 00000000 08:02 489855 /usr/X11R6/lib/libSM.so.6.0
15cbf000-15cc0000 rw-p 00007000 08:02 489855 /usr/X11R6/lib/libSM.so.6.0
15cc0000-15cd4000 r-xp 00000000 08:02 491237 /usr/X11R6/lib/libICE.so.6.3
15cd4000-15cd5000 rw-p 00013000 08:02 491237 /usr/X11R6/lib/libICE.so.6.3
15cd5000-15cd7000 rw-p 00000000 00:00 0
15cd7000-15cda000 r-xp 00000000 08:02 490025 /usr/X11R6/lib/libXrandr.so.2.0
15cda000-15cdb000 rw-p 00002000 08:02 490025 /usr/X11R6/lib/libXrandr.so.2.0
15cdb000-15ce2000 r-xp 00000000 08:02 489980 /usr/X11R6/lib/libXi.so.6.0
15ce2000-15ce3000 rw-p 00006000 08:02 489980 /usr/X11R6/lib/libXi.so.6.0
15ce3000-15ce4000 rw-p 00000000 00:00 0
15ce4000-15cf1000 r-xp 00000000 08:02 489890 /usr/X11R6/lib/libXext.so.6.4
15cf1000-15cf2000 rw-p 0000c000 08:02 489890 /usr/X11R6/lib/libXext.so.6.4
15cf2000-15d02000 r-xp 00000000 08:02 490090 /usr/X11R6/lib/libXft.so.2.1.1
15d02000-15d03000 rw-p 0000f000 08:02 490090 /usr/X11R6/lib/libXft.so.2.1.1
15d03000-15d66000 r-xp 00000000 08:02 605369 /usr/lib/libfreetype.so.6.3.4
15d66000-15d6d000 rw-p 00063000 08:02 605369 /usr/lib/libfreetype.so.6.3.4
15d6d000-15d7d000 r-xp 00000000 08:02 605352 /usr/lib/libz.so.1.2.1
15d7d000-15d7e000 rw-p 00010000 08:02 605352 /usr/lib/libz.so.1.2.1
15d7e000-15d9f000 r-xp 00000000 08:02 604952 /usr/lib/libfontconfig.so.1.0.4
15d9f000-15da3000 rw-p 00020000 08:02 604952 /usr/lib/libfontconfig.so.1.0.4
15da3000-15dab000 r-xp 00000000 08:02 603978 /usr/lib/libXcursor.so.1.0.2
15dab000-15dac000 rw-p 00007000 08:02 603978 /usr/lib/libXcursor.so.1.0.2
15dac000-15dad000 rw-p 00000000 00:00 0
15dad000-15db4000 r-xp 00000000 08:02 603974 /usr/lib/libXrender.so.1.2.2
15db4000-15db5000 rw-p 00006000 08:02 603974 /usr/lib/libXrender.so.1.2.2
15db5000-15dd9000 r-xp 00000000 08:02 606272 /usr/lib/libpangoft2-1.0.so.0.399.1
15dd9000-15dda000 rw-p 00024000 08:02 606272 /usr/lib/libpangoft2-1.0.so.0.399.1
15dda000-15df4000 r-xp 00000000 08:02 604890 /usr/lib/libexpat.so.1.0.0
15df4000-15df8000 rw-p 0001a000 08:02 604890 /usr/lib/libexpat.so.1.0.0
15df8000-15df9000 rw-p 00000000 00:00 0
3fff7000-40000000 rwxp ffff8000 00:00 0
Thanks,
Kingsley
--
|
|
From: Jeremy F. <je...@go...> - 2004-07-21 23:27:03
|
On Wed, 2004-07-21 at 13:26 -0700, Kingsley G. Morse Jr. wrote: > 3fff7000-40000000 rwxp ffff8000 00:00 0 Ah, are you using a 1G:3G user:kernel address space split? At present, Valgrind will only work with a 3:1 split (though it should be possible to tweak fairly easily). J |
|
From: Kingsley G. M. Jr. <ch...@na...> - 2004-07-22 23:57:48
|
Thanks for the reply. It inspired me to research with Google. On 07/21/04 16:23, Jeremy Fitzhardinge wrote: > On Wed, 2004-07-21 at 13:26 -0700, Kingsley G. Morse Jr. wrote: > > 3fff7000-40000000 rwxp ffff8000 00:00 0 > > Ah, are you using a 1G:3G user:kernel address space split? How can I check? Thanks, Kingsley |
|
From: Jeremy F. <je...@go...> - 2004-07-23 00:18:21
|
On Thu, 2004-07-22 at 16:57 -0700, Kingsley G. Morse Jr. wrote: > Thanks for the reply. > > It inspired me to research with Google. > > On 07/21/04 16:23, Jeremy Fitzhardinge wrote: > > On Wed, 2004-07-21 at 13:26 -0700, Kingsley G. Morse Jr. wrote: > > > 3fff7000-40000000 rwxp ffff8000 00:00 0 > > > > Ah, are you using a 1G:3G user:kernel address space split? > > How can I check? Well, it's a kernel build option, so look there first. If not dmesg probably has a clue. But the fact that your process stack top is at 40000000 is a pretty good hint too. J |
|
From: Kingsley G. M. Jr. <ch...@na...> - 2004-07-23 19:37:46
|
On 07/22/04 17:15, Jeremy Fitzhardinge wrote: > On Thu, 2004-07-22 at 16:57 -0700, Kingsley G. > Morse Jr. wrote: > > Thanks for the reply. > > > > It inspired me to research with Google. > > > > On 07/21/04 16:23, Jeremy Fitzhardinge wrote: > > > On Wed, 2004-07-21 at 13:26 -0700, Kingsley > > > G. Morse Jr. wrote: > > > > 3fff7000-40000000 rwxp ffff8000 00:00 > > > > 0 > > > > > > Ah, are you using a 1G:3G user:kernel > > > address space split? > > > > How can I check? > > Well, it's a kernel build option, so look there > first. If not dmesg probably has a clue. Yes, and, if I recall correctly, I found through Google that there was evidently a patch for kernel 2.4.(23?) that added it as a configuration option. However, unless I overlooked it, neither "make xconfig" or "dmesg" revealed such an option for my 2.4.19-aa kernel. <sigh> Cheers, Kingsley -- |
|
From: Nicholas N. <nj...@ca...> - 2004-07-25 12:33:35
|
On Fri, 23 Jul 2004, Kingsley G. Morse Jr. wrote:
>>>> Ah, are you using a 1G:3G user:kernel
>>>> address space split?
>>>
>>> How can I check?
>>
>> Well, it's a kernel build option, so look there
>> first. If not dmesg probably has a clue.
>
> Yes, and, if I recall correctly, I found through
> Google that there was evidently a patch for kernel
> 2.4.(23?) that added it as a configuration option.
>
> However, unless I overlooked it, neither "make
> xconfig" or "dmesg" revealed such an option for my
> 2.4.19-aa kernel.
Assuming you have a 1G:3G user:kernel split, you could try the patch for
coregrind/Makefile below (against 2.1.2 or the CVS HEAD; apply patch to
an already-built Valgrind, then re-build) which restricts everything to be
in the first 1G. It didn't work for me -- there was an error trying to
load shared libraries above 0x30000000 -- but it might work on your
system. If it does work on your system, it's likely you won't be able to
valgrind any very large programs, because there is so little user-space
memory available.
HTH
N
*** 178,182 ****
stage2_DEPENDENCIES = $(srcdir)/valgrind.vs x86/stage2.lds
stage2_LDFLAGS = -Wl,--export-dynamic -Wl,-e,_ume_entry -g \
! -Wl,-defsym,kickstart_base=0x30000000 \
-Wl,-T,x86/stage2.lds \
-Wl,-version-script $(srcdir)/valgrind.vs
--- 178,182 ----
stage2_DEPENDENCIES = $(srcdir)/valgrind.vs x86/stage2.lds
stage2_LDFLAGS = -Wl,--export-dynamic -Wl,-e,_ume_entry -g \
! -Wl,-defsym,kickstart_base=0xb0000000 \
-Wl,-T,x86/stage2.lds \
-Wl,-version-script $(srcdir)/valgrind.vs
|