|
From: wim d. <wim...@ad...> - 2004-02-24 03:27:15
|
Hi all, I needed the watchpoint patch (as specified on the web site) and hence 'patched' version 2.0.0 of valgrind. However there are problems with gdb (version 6.0) with the backtrace : when I attach gdb and ask 'bt' I only get a few calls and the a 'stack corrupt' message. However valgrind itself (when printing the problem) shows a complete backtrace. So I wanted to upgrade to 2.1 hoping that this is fixed. Therefor I would like to know what the cleanest way is to (re-)integrate this watchpoint patch. Should I again download and patch or is it already in the main version ? If these patches are not in mainstream what is keeping you from doing so ? Also, what does Massif do ? I did not find any refs on the site ... Thanx W |
|
From: Robert W. <rj...@du...> - 2004-02-24 04:02:24
|
> However there are problems with gdb (version 6.0) with the backtrace : wh= en I=20 > attach gdb and ask 'bt' I only get a few calls and the a 'stack corrupt'=20 > message. However valgrind itself (when printing the problem) shows a comp= lete=20 > backtrace. Does this happen without the watchpoint patch installed? I haven't used the gdb stuff too much, so I don't know whether this might effect it. I doubt it, though. > So I wanted to upgrade to 2.1 hoping that this is fixed. Therefor I woul= d=20 > like to know what the cleanest way is to (re-)integrate this watchpoint=20 > patch. Should I again download and patch or is it already in the main=20 > version ? Nope - you need to grab it from my web site. The web site now has 2.0.0 and 2.1.0 versions available, although I've only lightly tested them, since I use the CVS head for my work. > If these patches are not in mainstream what is keeping you from doing so = ? They're pretty invasive in the memcheck memory-checking code, so before I push them back to CVS I'd like to get a better feeling for how much of a performance impact they have. My gut feeling is "a tolerable amount", but I'd rather quantify that myself before I piss people off by slowing their code down even more. > Also, what does Massif do ? I did not find any refs on the site ... It's a spiffy memory heap profiler. You can read the docs in CVS: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/~checkout~/valgrind/massif/docs/ms= _main.html?rev=3D1.1 Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: wim d. <wim...@ad...> - 2004-02-24 15:54:38
|
/mnt/buro/fs.permanent/home/u19809/software/valgrind/valgrind/massif/hp2ps/Deviation.c:75: undefined reference to `sqrt' Compile error in cvs head |
|
From: wim d. <wim...@ad...> - 2004-02-24 23:16:04
|
Hi all, at program exit (after valgrind reports the statistics at the end) the application segfaults leaving a core. However the core looks completely corrupt. gdb reports (gdb) bt #0 0xb804b452 in ?? () #1 0xbffff538 in ?? () #2 0x0000000b in ?? () #3 0xbffff55c in ?? () #4 0x0000475b in ?? () #5 0xb802e2cb in ?? () #6 0x000000ee in ?? () #7 0x0000475b in ?? () #8 0x0000000b in ?? () #9 0xbffff57c in ?? () #10 0x0000000b in ?? () #11 0xbffff5a8 in ?? () #12 0xb8035652 in ?? () #13 0x0000475b in ?? () #14 0x0000000b in ?? () #15 0xbffff54c in ?? () #16 0xfffbfa37 in ?? () #17 0xffffffff in ?? () #18 0xfffffbff in ?? () #19 0xffffffff in ?? () #20 0xb8035d22 in ?? () #21 0x18000004 in ?? () |
|
From: wim d. <wim...@ad...> - 2004-02-24 14:07:20
|
> Does this happen without the watchpoint patch installed? I haven't used > the gdb stuff too much, so I don't know whether this might effect it. I > doubt it, though. No it also happens with regular valgrind 2.0 ... I will compile 2.1 and see > > Nope - you need to grab it from my web site. The web site now has 2.0.0 > and 2.1.0 versions available, although I've only lightly tested them, > since I use the CVS head for my work. Are the patches 2.1 compatible ? CU W |
|
From: Robert W. <rj...@du...> - 2004-02-24 17:52:37
|
> Are the patches 2.1 compatible ? There is a 2.1.0 patch, yes. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: wim d. <wim...@ad...> - 2004-02-24 14:15:04
|
just compiled 2.1.0 patched with watchpoint 2.1.0 patch. Situation is the same ... you get a nice backtrace in valgrind but gdb=20 fails : =3D=3D12803=3D=3D Thread 4: =3D=3D12803=3D=3D Use of uninitialised value of size 4 =3D=3D12803=3D=3D at 0x4232FA12: DEMUX_SetReplicator (fddemux.c:556) =3D=3D12803=3D=3D by 0x42330785: Wrap_DEMUX_SetReplicator (fddemux.c:533) =3D=3D12803=3D=3D by 0x42303565: CHMGR_IHandleCommand (channelmanager.c:= 177) =3D=3D12803=3D=3D by 0x42303E06: ListenThread (channelmanager.c:284) =3D=3D12803=3D=3D by 0x4230410B: ListenThreadWrap (channelmanager.c:316) =3D=3D12803=3D=3D by 0x402455DC: AC_RunActivatorCompliant=20 (ActivatorOSInitialize_A.c:112) =3D=3D12803=3D=3D by 0x4024D759: thread_wrapper (vg_libpthread.c:660) =3D=3D12803=3D=3D by 0x4015A398: do__quit (vg_scheduler.c:1787) =3D=3D12803=3D=3D =3D=3D12803=3D=3D ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y =2D- SNIP -- =3D=3D12803=3D=3D starting GDB with cmd: /usr/bin/gdb -nw /proc/12803/exe 1= 2803 GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... Attaching to program: /proc/12803/exe, process 12803 Reading symbols from /usr/lib/valgrind/vgskin_memcheck.so...done. =2D SNIP - Reading symbols=20 from /home/u19809/projects/AP/APEE_RT/gcc3/parcels/571331_TS.pex...done. Loaded symbols for /home/u19809/projects/AP/APEE_RT/gcc3/parcels/571331_TS.= pex 0x40196a36 in vgPlain_do_syscall () from /usr/lib/valgrind/valgrind.so (gdb) bt #0 0x40196a36 in vgPlain_do_syscall () from /usr/lib/valgrind/valgrind.so #1 0x4017a667 in vgPlain_system (cmd=3D0x401d8dc8 "=D4\034\t") at=20 vg_mylibc.c:1385 Previous frame inner to this frame (corrupt stack?) Suggestions |
|
From: wim d. <wim...@ad...> - 2004-02-24 14:25:46
|
Strangly enough 2.1.0 patched or unpatched does not allow for CTRL-C anymore. I need this because the standard options of prompt (return y, n or c) always continue (either with gdb, or without or without for all other problems) W |
|
From: Tom H. <th...@cy...> - 2004-02-24 14:37:11
|
In message <200...@ad...>
wim delvaux <wim...@ad...> wrote:
> Strangly enough 2.1.0 patched or unpatched does not allow for CTRL-C anymore.
What do you mean by "allow for CTRL-C"? What were you typing the
Ctrl-C to? and what was happening when you typed it?
> I need this because the standard options of prompt (return y, n or c) always
> continue (either with gdb, or without or without for all other problems)
If you program is changing the terminal mode in certain ways then you
may need to type ^J after the letter instead of hitting enter as
valgrind only looks for an NL and doesn't handle CR at that point.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: wim d. <wim...@ad...> - 2004-02-24 15:12:11
|
On Tuesday 24 February 2004 15:36, Tom Hughes wrote: > In message <200...@ad...> > > wim delvaux <wim...@ad...> wrote: > > Strangly enough 2.1.0 patched or unpatched does not allow for CTRL-C > > anymore. > > What do you mean by "allow for CTRL-C"? What were you typing the > Ctrl-C to? and what was happening when you typed it? When you get the prompt to ask if you want to attach to gdb I press ctrl-c > > > I need this because the standard options of prompt (return y, n or c) > > always continue (either with gdb, or without or without for all other > > problems) > > If you program is changing the terminal mode in certain ways then you > may need to type ^J after the letter instead of hitting enter as > valgrind only looks for an NL and doesn't handle CR at that point. No the program does not do anything with respect to terminals. THe prompt works just fine. That is not the problem but the options that are present do not allow you to terminate the application (it always proposes to continue), hence the ctrl-c > > Tom |
|
From: Tom H. <th...@cy...> - 2004-02-24 14:35:29
|
In message <200...@ad...>
wim delvaux <wim...@ad...> wrote:
> Reading symbols
> from /home/u19809/projects/AP/APEE_RT/gcc3/parcels/571331_TS.pex...done.
> Loaded symbols for /home/u19809/projects/AP/APEE_RT/gcc3/parcels/571331_TS.pex
> 0x40196a36 in vgPlain_do_syscall () from /usr/lib/valgrind/valgrind.so
> (gdb) bt
> #0 0x40196a36 in vgPlain_do_syscall () from /usr/lib/valgrind/valgrind.so
> #1 0x4017a667 in vgPlain_system (cmd=0x401d8dc8 "Ô\034\t") at
> vg_mylibc.c:1385
> Previous frame inner to this frame (corrupt stack?)
This should be fixed in the CVS head as we changed the way that
attaching to the debugger is handled in order to avoid this.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <ar...@de...> - 2004-02-24 14:55:12
|
Is this a huge change? I have lots of Debian users complaining about this and it would be a good enhancement to the Debian version of valgrind (2.1.0-7). Tom Hughes <th...@cy...> writes: > In message <200...@ad...> > wim delvaux <wim...@ad...> wrote: > >> Reading symbols >> from /home/u19809/projects/AP/APEE_RT/gcc3/parcels/571331_TS.pex...done. >> Loaded symbols for /home/u19809/projects/AP/APEE_RT/gcc3/parcels/571331_TS.pex >> 0x40196a36 in vgPlain_do_syscall () from /usr/lib/valgrind/valgrind.so >> (gdb) bt >> #0 0x40196a36 in vgPlain_do_syscall () from /usr/lib/valgrind/valgrind.so >> #1 0x4017a667 in vgPlain_system (cmd=0x401d8dc8 "Ô\034\t") at >> vg_mylibc.c:1385 >> Previous frame inner to this frame (corrupt stack?) > > This should be fixed in the CVS head as we changed the way that > attaching to the debugger is handled in order to avoid this. > > Tom > > -- > Tom Hughes (th...@cy...) > Software Engineer, Cyberscience Corporation > http://www.cyberscience.com/ > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Andrés Roldán <ar...@de...> GPG Key-ID: 0xB29396EB http://people.fluidsignal.com/~aroldan |
|
From: Tom H. <th...@cy...> - 2004-02-24 14:59:40
|
In message <87r...@vo...>
Andrés Roldán <ar...@de...> wrote:
> Is this a huge change? I have lots of Debian users complaining
> about this and it would be a good enhancement to the Debian
> version of valgrind (2.1.0-7).
It isn't tiny because we did completely change the mechanism used to
attach the debugger. It isn't completely massive either.
There's likely to be a 2.1.1 fairly soon anyway I think.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: wim d. <wim...@ad...> - 2004-02-24 15:19:12
|
I get this when running ./autogen.sh after checking out cvs HEAD running: aclocal running: autoheader running: automake -a automake: configure.in: installing `./install-sh' automake: configure.in: installing `./mkinstalldirs' automake: configure.in: installing `./missing' automake: configure.in: installing `./config.guess' automake: configure.in: installing `./config.sub' Makefile.am:2: require version 1.6, but have 1.4-p6 automake: coregrind/Makefile.am: not supported: source file `x86/ume_entry.S' is in subdirectory automake: coregrind/Makefile.am: not supported: source file `x86/ume_go.c' is in subdirectory coregrind/Makefile.am: valgrind_OBJECTS should not be defined automake: coregrind/Makefile.am: not supported: source file `x86/ume_entry.S' is in subdirectory automake: coregrind/Makefile.am: not supported: source file `x86/ume_go.c' is in subdirectory |
|
From: Olly B. <ol...@su...> - 2004-02-24 15:43:52
|
On Tue, Feb 24, 2004 at 04:18:14PM +0100, wim delvaux wrote:
> Makefile.am:2: require version 1.6, but have 1.4-p6
You need to use automake 1.6 or later...
Cheers,
Olly
|
|
From: wim d. <wim...@ad...> - 2004-02-24 15:46:38
|
On Tuesday 24 February 2004 16:42, Olly Betts wrote: > On Tue, Feb 24, 2004 at 04:18:14PM +0100, wim delvaux wrote: > > Makefile.am:2: require version 1.6, but have 1.4-p6 > > You need to use automake 1.6 or later... Ok that is the crappy thing with automake. I have about 4 version installed ii automake1.4 1.4-p6-8 A tool for generating GNU Standards-complian ii automake1.6 1.6.3-11 A tool for generating GNU Standards-complian ii automake1.7 1.7.9-3 A tool for generating GNU Standards-complian But it always picks up the wrong one ... why are they always incompatible ??? > Cheers, > Olly |
|
From: wim d. <wim...@ad...> - 2004-02-24 15:56:26
|
gcc -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -o hp2ps -lm AuxFile.o Axes.o AreaBelow.o Curves.o Deviation.o Dimensions.o Error.o HpFile.o Key.o Main.o Marks.o TopTwenty.o TraceElement.o PsFile.o Reorder.o Scale.o Shade.o Utilities.o probably need this too... |
|
From: Tom H. <th...@cy...> - 2004-02-24 16:41:08
|
In message <200...@ad...>
wim delvaux <wim...@ad...> wrote:
> gcc -Winline -Wall -Wshadow -O -fno-omit-frame-pointer
> -mpreferred-stack-boundary=2 -g -o hp2ps -lm AuxFile.o Axes.o AreaBelow.o
> Curves.o Deviation.o Dimensions.o Error.o HpFile.o Key.o Main.o Marks.o
> TopTwenty.o TraceElement.o PsFile.o Reorder.o Scale.o Shade.o Utilities.o
The -lm should probably be at the end of that line instead of the
start, otherwise any references to maths functions in those .o files
might not be resolved properly.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: wim d. <wim...@ad...> - 2004-02-24 23:12:14
|
Indeed, putting -lm at the end resolves sqrt ... change makefiles plse |
|
From: Nicholas N. <nj...@ca...> - 2004-02-24 23:32:54
|
On Wed, 25 Feb 2004, wim delvaux wrote: > Indeed, putting -lm at the end resolves sqrt ... change makefiles plse It's not as simple as that -- the Makefiles are autogenerated by automake. It's the one putting the -lm before the .o files. I don't know why it does this or how to change it. And Wim, here's a suggestion: terse, single-line bug reports are not a very effective way to get responses. N |
|
From: wim d. <wim...@ad...> - 2004-02-24 23:45:43
|
On Wednesday 25 February 2004 00:31, Nicholas Nethercote wrote: > On Wed, 25 Feb 2004, wim delvaux wrote: > > Indeed, putting -lm at the end resolves sqrt ... change makefiles plse > > It's not as simple as that -- the Makefiles are autogenerated by automake. > It's the one putting the -lm before the .o files. I don't know why it > does this or how to change it. > > And Wim, here's a suggestion: terse, single-line bug reports are not a > very effective way to get responses. > > N Sorry about that but it was a reponse to a previous item in the thread (somebody suggested putting that -lm near the end) About the Makefile. I am not sure HOW that -lm gets there. Can automake detect what libraries are needed based on the source ? I think the Makefile.am or Makefile.in (whichever) has some rules to define HOW this needs to be compiled ... CU W |
|
From: Tom H. <th...@cy...> - 2004-02-25 08:54:14
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 25 Feb 2004, wim delvaux wrote:
>
>> Indeed, putting -lm at the end resolves sqrt ... change makefiles plse
>
> It's not as simple as that -- the Makefiles are autogenerated by automake.
> It's the one putting the -lm before the .o files. I don't know why it
> does this or how to change it.
Reading the automake manual, it looks like you need to use LDADD
instead of LDFLAGS to set the libraries. That gets added at the end
of the linker command line instead of the start.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-26 09:06:41
|
On Wed, 25 Feb 2004, Tom Hughes wrote: > Reading the automake manual, it looks like you need to use LDADD > instead of LDFLAGS to set the libraries. That gets added at the end > of the linker command line instead of the start. done |