|
From: Tom H. <to...@co...> - 2005-11-07 19:14:46
|
The SVN version of valgrind now has support for running 32 bit x86 binaries on amd64 systems - when valgrind is built on amd64 it will build with support for both x86 and amd64 binaries so that it can run both 32 bit and 64 bit programs. The correct tool should be selected automatically including when a 32 bit program is exec'ed from a 64 bit program or vice versa and the --trace-children=yes flag is used to cause valgrind to trace the new program. Please do try it out if you want and let us know on the mailing lists or by filing a bug on the bug tracker if you encounter any problems. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Daniel V. <vei...@re...> - 2005-11-07 22:45:38
|
On Mon, Nov 07, 2005 at 07:14:40PM +0000, Tom Hughes wrote: > The SVN version of valgrind now has support for running 32 bit x86 > binaries on amd64 systems Cool ! Out of curiosity, do you make use of the extra registers to speed up emulation ? Daniel -- Daniel Veillard | Red Hat http://redhat.com/ vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
|
From: Tom H. <to...@co...> - 2005-11-07 23:27:27
|
In message <200...@re...>
Daniel Veillard <vei...@re...> wrote:
> On Mon, Nov 07, 2005 at 07:14:40PM +0000, Tom Hughes wrote:
> > The SVN version of valgrind now has support for running 32 bit x86
> > binaries on amd64 systems
>
> Cool ! Out of curiosity, do you make use of the extra registers to
> speed up emulation ?
No - the x86 code is handled using tools that were compiled to target
x86 just as if you had built valgrind on a 32 bit machine.
Ideally we would do what you suggest and build a 64 bit binary that
ran 32 bit code but that is rather harder - this way was the easy way
at least as a first step.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-11-07 23:49:35
|
On Monday 07 November 2005 22:45, Daniel Veillard wrote: > On Mon, Nov 07, 2005 at 07:14:40PM +0000, Tom Hughes wrote: > > The SVN version of valgrind now has support for running 32 bit x86 > > binaries on amd64 systems > > Cool ! Out of curiosity, do you make use of the extra registers to > speed up emulation ? No - we have enough complication as it is without doing cross-arch simulation :-) Besides, one of the things that is apparent from the ppc32 port is that having a lot of registers on the host does not seem to make difference in performance, because the live ranges are not long enough to use them all. It's much more important for the guest architecture to have a lot of registers, because having more registers means fewer spills, and since each spill is a memory transaction that memcheck/cachegrind has to track, spills on the guest are expensive. J |
|
From: Daniel V. <vei...@re...> - 2005-11-08 12:01:13
|
On Mon, Nov 07, 2005 at 11:54:00PM +0000, Julian Seward wrote:
> On Monday 07 November 2005 22:45, Daniel Veillard wrote:
> > On Mon, Nov 07, 2005 at 07:14:40PM +0000, Tom Hughes wrote:
> > > The SVN version of valgrind now has support for running 32 bit x86
> > > binaries on amd64 systems
> >
> > Cool ! Out of curiosity, do you make use of the extra registers to
> > speed up emulation ?
>
> No - we have enough complication as it is without doing cross-arch
> simulation :-) Besides, one of the things that is apparent from the
> ppc32 port is that having a lot of registers on the host does not
> seem to make difference in performance, because the live ranges are
> not long enough to use them all. It's much more important for the
> guest architecture to have a lot of registers, because having more
> registers means fewer spills, and since each spill is a memory
> transaction that memcheck/cachegrind has to track, spills on the
> guest are expensive.
Hummm, okay ! This makes sense,
thanks a lot !
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
|
From: Julian S. <js...@ac...> - 2005-11-07 23:51:35
|
> Please do try it out if you want and let us know on the mailing lists > or by filing a bug on the bug tracker if you encounter any problems. In particular, we would be interested to hear about amd64-linux setups where you only have a 64-bit toolchain and 32-bit is not supported -- does it work in that situation? J |
|
From: Paul P. <ppl...@gm...> - 2005-11-12 09:53:18
|
On 11/7/05, Tom Hughes <to...@co...> wrote:
>
> The SVN version of valgrind now has support for running 32 bit x86
Just checked out: VG 5092, VEX 1450
Please do try it out if you want and let us know on the mailing lists
> or by filing a bug on the bug tracker if you encounter any problems.
64-bit version appears to work fine, but 32-bit exe crashes right away:
$ echo "int main() { return 0; }" > junk.c
$ gcc -m32 -g junk.c && ./a.out && /usr/local/valgrind-3.0.svn/bin/valgrind
-v ./a.out
=3D=3D26864=3D=3D Memcheck, a memory error detector.
=3D=3D26864=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward =
et al.
=3D=3D26864=3D=3D Using LibVEX rev 1450, a library for dynamic binary trans=
lation.
=3D=3D26864=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
=3D=3D26864=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation
framework.
=3D=3D26864=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward =
et al.
=3D=3D26864=3D=3D
--26864-- Valgrind library directory: /usr/local/valgrind-3.0.svn
/lib/valgrind
--26864-- Command line
--26864-- ./a.out
--26864-- Startup, with flags:
--26864-- -v
--26864-- Contents of /proc/version:
--26864-- Linux version 2.4.21-15.ELsmp (bhc...@th...)
(gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)) #1 SMP Thu Apr 22
00:09:01 EDT 2004
--26864-- Reading syms from /tmp/a.out (0x8048000)
--26864-- Reading syms from /lib/ld-2.3.2.so <http://2.3.2.so> (0x4EACB000)
--26864-- Reading syms from
/usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
(0x70000000)
--26864-- object doesn't have a dynamic symbol table
--26864-- Reading suppressions file: /usr/local/valgrind-3.0.svn
/lib/valgrind/default.supp
=3D=3D26864=3D=3D
=3D=3D26864=3D=3D Process terminating with default action of signal 11 (SIG=
SEGV)
=3D=3D26864=3D=3D at 0x4EACE253: process_envvars (in /lib/ld-2.3.2.so<http:=
//2.3.2.so>
)
=3D=3D26864=3D=3D by 0x4EACC208: dl_main (in /lib/ld-2.3.2.so <http://2.3.2=
.so>)
=3D=3D26864=3D=3D by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http=
://2.3.2.so>
)
=3D=3D26864=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3=
.2.so>)
=3D=3D26864=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>=
)
=3D=3D26864=3D=3D
=3D=3D26864=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 fr=
om 0)
=3D=3D26864=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D26864=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D26864=3D=3D
=3D=3D26864=3D=3D No malloc'd blocks -- no leaks are possible.
--26864-- memcheck: sanity checks: 0 cheap, 1 expensive
--26864-- memcheck: auxmaps: 0 auxmap entries (0k, 0M) in use
--26864-- memcheck: auxmaps: 0 searches, 0 comparisons
--26864-- memcheck: secondaries: 5 issued (320k, 0M)
--26864-- memcheck: secondaries: 1 accessible and distinguished (64k, 0M)
--26864-- tt/tc: 178 tt lookups requiring 177 probes
--26864-- tt/tc: 178 fast-cache updates, 2 flushes
--26864-- translate: new 89 (1,981 -> 28,781; ratio 145:10) [0 scs]
--26864-- translate: dumped 0 (0 -> ??)
--26864-- translate: discarded 0 (0 -> ??)
--26864-- scheduler: 190 jumps (bb entries).
--26864-- scheduler: 0/92 major/minor sched events.
--26864-- sanity: 1 cheap, 1 expensive checks.
--26864-- exectx: 30,011 lists, 0 contexts (avg 0 per list)
--26864-- exectx: 0 searches, 0 full compares (0 per 1000)
--26864-- exectx: 0 cmp2, 0 cmp4, 0 cmpAll
Segmentation fault
$
This is unmodified
Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
|
|
From: Tom H. <to...@co...> - 2005-11-12 17:41:05
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> ==29870== Process terminating with default action of signal 11 (SIGSEGV)
> ==29870== at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870== by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http://2.3.2.so>
> )
> ==29870== by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870== by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870==
>
>
> Is that using glibc-2.3.2-95.20.i686.rpm or a later update?
>
>
> $ rpm -qf /lib/ld-2.3.2.so <http://2.3.2.so>
> glibc-2.3.2-95.20
>
> Also, I tried to see if I can debug core. Default "ulimit -c" is zero;
> setting it to unlimited changes the message:
> ==29946== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
>
> but no core* is produced :(
That is a core dump of the client program so will be a vgcore* file.
> Attaching to program: /proc/30077/fd/1014, process 30077
> 0x4eacc1ec in ?? ()
> (gdb) x/i $pc
> 0x4eacc1ec: mov %ecx,(%esp)
> (gdb) x/x $esp
> 0xfef12ec0: Cannot access memory at address 0xfef12ec0
> (gdb) shell cat /proc/30077/maps
> 0000000004000000-000000000435a000 rwxp 0000000000000000 00:00 0
> 000000000435a000-000000000435c000 ---p 000000000035a000 00:00 0
> 000000000435c000-000000000436c000 rwxp 000000000035c000 00:00 0
> 000000000436c000-000000000436e000 ---p 000000000036c000 00:00 0
> 000000000436e000-000000000437e000 rwxp 0000000000000000 00:00 0
> 0000000004577000-0000000005f69000 rwxp 0000000000000000 00:00 0
> 0000000008048000-0000000008049000 r-xp 0000000000000000 03:41 200779
> /tmp/a.out
> 0000000008049000-000000000804a000 rwxp 0000000000000000 03:41 200779
> /tmp/a.out
> 000000000804a000-000000000804b000 rwxp 0000000000000000 00:00 0
> 000000004eacb000-000000004eae0000 r-xp 0000000000000000 03:41 510225
> /lib/ld-2.3.2.so <http://2.3.2.so>
> 000000004eae0000-000000004eae1000 rwxp 0000000000014000 03:41 510225
> /lib/ld-2.3.2.so <http://2.3.2.so>
> 0000000070000000-0000000070135000 r-xp 0000000000000000 03:41 772191
> /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
> 0000000070135000-0000000070136000 rwxp 0000000000135000 03:41 772191
> /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
> 0000000070136000-00000000707c2000 rwxp 0000000000000000 00:00 0
> 00000000fef13000-00000000fef14000 rwxp 0000000000000000 00:00 0
> 00000000fff13000-00000000ffffe000 rw-p fffffffffff16000 00:00 0
> (gdb) quit
> ==30076==
> ==30076== Debugger has detached. Valgrind regains control. We continue.
> ==30076==
> ==30076== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==30076== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==30076== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==30076== For counts of detected errors, rerun with: -v
> ==30076== No malloc'd blocks -- no leaks are possible.
> Segmentation fault
>
> Hmm; %esp is just below the stack page, and the kernel refuses to grow
> stack?
That's the original kernel supplied stack though isn't it? and we
shouldn't be giving that to the client program - we allocate a new
stack for that.
> In fact, increasing environment size moves the place where it coredumps,
> and invreasing it sufficiently makes it run:
Interesting. I'll have a play with that. Any idea roughly what
sizes of environment cause a problem?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-12 17:49:28
|
In message <7c7...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <2a2...@ma...>
> Paul Pluzhnikov <ppl...@gm...> wrote:
>
> > Hmm; %esp is just below the stack page, and the kernel refuses to grow
> > stack?
>
> That's the original kernel supplied stack though isn't it? and we
> shouldn't be giving that to the client program - we allocate a new
> stack for that.
Actually that address does look about right for the stack we
allocate - it's slightly higher on my machine but not much.
Can you run with --trace-signals=yes and see what it says?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-11-12 17:57:33
|
On 11/12/05, Tom Hughes <to...@co...> wrote: > > > Actually that address does look about right for the stack we > allocate - it's slightly higher on my machine but not much. > > Can you run with --trace-signals=3Dyes and see what it says? $ /usr/local/valgrind-3.0.svn/bin/valgrind -q --trace-signals=3Dyes ./a.out --30170-- Max kernel-supported signal is 64 --30170-- signal 11 arrived ... si_code=3D196609, EIP=3D0x4EACC1EC, eip=3D0x477DC95 --30170-- SIGSEGV: si_code=3D196609 faultaddr=3D0xFEF88EC0 tid=3D1 ESP=3D0x= FEF88EC0 seg=3D0xFE78A000-0xFEF88FFF --30170-- delivering signal 11 (SIGSEGV):196609 to thread 1 --30170-- delivering 11 (code 196609) to default handler; action: terminate+core =3D=3D30170=3D=3D =3D=3D30170=3D=3D Process terminating with default action of signal 11 (SIG= SEGV): dumping core =3D=3D30170=3D=3D at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2= .so>) =3D=3D30170=3D=3D by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http= ://2.3.2.so> ) =3D=3D30170=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3= .2.so>) =3D=3D30170=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>= ) Segmentation fault > Any idea roughly what sizes of environment cause a problem? $ env | wc -c 2771 $ PATH=3D$PATH:$PATH env | wc -c 3342 $ PATH=3D$PATH:$PATH:$PATH env | wc -c 3913 Cheers, |
|
From: Tom H. <to...@co...> - 2005-11-12 18:44:15
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> On 11/12/05, Tom Hughes <to...@co...> wrote:
>
> > Actually that address does look about right for the stack we
> > allocate - it's slightly higher on my machine but not much.
> >
> > Can you run with --trace-signals=yes and see what it says?
>
> $ /usr/local/valgrind-3.0.svn/bin/valgrind -q --trace-signals=yes ./a.out
> --30170-- Max kernel-supported signal is 64
> --30170-- signal 11 arrived ... si_code=196609, EIP=0x4EACC1EC,
> eip=0x477DC95
> --30170-- SIGSEGV: si_code=196609 faultaddr=0xFEF88EC0 tid=1 ESP=0xFEF88EC0
> seg=0xFE78A000-0xFEF88FFF
The si_code value is bogus (0x30001) so it doesn't realise it
needs to extend the stack. This is the bug we discussed on the
developer list last night but we thought it was a ppc specific
bug. Obviously it affects all 2.4 kernels of a certain vintage.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-11-12 18:50:51
Attachments:
valgrind-sicode.patch
|
In message <414...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <2a2...@ma...>
> Paul Pluzhnikov <ppl...@gm...> wrote:
>
> > $ /usr/local/valgrind-3.0.svn/bin/valgrind -q --trace-signals=yes ./a.out
> > --30170-- Max kernel-supported signal is 64
> > --30170-- signal 11 arrived ... si_code=196609, EIP=0x4EACC1EC,
> > eip=0x477DC95
> > --30170-- SIGSEGV: si_code=196609 faultaddr=0xFEF88EC0 tid=1 ESP=0xFEF88EC0
> > seg=0xFE78A000-0xFEF88FFF
>
> The si_code value is bogus (0x30001) so it doesn't realise it
> needs to extend the stack. This is the bug we discussed on the
> developer list last night but we thought it was a ppc specific
> bug. Obviously it affects all 2.4 kernels of a certain vintage.
Try this patch - it tweaks our signal handlers to discard anything
in the top half of the si_code value on linux as the kernel is
supposed to have masked that off already.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Paul P. <ppl...@gm...> - 2005-11-12 19:57:36
|
On 11/12/05, Tom Hughes <to...@co...> wrote: > > > Try this patch That fixes it :) --10895-- Max kernel-supported signal is 64 --10895-- signal 11 arrived ... si_code=3D1, EIP=3D0x4EACC1EC, eip=3D0x477D= E15 --10895-- SIGSEGV: si_code=3D1 faultaddr=3D0xFEFCBEA0 tid=3D1 ESP=3D0xFEFCB= EA0 seg=3D0xFE7CD000-0xFEFCBFFF --10895-- -> extended stack base to 0xFEFCB000 ... Cheers, |
|
From: Paul P. <ppl...@gm...> - 2005-11-13 00:10:13
|
On 11/12/05, Tom Hughes <to...@co...> wrote: > > In message <2a2...@ma...> > you wrote: > > I wonder if the environment we construct is dodgy. Not sure. The error has moved a little bit today: =3D=3D29870=3D=3D Process terminating with default action of signal 11 (SIG= SEGV) =3D=3D29870=3D=3D at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2= .so>) =3D=3D29870=3D=3D by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http= ://2.3.2.so> ) =3D=3D29870=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3= .2.so>) =3D=3D29870=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>= ) =3D=3D29870=3D=3D Is that using glibc-2.3.2-95.20.i686.rpm or a later update? $ rpm -qf /lib/ld-2.3.2.so <http://2.3.2.so> glibc-2.3.2-95.20 Also, I tried to see if I can debug core. Default "ulimit -c" is zero; setting it to unlimited changes the message: =3D=3D29946=3D=3D Process terminating with default action of signal 11 (SIG= SEGV): dumping core but no core* is produced :( I had better luck with --db-attach though: $ /usr/local/valgrind-3.0.svn/bin/valgrind --trace-syscalls=3Dyes --db-attach=3Dyes --db-command=3D"/usr/bin/gdb -q %f %p" ./a.out =3D=3D30076=3D=3D Memcheck, a memory error detector. =3D=3D30076=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D30076=3D=3D Using LibVEX rev 1450, a library for dynamic binary trans= lation. =3D=3D30076=3D=3D Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. =3D=3D30076=3D=3D Using valgrind-3.1.SVN, a dynamic binary instrumentation framework. =3D=3D30076=3D=3D Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward = et al. =3D=3D30076=3D=3D For more details, rerun with: -v =3D=3D30076=3D=3D SYSCALL[30076,1](122) sys_newuname ( 0xFEF130A4 )[sync] --> Success(0x0) SYSCALL[30076,1]( 45) sys_brk ( 0x0 ) --> [pre-success] Success(0x804A000) =3D=3D30076=3D=3D =3D=3D30076=3D=3D Process terminating with default action of signal 11 (SIG= SEGV): dumping core =3D=3D30076=3D=3D at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2= .so>) =3D=3D30076=3D=3D by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http= ://2.3.2.so> ) =3D=3D30076=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3= .2.so>) =3D=3D30076=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>= ) =3D=3D30076=3D=3D =3D=3D30076=3D=3D ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- Y =3D=3D30076=3D=3D starting debugger with cmd: /usr/bin/gdb -q /proc/30077/f= d/1014 30077 Using host libthread_db library "/lib64/tls/libthread_db.so.1". Attaching to program: /proc/30077/fd/1014, process 30077 0x4eacc1ec in ?? () (gdb) x/i $pc 0x4eacc1ec: mov %ecx,(%esp) (gdb) x/x $esp 0xfef12ec0: Cannot access memory at address 0xfef12ec0 (gdb) shell cat /proc/30077/maps 0000000004000000-000000000435a000 rwxp 0000000000000000 00:00 0 000000000435a000-000000000435c000 ---p 000000000035a000 00:00 0 000000000435c000-000000000436c000 rwxp 000000000035c000 00:00 0 000000000436c000-000000000436e000 ---p 000000000036c000 00:00 0 000000000436e000-000000000437e000 rwxp 0000000000000000 00:00 0 0000000004577000-0000000005f69000 rwxp 0000000000000000 00:00 0 0000000008048000-0000000008049000 r-xp 0000000000000000 03:41 200779 /tmp/a.out 0000000008049000-000000000804a000 rwxp 0000000000000000 03:41 200779 /tmp/a.out 000000000804a000-000000000804b000 rwxp 0000000000000000 00:00 0 000000004eacb000-000000004eae0000 r-xp 0000000000000000 03:41 510225 /lib/ld-2.3.2.so <http://2.3.2.so> 000000004eae0000-000000004eae1000 rwxp 0000000000014000 03:41 510225 /lib/ld-2.3.2.so <http://2.3.2.so> 0000000070000000-0000000070135000 r-xp 0000000000000000 03:41 772191 /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck 0000000070135000-0000000070136000 rwxp 0000000000135000 03:41 772191 /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck 0000000070136000-00000000707c2000 rwxp 0000000000000000 00:00 0 00000000fef13000-00000000fef14000 rwxp 0000000000000000 00:00 0 00000000fff13000-00000000ffffe000 rw-p fffffffffff16000 00:00 0 (gdb) quit =3D=3D30076=3D=3D =3D=3D30076=3D=3D Debugger has detached. Valgrind regains control. We conti= nue. =3D=3D30076=3D=3D =3D=3D30076=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 fr= om 0) =3D=3D30076=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks. =3D=3D30076=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated. =3D=3D30076=3D=3D For counts of detected errors, rerun with: -v =3D=3D30076=3D=3D No malloc'd blocks -- no leaks are possible. Segmentation fault Hmm; %esp is just below the stack page, and the kernel refuses to grow stack? In fact, increasing environment size moves the place where it coredumps, and invreasing it sufficiently makes it run: $ /usr/local/valgrind-3.0.svn/bin/valgrind -q ./a.out && echo ok =3D=3D30158=3D=3D =3D=3D30158=3D=3D Process terminating with default action of signal 11 (SIG= SEGV): dumping core =3D=3D30158=3D=3D at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2= .so>) =3D=3D30158=3D=3D by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http= ://2.3.2.so> ) =3D=3D30158=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3= .2.so>) =3D=3D30158=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>= ) Segmentation fault $ PATH=3D$PATH:$PATH /usr/local/valgrind-3.0.svn/bin/valgrind -q ./a.out && echo ok =3D=3D30159=3D=3D =3D=3D30159=3D=3D Process terminating with default action of signal 11 (SIG= SEGV): dumping core =3D=3D30159=3D=3D at 0x4EADA172: _dl_sysdep_start (in /lib/ld-2.3.2.so<http= ://2.3.2.so> ) =3D=3D30159=3D=3D by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3= .2.so>) =3D=3D30159=3D=3D by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>= ) Segmentation fault $ PATH=3D$PATH:$PATH:$PATH /usr/local/valgrind-3.0.svn/bin/valgrind -q ./a.= out && echo ok ok Cheers, |