|
From: Julian S. <js...@ac...> - 2005-07-27 20:17:50
|
Greetings. Valgrind-3.0.0 Release Candidate 1 is available from http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 (md5sum == c3dc8089bebe7aba0822667b7850451e) This is our first attempt at what we believe to be a release-quality snapshot of the Valgrind-3.0 line. If all goes well, we hope to release a final 3.0 in about a week's time. This is the first Valgrind to support both x86-linux and amd64-linux. Support for ppc32-linux is also integrated but does not yet work well enough to be useful. Please download and test this release candidate, and let us know of any problems you encounter. This tarball is known to build and work on the following platforms: amd64 running SuSE 9.2 x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4 ppc32 running Yellow Dog 4.0.1 (subject to caveats above) The attached release notes detail what is new in 3.0. Many thanks to all those who contributed to Valgrind's development. This RC represents a great deal of time, energy and effort on the part of many people. The Valgrind Developers --------------------------------------------------------------------- Release 3.0.0 ([[TODO: add release date]]) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.0.0 is a major overhaul of Valgrind. The most significant user-visible change is that Valgrind now supports architectures other than x86. The new architectures it supports are AMD64 and PPC32, and the infrastructure is present for other architectures to be added later. The AMD64 support works well, but has some shortcomings: - It generally won't be as solid as the x86 version. For example, support for more obscure instructions and system calls may be missing. We will fix these as they arise. - Address space may be limited; see the point about position-independent executables below. - If Valgrind is built on an AMD64 machine, it will only run 64-bit executables. If you want to run 32-bit x86 executables under Valgrind on an AMD64, you will need to build Valgrind on an x86 machine and copy it to the AMD64 machine. And it probably won't work if you do something tricky like exec'ing a 32-bit program from a 64-bit program while using --trace-children=yes. We hope to improve this situation in the future. The PPC32 support is very basic. It may not work reliably even for small programs, but it's a start. Many thanks to Paul Mackerras for his great work that enabled this support. We are working to make PPC32 usable as soon as possible. Other user-visible changes: - No longer building Valgrind as a position-independent executable (PIE) by default, as it caused too many problems. Without PIE enabled, AMD64 programs will only be able to access 2GB of address space. We will fix this eventually, but not for the moment. Use --enable-pie at configure-time to turn this on. - Support for programs that use stack-switching has been improved. Use the --max-stackframe flag for simple cases, and the VALGRIND_STACK_REGISTER, VALGRIND_STACK_DEREGISTER and VALGRIND_STACK_CHANGE client requests for trickier cases. - Support for programs that use self-modifying code has been improved, in particular programs that put temporary code fragments on the stack. This helps for C programs compiled with GCC that use nested functions, and also Ada programs. This is controlled with the --smc-check flag, although the default setting should work in most cases. - Output can now be printed in XML format. This should make it easier for tools such as GUI front-ends and automated error-processing schemes to use Valgrind output as input. The --xml flag controls this. As part of this change, ELF directory information is read from executables, so absolute source file paths are available if needed. [[TODO: describe the related CLOs added (eg. --log-file-qualifier)]] - Programs that allocate many heap blocks may run faster, due to improvements in certain data structures. - Addrcheck is currently not working. We hope to get it working again soon. Helgrind is still not working, as was the case for the 2.4.0 release. - The JITter has been completely rewritten, and is now in a separate library, called Vex. This enabled a lot of the user-visible changes, such as new architecture support. The new JIT unfortunately translates more slowly than the old one, so programs may take longer to start. We believe the code quality is produces is about the same, so once started, programs should run at about the same speed. Feedback about this would be useful. On the plus side, Vex and hence Memcheck tracks value flow properly through floating point and vector registers, something the 2.X line could not do. That means that Memcheck is much more likely to be usably accurate on vectorised code. - There is a subtle change to the way exiting of threaded programs is handled. In 3.0, Valgrind's final diagnostic output (leak check, etc) is not printed until the last thread exits. If the last thread to exit was not the original thread which started the program, any other process wait()-ing on this one to exit may conclude it has finished before the diagnostic output is printed. This may not be what you expect. 2.X had a different scheme which avoided this problem, but caused deadlocks under obscure circumstances, so we are trying something different for 3.0. - Small changes in control log file naming which make it easier to use valgrind for debugging MPI-based programs. - As part of adding AMD64 support, DWARF2 CFI-based stack unwinding support was added. In principle this means Valgrind can produce meaningful backtraces on x86 code compiled with -fomit-frame-pointer providing you also compile your code with -fasynchronous-unwind-tables. - [[TODO: add more here]] Changes that are not user-visible: - The code has been massively overhauled in order to modularise it. As a result we hope it is easier to navigate and understand. - Lots of code has been rewritten. - [[TODO: add more here]] BUGS FIXED [[TODO: add the full list here (once the RCs are out of the way?)]] (3.0RC1: 27 July 05, vex r1303, valgrind r4283). |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 20:49:49
|
On Wed, 27 Jul 2005, Julian Seward wrote: > Valgrind-3.0.0 Release Candidate 1 is available from > http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 > (md5sum == c3dc8089bebe7aba0822667b7850451e) Regression tests go as expected (3 failures), and StarOffice worked ok. Although I did see this output at the end: ==8095== Syscall param write(buf) points to uninitialised byte(s) ==8095== at 0x1CC26404: write (in /lib/libc-2.2.5.so) ==8095== by 0x1C7528E3: osl_joinWithThread (in /lusr/opt/staroffice7/program/libsal.so.3.1.0) ==8095== by 0x1C412377: vos::OThread::join() (in /lusr/opt/staroffice7/program/libvos3gcc3.so) ==8095== by 0x806EABF: desktop::OfficeIPCThread::DisableOfficeIPCThread() (in /lusr/opt/staroffice7/program/soffice.bin) ==8095== by 0x80605F5: desktop::Desktop::DeInit() (in /lusr/opt/staroffice7/program/soffice.bin) ==8095== by 0x1B9D4C34: DeInitVCL() (in /lusr/opt/staroffice7/program/libvcl645li.so) ==8095== by 0x1B9D4692: SVMain() (in /lusr/opt/staroffice7/program/libvcl645li.so) ==8095== by 0x1BB987E3: main (in /lusr/opt/staroffice7/program/libvcl645li.so) ==8095== Address 0x52BFE3CC is on thread 1's stack [~/grind/trunk2/tmp/valgrind-3.0.RC1] ==8128== ==8128== ERROR SUMMARY: 1578 errors from 64 contexts (suppressed: 8 from 3) ==8128== malloc/free: in use at exit: 801466 bytes in 6295 blocks. ==8128== malloc/free: 22603 allocs, 16308 frees, 4661380 bytes allocated. ==8128== For counts of detected errors, rerun with: -v ==8128== searching for pointers to 6295 not-freed blocks. ==8128== checked 22230836 bytes. ==8128== ==8128== LEAK SUMMARY: ==8128== definitely lost: 18050 bytes in 22 blocks. ==8128== possibly lost: 44884 bytes in 399 blocks. ==8128== still reachable: 738532 bytes in 5874 blocks. ==8128== suppressed: 0 bytes in 0 blocks. ==8128== Use --leak-check=full to see details of leaked memory. Notice that the prompt is buried in there before the final output. This could be caused by the change in how termination is handled. N |
|
From: Nicholas N. <nj...@cs...> - 2005-07-27 20:55:58
|
On Wed, 27 Jul 2005, Nicholas Nethercote wrote: >> Valgrind-3.0.0 Release Candidate 1 is available from >> http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 >> (md5sum == c3dc8089bebe7aba0822667b7850451e) > > Regression tests go as expected (3 failures), and StarOffice worked ok. I forgot to say: [~/scale/dev1/scale] uname -a Linux charco.cs.utexas.edu 2.4.29 #1 SMP Mon Jan 24 09:20:36 CST 2005 i686 unknown [~/scale/dev1/scale] /lib/libc.so.6 GNU C Library stable release version 2.2.5, by Roland McGrath et al. Copyright (C) 1992-2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 2.95.4 20011002 (Debian prerelease). Compiled on a Linux 2.4.18 system on 2005-01-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.9 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Report bugs using the `glibcbug' script to <bu...@gn...>. This is an oldish Debian-something system. N |
|
From: Julian S. <js...@ac...> - 2005-07-27 21:11:25
|
> Regression tests go as expected (3 failures), and StarOffice worked ok. > Although I did see this output at the end: Good. OOo 1.1.3 on LinuxThreads works, I know that much. > > ==8095== Syscall param write(buf) points to uninitialised byte(s) > ==8095== at 0x1CC26404: write (in /lib/libc-2.2.5.so) > ==8095== by 0x1C7528E3: osl_joinWithThread (in > /lusr/opt/staroffice7/program/libsal.so.3.1.0) > ==8095== by 0x1C412377: vos::OThread::join() (in > /lusr/opt/staroffice7/program/libvos3gcc3.so) > ==8095== by 0x806EABF: > desktop::OfficeIPCThread::DisableOfficeIPCThread() (in > /lusr/opt/staroffice7/program/soffice.bin) > ==8095== by 0x80605F5: desktop::Desktop::DeInit() (in > /lusr/opt/staroffice7/program/soffice.bin) > ==8095== by 0x1B9D4C34: DeInitVCL() (in > /lusr/opt/staroffice7/program/libvcl645li.so) > ==8095== by 0x1B9D4692: SVMain() (in > /lusr/opt/staroffice7/program/libvcl645li.so) > ==8095== by 0x1BB987E3: main (in > /lusr/opt/staroffice7/program/libvcl645li.so) Isn't that a classic buffer-contains-uninitialised-padding problem? > Notice that the prompt is buried in there before the final output. This > could be caused by the change in how termination is handled. It is indeed. Bear in mind that OOo/SO was the first known deadlock-at- exit case and so it makes sense now that the main thread exits before all of its children. J |
|
From: Madhu M K. <mm...@ya...> - 2005-07-27 20:50:38
|
Hi, On Wed, 2005-07-27 at 13:17, Julian Seward wrote: > Please download and test this release candidate, and let us know of > any problems you encounter. This tarball is known to build and work > on the following platforms: > > amd64 running SuSE 9.2 > > x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4 > You can add Fedora Core 1 and Fedora Core 2 to that list. Some warnings from the compile were: -- gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../.. -I../../coregrind/x86 -I../../coregrind/linux -I../../coregrind/x86-linux -I../../include -I/home/mmk/valgrind/valgrind-3.0.RC1/VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -MT symtypes.o -MD -MP -MF ".deps/symtypes.Tpo" -c -o symtypes.o symtypes.c; \ then mv -f ".deps/symtypes.Tpo" ".deps/symtypes.Po"; else rm -f ".deps/symtypes.Tpo"; exit 1; fi symtypes.c: In function `vgPlain_describe_addr': symtypes.c:764: warning: no previous prototype for `newvar' symtypes.c:984: warning: no previous prototype for `genstring' and gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../coregrind -I.. -I../coregrind/x86 -I../coregrind/linux -I../coregrind/x86-linux -I../include -I/home/mmk/valgrind/valgrind-3.0.RC1/VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DKICKSTART_BASE=0xb0000000 -m32 -mpreferred-stack-boundary=2 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -MT m_mallocfree.o -MD -MP -MF ".deps/m_mallocfree.Tpo" -c -o m_mallocfree.o m_mallocfree.c; \ then mv -f ".deps/m_mallocfree.Tpo" ".deps/m_mallocfree.Po"; else rm -f ".deps/m_mallocfree.Tpo"; exit 1; fi In file included from m_mallocfree.c:252: m_mallocfree.c:267: warning: inlining failed in call to `get_bszB' m_mallocfree.c:249: warning: called from here -- Apart from those, things seem pretty rock solid. I've run some basic sanity checks and they seem fine, I'm going to get the regression testing going tonight. Cheerio, M -- Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
From: Tom H. <to...@co...> - 2005-07-27 21:30:16
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Please download and test this release candidate, and let us know of
> any problems you encounter. This tarball is known to build and work
> on the following platforms:
>
> amd64 running SuSE 9.2
FC 2, 3 and 4 should be OK as well. My overnights are running amd64
on all of those.
> x86 running SuSE 9.1, SuSE 9.3, RedHat 7.3, Fedora Core 4
RH 8.0 should be OK as well.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christian P. <tr...@ge...> - 2005-07-27 21:38:22
|
On Wednesday 27 July 2005 22:17, Julian Seward wrote: > amd64 running SuSE 9.2 amd64 running Gentoo/Linux (2005.0, ~amd64 testing/unstable packages) ^^ works fine for me, too, however, I do *STILL* have that freezing=20 (mmap/munmap) problem on VG start and exit. Regards, Christian Parpart. =2D-=20 23:36:08 up 126 days, 12:43, 2 users, load average: 2.37, 9.55, 7.26 |
|
From: Nicholas N. <nj...@cs...> - 2005-07-29 14:25:10
|
On Fri, 29 Jul 2005, Duane Griffin wrote: > It builds and seems to work fine for me on AMD64 running SuSE 9.0, but > there are a number of failures in the regression test: > > == 157 tests, 35 stderr failures, 1 stdout failure ================= 35 is a bit high. Can you look at the *.stderr.diff and *.stderr.out files and determine if there's a single cause of most of the failures? Thanks. N |
|
From: Maurice v. d. P. <gri...@ge...> - 2005-07-31 13:32:35
|
On Fri, Jul 29, 2005 at 09:25:01AM -0500, Nicholas Nethercote wrote: > On Fri, 29 Jul 2005, Duane Griffin wrote: >=20 > >It builds and seems to work fine for me on AMD64 running SuSE 9.0, but > >there are a number of failures in the regression test: > > > >=3D=3D 157 tests, 35 stderr failures, 1 stdout failure =3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 35 is a bit high. Can you look at the *.stderr.diff and *.stderr.out=20 > files and determine if there's a single cause of most of the failures? I have similar results on an x86 running Gentoo: =3D=3D 180 tests, 31 stderr failures, 2 stdout failures =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D memcheck/tests/addressable (stderr) memcheck/tests/badaddrvalue (stderr) memcheck/tests/badrw (stderr) memcheck/tests/clientperm (stderr) memcheck/tests/custom_alloc (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/errs1 (stderr) memcheck/tests/exitprog (stderr) memcheck/tests/fprw (stderr) memcheck/tests/inits (stderr) memcheck/tests/inline (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/manuel1 (stderr) memcheck/tests/manuel3 (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/strchr (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/x86/pushfpopf (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_exit_group (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/mq (stderr) none/tests/selfrun (stdout) none/tests/selfrun (stderr) none/tests/x86/int (stderr) There does not seem to be a single cause of most of these.=20 I see unhandled instructions, an unimplemented function (mq_open), a bad cmdline option (--single-step=3Dyes), lots of expected __libc_start_main messages that are not generated, source line differences, etc. I'll be happy to provide whatever extra info you need. Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Julian S. <js...@ac...> - 2005-07-29 17:40:18
|
> On Friday 29 July 2005 12:59, Duane Griffin wrote: > It builds and seems to work fine for me on AMD64 running SuSE 9.0, but > there are a number of failures in the regression test: > > == 157 tests, 35 stderr failures, 1 stdout failure ================= They are probably all encountering the same problem, but we'd need to see the nonempty <testname>.stderr.diff files to find out. Can you tar them up and send them? J |
|
From: Julian S. <js...@ac...> - 2005-07-29 17:52:05
|
> On Fri, 2005-07-29 at 14:12 +0100, Julian Seward wrote: > > > On Friday 29 July 2005 12:59, Duane Griffin wrote: > > > It builds and seems to work fine for me on AMD64 running SuSE 9.0, but > > > there are a number of failures in the regression test: > > > > > > == 157 tests, 35 stderr failures, 1 stdout failure ================= > > > > They are probably all encountering the same problem, but we'd need > > to see the nonempty <testname>.stderr.diff files to find out. Can you > > tar them up and send them? > > My pleasure, please find them attached. Looks like they are mostly just > caused by this warning: > > Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading Ok, all you DWARF2 CFA junkies out there :-), here's a question: I get the abovementioned warning a lot. Basically the call-frame unwinding information is a sequence of CIE or FDE records. What's in them doesn't matter, but each does have a size field which says how big that particular record is. Valgrind takes a zero-sized record as an end-of-sequence marker, and stops reading. Most of the time this corresponds to the end of the ELF .ehframe section, but sometimes it doesn't. For reference, "readelf --debug-dump=frames" also stops reading when it hits a zero-length CIE/FDE record. Problem is, the DWARF3 specification describes the CFA information in great detail, but it doesn't say how the end of the CIE/FDE record sequence is to be detected. If anybody can shed any light on this ultra-arcane point, I'd really appreciate it. J |
|
From: Tom H. <to...@co...> - 2005-07-29 18:04:51
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> Problem is, the DWARF3 specification describes the CFA information in
> great detail, but it doesn't say how the end of the CIE/FDE record
> sequence is to be detected.
My code just carries on to the end of the .dwarf_frame section
and libdwarf looks like it does the same.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Maurice v. d. P. <gri...@ge...> - 2005-07-29 17:46:15
Attachments:
valgrind-3.0.0-static-const.patch
|
On Wed, Jul 27, 2005 at 09:17:35PM +0100, Julian Seward wrote:
> Please download and test this release candidate, and let us know of
> any problems you encounter.
It compiles on one of my systems, but not on the other. The system that
it fails to build on is an nptl only system.
The build fails because of a few static const variable declarations
within functions. Why are these static? If I change them to normal const
variables, the compilation succeeds.
One example of this is in coregrind/m_aspacemgr/aspacemgr.c at the
beginning of function VG_(unmap_range). The error I get is
"initializer element is not constant".
I've tried with
compilers: gcc 3.3.3
gcc 3.4.3
gcc 3.4.4
glibc: 2.3.5
Attached is a patch to change all problematic static consts into consts.
Best regards,
Maurice.
P.S.: If proc is not mounted, valgrind exits like this:
open /proc/self/maps: No such file or directory
Segmentation fault
It would be nice if it could exit more gracefully.
--
Maurice van der Pot
Gentoo Linux Developer gri...@ge... http://www.gentoo.org
Creator of BiteMe! gri...@kf... http://www.kfk4ever.com
|
|
From: Tom H. <to...@co...> - 2005-07-29 17:58:50
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> It compiles on one of my systems, but not on the other. The system that
> it fails to build on is an nptl only system.
I don't think the NPTL only thing is an issue. FC4 is NPTL by default
and that builds fine.
> The build fails because of a few static const variable declarations
> within functions. Why are these static? If I change them to normal const
> variables, the compilation succeeds.
The problem is not the fact that it is static, but the fact that
the initialiser is invalid.
> One example of this is in coregrind/m_aspacemgr/aspacemgr.c at the
> beginning of function VG_(unmap_range). The error I get is
> "initializer element is not constant".
Those are technically invalid but work with every version of gcc
that I know of so long as you have optimisation turned on as the
constant folder reduces the expression to a constant before it checks
the initialiser ;-)
For production use I would suggest that you probably want to have
optimisation turned on when building valgrind
> I've tried with
> compilers: gcc 3.3.3
> gcc 3.4.3
> gcc 3.4.4
> glibc: 2.3.5
>
> Attached is a patch to change all problematic static consts into consts.
There is already a bug on the bug tracker for this. You probably
want to attach yourself to it and maybe add your patch.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Maurice v. d. P. <gri...@ge...> - 2005-07-29 18:17:42
|
On Fri, Jul 29, 2005 at 06:58:43PM +0100, Tom Hughes wrote: > > The build fails because of a few static const variable declarations > > within functions. Why are these static? If I change them to normal const > > variables, the compilation succeeds. >=20 > The problem is not the fact that it is static, but the fact that > the initialiser is invalid. I'd like to understand this. The initialiser is False || somestaticconstfil= evar.=20 Why would that be a problem only for static consts and not for consts?=20 What is the difference between static consts and consts within functions=20 for that matter? > For production use I would suggest that you probably want to have > optimisation turned on when building valgrind You're right. I forgot to check this. > There is already a bug on the bug tracker for this. You probably > want to attach yourself to it and maybe add your patch. Oh man! I'm the one who submitted the report! When I saw this problem this time I knew I had seen it before, but I searched through Gentoo's bugzilla and any patches I ever applied to my packages and didn't find anything.=20 Sorry for the duplicate report. I attached the patch to the bug report. Thanks, Maurice. --=20 Maurice van der Pot Gentoo Linux Developer gri...@ge... http://www.gentoo.org Creator of BiteMe! gri...@kf... http://www.kfk4ever.com |
|
From: Tom H. <to...@co...> - 2005-07-29 18:30:16
|
In message <200...@kf...>
Maurice van der Pot <gri...@ge...> wrote:
> On Fri, Jul 29, 2005 at 06:58:43PM +0100, Tom Hughes wrote:
> > > The build fails because of a few static const variable declarations
> > > within functions. Why are these static? If I change them to normal const
> > > variables, the compilation succeeds.
> >
> > The problem is not the fact that it is static, but the fact that
> > the initialiser is invalid.
>
> I'd like to understand this. The initialiser is False || somestaticconstfilevar.
> Why would that be a problem only for static consts and not for consts?
> What is the difference between static consts and consts within functions
> for that matter?
Whether it is const or not is irrelevant, the fact is that the
initialiser for a static variable (whether or not it is const and
whether it is at file or function scape) is supposed to be a constant.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-07-31 12:44:31
|
> Valgrind-3.0.0 Release Candidate 1 is available from > http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2 > (md5sum == c3dc8089bebe7aba0822667b7850451e) On Debian 3.1 (x86), valgrind RC1 works, but shows two unexpected errors in the regression test: * none/tests/x86/int fails with vex x86->IR: unhandled instruction bytes: 0xCD 0x81 0xC7 0x4 * none/tests/faultstatus fails with Test 4: PASS Test 5: vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x5D 0xC3 FAIL: expected si_code==2, not 1 Test 6: vex x86->IR: unhandled instruction bytes: 0xCC 0x5D 0xC3 0x55 FAIL: expected signal 5, not 4 Test 7: vex x86->IR: unhandled instruction bytes: 0xCD 0x10 0x5D 0xC3 FAIL: expected signal 11, not 4 Test 8: vex x86->IR: unhandled instruction bytes: 0xCE 0x89 0x45 0xFC FAIL: expected signal 11, not 4 Test 9: vex x86->IR: unhandled instruction bytes: 0x62 0x5 0xC 0x90 FAIL: expected signal 11, not 4 Both programs behave as expected outside of valgrind. Software used: gcc version 3.3.5 (Debian 1:3.3.5-13) $ uname -a Linux localhost 2.4.26-1-386 #1 Tue Aug 24 13:31:19 JST 2004 i686 GNU/Linux $ /lib/libc.so.6 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.3.5 (Debian 1:3.3.5-12). Compiled on a Linux 2.6.0-test7 system on 2005-05-10. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. Report bugs using the `glibcbug' script to <bu...@gn...>. |
|
From: Tom H. <to...@co...> - 2005-07-31 15:11:55
|
In message <8701.194.109.230.85.1122813863.squirrel@194.109.230.85>
"Jeroen N. Witmond" <jn...@xs...> wrote:
> > Valgrind-3.0.0 Release Candidate 1 is available from
> > http://www.valgrind.org/downloads/valgrind-3.0.RC1.tar.bz2
> > (md5sum == c3dc8089bebe7aba0822667b7850451e)
>
> On Debian 3.1 (x86), valgrind RC1 works, but shows two unexpected errors
> in the regression test:
>
> * none/tests/x86/int fails with
>
> vex x86->IR: unhandled instruction bytes: 0xCD 0x81 0xC7 0x4
>
> * none/tests/faultstatus fails with
>
> Test 4: PASS
> Test 5: vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x5D 0xC3
> FAIL: expected si_code==2, not 1
> Test 6: vex x86->IR: unhandled instruction bytes: 0xCC 0x5D 0xC3 0x55
> FAIL: expected signal 5, not 4
> Test 7: vex x86->IR: unhandled instruction bytes: 0xCD 0x10 0x5D 0xC3
> FAIL: expected signal 11, not 4
> Test 8: vex x86->IR: unhandled instruction bytes: 0xCE 0x89 0x45 0xFC
> FAIL: expected signal 11, not 4
> Test 9: vex x86->IR: unhandled instruction bytes: 0x62 0x5 0xC 0x90
> FAIL: expected signal 11, not 4
Those tests are testing invalid instructions, but ones which are
supposed to generate a different sort of signal rather than a
basic SIGILL and vex doesn't currently support that as it just
reports an undefined instruction and valgrind then raisess SIGILL.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-31 14:47:19
|
On Sun, 31 Jul 2005, Jeroen N. Witmond wrote: > On Debian 3.1 (x86), valgrind RC1 works, but shows two unexpected errors > in the regression test: > > * none/tests/x86/int > * none/tests/faultstatus These are expected; the new JITter doesn't yet implemented all the required instructions. It's good that you are only seeing these two failures, that's the minimum we can expect. Thanks for the report. N |
|
From: Jeroen N. W. <jn...@xs...> - 2005-08-01 13:02:27
|
> On Sun, 31 Jul 2005, Jeroen N. Witmond wrote: > >> On Debian 3.1 (x86), valgrind RC1 works, but shows two unexpected >> errors in the regression test. > > These are expected; the new JITter doesn't yet implemented all the > required instructions. It's good that you are only seeing these two > failures, that's the minimum we can expect. In fact, I see five errors in the regression test. The two I mentioned earlier were the ones I didn't expect, or at least could not explain. Two other errors are in none/tests/fdleak_fcntl and memcheck/tests/writev. These are caused by differences in the stack trace, and could be handled by adding yet another set of suppression files. The fifth error is in none/tests/tls. First of all, this test is never run with RC1 as is, as file none/tests/tls.vgtest is missing from the distribution. (It is not referrenced in none/tests/Makefile.am.) After copying this file from svn into RC1, the test is run but fails. gcc and libc on my box support TLS, so the test for TLS in the valgrind configation succeeds. But apparently the kernel I use (2.4.26) does not support TLS. Therefore I regard this fifth error as a configuration error, as configuring valgrind with --disable-tls makes this error go away. As far as I can see, that is the only effect this configuration option has. An additional and minor point is that while searching for other tests without a .vgtest file, I noticed that memcheck/tests/metadata has a file .vgtest-HIDING instead, which makes me curious. The bottom line remains that I find the minimum expected number of errors, which also remains good news. Jeroen. |
|
From: Julian S. <js...@ac...> - 2005-08-01 13:45:37
|
> The fifth error is in none/tests/tls. First of all, this test is never run > with RC1 as is, as file none/tests/tls.vgtest is missing from the > distribution. Fixed (r4298). Thanks for spotting that. > An additional and minor point is that while searching for other tests > without a .vgtest file, I noticed that memcheck/tests/metadata has a file > .vgtest-HIDING instead, which makes me curious. The facilities this tests (making an memcheck'd program able to read/write its own definedness bits) got disabled and has not been fixed -- I don't expect it to be useful. So the corresponding test needed to be disabled, and renaming the .vgtest file like this seemed as good a way as any. > The bottom line remains that I find the minimum expected number of errors, > which also remains good news. Good. J |
|
From: Paul P. <ppl...@gm...> - 2005-07-30 00:47:33
|
On AMD64 Red Hat Enterprise Linux AS release 3 (Taroon Update 2),
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-39)
make check fails to build:
/home/paul/valgrind-3.0.RC1/tests/cputest.c:103: undefined reference to `go=
'
collect2: ld returned 1 exit status
This is because this gcc uses -D__x86_64 rather then -D__amd64
Fix:
--- cputest.c.orig 2005-07-29 17:23:48.000000000 -0700
+++ cputest.c 2005-07-29 17:24:35.000000000 -0700
@@ -21,7 +21,7 @@
NULL
};
=20
-#ifdef __amd64
+#if defined(__amd64) || defined(__x86_64)
static Bool go(char* cpu)
{
if ( strcmp( cpu, "amd64" ) =3D=3D 0 )
Most of the tests fail:
=3D=3D 157 tests, 149 stderr failures, 2 stdout failures =3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
memcheck/tests/addressable (stderr)
memcheck/tests/badaddrvalue (stderr)
memcheck/tests/badfree-2trace (stderr)
memcheck/tests/badfree (stderr)
memcheck/tests/badjump (stderr)
memcheck/tests/badjump2 (stderr)
...
Looks like most of them are failing due to=20
Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading
which I reported earlier.
The 2 stdout failures are:
memcheck/tests/leakotron.stdout.diff:
*** leakotron.stdout.exp 2005-07-26 01:58:06.000000000 -0700
--- leakotron.stdout.out 2005-07-29 17:27:08.000000000 -0700
***************
*** 1 ****
! PASS
--- 1 ----
! FAILED: I freed everything, but there's still 4800 bytes reachable
none/tests/exec-sigmask.stdout.diff
*** exec-sigmask.stdout.exp 2005-07-26 01:58:34.000000000 -0700
--- exec-sigmask.stdout.out 2005-07-29 17:28:30.000000000 -0700
***************
*** 0 ****
--- 1 ----
+ full: signal 32 missing from mask
Cheers,
|
|
From: Nicholas N. <nj...@cs...> - 2005-07-30 01:24:46
|
On Fri, 29 Jul 2005, Paul Pluzhnikov wrote: > make check fails to build: > /home/paul/valgrind-3.0.RC1/tests/cputest.c:103: undefined reference to `go' > collect2: ld returned 1 exit status > > This is because this gcc uses -D__x86_64 rather then -D__amd64 I've committed a fix for this, thanks. N |
|
From: Nicholas N. <nj...@cs...> - 2005-08-03 13:22:06
|
On Fri, 29 Jul 2005, Paul Pluzhnikov wrote: > make check fails to build: > /home/paul/valgrind-3.0.RC1/tests/cputest.c:103: undefined reference to `go' > collect2: ld returned 1 exit status > > This is because this gcc uses -D__x86_64 rather then -D__amd64 I fixed that the other day. > Most of the tests fail: > == 157 tests, 149 stderr failures, 2 stdout failures ================= > memcheck/tests/addressable (stderr) > memcheck/tests/badaddrvalue (stderr) > memcheck/tests/badfree-2trace (stderr) > memcheck/tests/badfree (stderr) > memcheck/tests/badjump (stderr) > memcheck/tests/badjump2 (stderr) > ... > > Looks like most of them are failing due to > Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI reading > which I reported earlier. Julian fixed that, too. N |
|
From: Paul P. <ppl...@gm...> - 2005-08-03 15:26:25
|
On 8/3/05, Nicholas Nethercote <nj...@cs...> wrote:
> > Warning: zero-sized CIE/FDE but not at section end in DWARF2 CFI readi=
ng
>=20
> Julian fixed that, too.
The new regtest results from that system:
=3D=3D 159 tests, 8 stderr failures, 1 stdout failure =3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
memcheck/tests/leakotron (stdout)
memcheck/tests/pointer-trace (stderr)
memcheck/tests/sigprocmask (stderr)
memcheck/tests/strchr (stderr)
memcheck/tests/vgtest_ume (stderr)
memcheck/tests/weirdioctl (stderr)
memcheck/tests/xml1 (stderr)
none/tests/faultstatus (stderr)
none/tests/fdleak_fcntl (stderr)
The "interesting" diffs are:
*** vgtest_ume.stderr.exp 2005-07-02 15:43:03.000000000 -0700
--- vgtest_ume.stderr.out 2005-08-03 07:41:05.000000000 -0700
***************
*** 4 ****
! Hello, world!
--- 4,5 ----
! Warning: client syscall mmap2 tried to modify addresses 0x........-0x....=
....
! valgrind: mmap(0x........, 4096) failed in UME.
*** weirdioctl.stderr.exp 2005-07-02 15:42:58.000000000 -0700
--- weirdioctl.stderr.out 2005-08-03 07:41:06.000000000 -0700
***************
*** 3,4 ****
! by 0x........: __libc_start_main (in /...libc...)
! by 0x........: ...
--- 3,8 ----
! by 0x........: main (weirdioctl.c:28)
! Address 0x........ is on thread 1's stack
!=20
! Syscall param ioctl(TCSET{A,AW,AF}) points to uninitialised byte(s)
! at 0x........: ioctl (in /...libc...)
! by 0x........: main (weirdioctl.c:43)
*** xml1.stderr.exp64 2005-08-03 07:33:52.000000000 -0700
--- xml1.stderr.out 2005-08-03 07:41:09.000000000 -0700
***************
*** 353,364 ****
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <fn>__libc_start_main</fn>
- </frame>
- <frame>
- <ip>0x........</ip>
- <obj>...</obj>
- <dir>...</dir>
- <file>start.S</file>
- <line>...</line>
- </frame>
--- 352 ----
*** faultstatus.stderr.exp 2005-07-02 15:43:44.000000000 -0700
--- faultstatus.stderr.out 2005-08-03 07:41:37.000000000 -0700
***************
*** 6,12 ****
- Test 5: PASS
- Test 6: PASS
- Test 7: PASS
- Test 8: PASS
- Test 9: disInstr: unhandled instruction bytes: 0x........ 0x........
0x........ 0x........
- at 0x........: test9 (faultstatus.c:127)
- FAIL: expected signal 11, not 4
--- 5 ----
(Looks like new faultstatus.stderr.exp64 is needed for that last one).
Cheers,
|