I'm a big fan of Valgrind and I use it to check all my programs. Now that I'm switching to an amd 64 platform, I'm wondering if there is a chance that one day this architecture will be supported. Thanks you for you great job.
Would you be willing to make a small donation for it? Because I would. If enough of us (a score perhaps or more) get together perhaps we could scrounge up enough to sponsor the port. Of course I'm talking about full fledged, using all the registers (x87 and xmm notably) to our optimal advantage port, not running valgrind in emulation or legacy, I can do that now (:
(there's four people that've voted for this bug so far and the reporter who hasnt voted (no surprise)...Nick and Julian have others contacted you off-list that might be thinking the same thing I am? I know I asked Nick about it, I might not be the only one with the notion (if there isn't someone currently working on the port))
I would be willing to kick in 50 bucks, absolutely. I might also be able to arrange shell access to an x86-64 box (gentoo w/ gcc 3.3.3) at some prearranged times. If donations would actually motivate things, though, I'd rather see code coverage functionality implemented first. ;>
Yeah that would be cool (-: From what I see in massif, it's not a far off concept. As for donations ability to motivate things, I don't know. I think (unless a deluge of donators comes up with a huge load of cash) you have to have a developer already somewhere who is at least mostly capable of the port so that the money 'needed' to sway it is only enough to reprioritize things and not enough to hire and train and then motivate a full time dev (: But I'm being hopeful, and also a little curious. It couldn't hurt to try. As for the box, I too can donate an account on a gentoo/amd64 box. I could probably keep the time restrictions to a minimum, too, but it's the system resources that won't be 100% available all the time (since contrary to popular belief I do use my boxen on occasion d=) And of course I'm sure there's dozens if not thousands who would at least be willing to lend a hand by 'testing' (a pretty term we qa folks use for 'snatching up as soon as you can get your grubby hands on'). Seriously though
I really don't think money is the issue here people. If nobody else gets there before me then it's quite likely that I will look at this in due course, and I already have access to an appropriate machine. The main issues are the time to do it, but that isn't going to be resolved with offers of cash, and more importantly there is the fact that the core developers are still trying to work out how best to support multiple platforms and/or architectures and I'm reluctant to do to much work in this direction until that is resolved.
I agree with your comment. I've started looking at valgrind architecture and I've read that it will be added some abstraction layer to support multiple platforms. It is better to wait for this feature to implement the x86_64 support. Concerning the donation, I will be glad to offer some dollars/euros/beers to the developers if they support the x86_64 architecture ;)
I'm also willing to kick in for a amd64 valgrind, if it would help. I'd spoken with Julian Seward about this in Feb 2004 and this was the response I received: >Many people have asked for an x86-64 port; for sure it is the >most frequently asked-for port. We find ourselves in a difficult >position over this. The initial port away from x86 will involve >some overhead in generalising the framework to support a different >cpu architecture. > >We've studied the problems involved in some detail, so we have >a good idea what's required. However, I'd say it's a significant >amount of work, even for one experienced in the art of compiler >hacking (me . It might take a couple of months to bend the >existing framework to support x86-64, but that is basically a >dead-end line of development -- what we want to do is install >a generic porting framework, and use it to build ports for >x86-64, powerpc, and whatever else, on that framework. > >So, realistically, you need to be considering buying, I'd say, >four months of skilled engineering time to get a decent implementation >of what you want. One possibility is for you to join with >other companies wanting an x86-64 port and share the costs. Paying for 4 months of skilled dev time isn't going to be cheap, at the very least, 10k? I can't quite ante up that amount of cash, but I would be willing to put 1k into the pot. Any others?
*** Bug 91392 has been marked as a duplicate of this bug. ***
*** Bug 91695 has been marked as a duplicate of this bug. ***
I, too, would like x86-64 support in valgrind :) I have an x86-64 box (personal one) connected via broadband (256Kb upstream, 3Mb downstream) that I could set up an account on for a developer. It runs SuSE 9.2 Professional x86-64 and I have full control of it and would have few/no time restrictions on it for a developer. Of course, it's not so hard to get x86-64 hardware these days, but I figured I'd offer in case there was some issue on your end. I could even kick in $100.
*** Bug 100197 has been marked as a duplicate of this bug. ***
An update: Julian is working on this. He has Hello World running on AMD64. Progress is being made, please be patient. Hopefully something will be made publically avaiable in the next couple of months.
where can I see the diffs to the current working process of this? I'm just curious :D
The web site (www.valgrind.org) has instructions on how to checkout the current code for valgrind 3 from the subversion repository.
ai, that's nice. I though you're on KDE's repository? (That's why I didn't find any x64 port branches?) I mean, they're about to migrate to SVN in a day anyway. > svn co svn://svn.valgrind.org/vex/trunk > svn co svn://svn.valgrind.org/valgrind/trunk > cd vex/trunk && make clean version all > cd valgrind/trunk > .... according to those lines from your website.. hmm... okay, this is wondering me because `svn co` this way creates a trunk dir, not a vex/trunk nor valgrind/trunk. At least my subversion client (svn 1.1.3) so. these shall be the right lines: ! svn co svn://svn.valgrind.org/vex/trunk vex ! svn co svn://svn.valgrind.org/valgrind/trunk valgrind ! cd vex && make clean version all ! cd valgrind ! .... cya.
*** Bug 105554 has been marked as a duplicate of this bug. ***
any new fancy NEWS updates available? how's the state of progress? thanks ;-) christian.
If you're keen, check out the valgrind.org SVN repository (not the KDE one!) and try it. Memcheck, Cachegrind and Massif are all working at least to some extent -- most of the regression tests are passing. But don't be surprised if it's not all smooth sailing.
I was going to say something to the same effect, but with respect to "try it", even after Julian's latest stack definedness fix I still get the race where valgrind jumps to 98% cpu and 4095G virtual address space upon startup (in all test cases) and stays there until about a minute (worth of cpu time) _after_ being killed. No idea how to debug that - rough guess would be some system call or the like that can vary between my environment and Julian's. Past offers of assistance and resources to both of you still stand.
Well, it works pretty well for me on SuSE 9.2 on amd64, as that's what I've been hacking on :-) Pretty well means, for example, on Memcheck I can run Mozilla, Konqueror, tons of FP code, pretty much anything that is installed as part of 9.2, and it works OK. Re #19, what kind of setup are you running on? I can quite believe there is something screwy in the address space management which needs to be sorted out. At this point, if people tested it on different amd64-linux distros and reported which ones work and which don't, that would be a useful collective exercise.
1) why do I *explicitely* have to EXTRA_CFLAGS/C[XX]FLAGS="-fPIC" for compiling/linking? (it won't link valgrind otherwise) 2) when running my fresh built ./valgrind (right after make install), it eats up my CPUs (gkrellm says: alternately) however, I had to take lots of time to get it killed then. Is valgrind *not* SMP safe? host specs: Gentoo Linux (fully 64bit compiled) with 2x AMD Opteron 248 CPUs, and 4x 1GB RAM.
What happens if you give --disable-pie to the configure script? Does that help? J > 2) when running my fresh built ./valgrind (right after make install), it > eats up my CPUs (gkrellm says: alternately) > > however, I had to take lots of time to get it killed then. > > Is valgrind *not* SMP safe? > > host specs: Gentoo Linux (fully 64bit compiled) with 2x AMD Opteron 248 > CPUs, and 4x 1GB RAM.
Yes, that helps. Immensely. Doing a regtest now.
This is on an in-house linux-2.6 opteron (1x248C0) glibc-2.3.5 sandbox. I hadn't thought along the lines of --disable-pie since I was expecting the error that trapni apparently got to let me know if there was a PIC/non-PIC related problem. Anyway, thanks for the tip. Several tests had to be killed by the monitor kernel (I think they tended to have to do with threading/forking...) Overall, essentially the same results you've seen. Good work. == 153 tests, 24 stderr failures, 10 stdout failures ================= memcheck/tests/addressable (stdout) memcheck/tests/addressable (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stdout) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) none/tests/async-sigs (stdout) none/tests/async-sigs (stderr) none/tests/coolo_sigaction (stdout) none/tests/coolo_sigaction (stderr) none/tests/exec-sigmask (stderr) none/tests/faultstatus (stderr) none/tests/fork (stdout) none/tests/fork (stderr) none/tests/syscall-restart1 (stderr) none/tests/syscall-restart2 (stderr) none/tests/thread-exits (stdout) none/tests/thread-exits (stderr) none/tests/threaded-fork (stdout) none/tests/yield (stdout)
vex iropt: fold_Expr: no rule for: 1Uto64(0:I1) 0:I1 vex: the `impossible' happened... Need any other info than that?
The amd64 port seems to run fine on most programs here. However the code we are working on gives us a: vex amd64->IR: unhandled instruction bytes: 0x34 0x1 0x41 0x88
SuSE 9.1 x86_64 VEX: Rev. 1198 valgrind: Rev. 3756 ==15275== Memcheck, a memory error detector. ==15275== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==15275== Using LibVEX rev 1198, a library for dynamic binary translation. ==15275== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==15275== Using valgrind-3.0.0.SVN, a dynamic binary instrumentation framework. ==15275== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==15275== For more details, rerun with: -v ==15275== vex amd64->IR: unhandled instruction bytes: 0x92 0xC3 0x90 0x90 ==15275== ==15275== Process terminating with default action of signal 4 (SIGILL): dumping core ==15275== Illegal opcode at address 0x1190FA28 ==15275== at 0x1190FA28: strcmp (in /lib64/ld-2.3.3.so) ==15275== by 0x1190B654: _dl_name_match_p (in /lib64/ld-2.3.3.so) ==15275== by 0x11906087: _dl_map_object (in /lib64/ld-2.3.3.so) ==15275== by 0x11902CB3: dl_main (in /lib64/ld-2.3.3.so) ==15275== by 0x1190E3FC: _dl_sysdep_start (in /lib64/ld-2.3.3.so) ==15275== by 0x1190144A: _dl_start (in /lib64/ld-2.3.3.so) ==15275== by 0x11900CD7: (within /lib64/ld-2.3.3.so) ==15275==
> ------- Additional Comments From mg_abimail yahoo com 2005-05-17 07:55 > ------- vex iropt: fold_Expr: no rule for: 1Uto64(0:I1) > 0:I1 > vex: the `impossible' happened... > > Need any other info than that? Yes. Missing folding rules don't kill vex, so there must be some other reason for the 'impossible' to happen. Did you delete some lines close to the end of the log? I suspect the instruction selector barfed, but that's not clear from what you sent.
> I hadn't thought along the lines of --disable-pie since I was I'm inclined to make --disable-pie the default. It causes problems on both x86 and amd64 for various distros and I have no idea how to fix them. Volunteers?
> vex amd64->IR: unhandled instruction bytes: 0x92 0xC3 0x90 0x90 It's not entirely clear what instruction that was intended to be. Could you disassemble the relevant section of code and send it to me? You may find it useful to run with --trace-flags=10000000 to see what Valgrind thought the instructions leading up to this one were.
In message <20050517102658.26241.qmail@ktown.kde.org> Julian Seward <jseward@acm.org> wrote: > > I hadn't thought along the lines of --disable-pie since I was > > I'm inclined to make --disable-pie the default. It causes problems > on both x86 and amd64 for various distros and I have no idea how to > fix them. Volunteers? The problem is that it severely restricts the address space available to the client program, especially on amd64. I've been using PIE builds on amd64 without too much trouble other than having to increase the number of auxiliary maps. The main problem is with systems with older tool chains and amd64 systems will normally have fairly new ones. That said, one of last night's commits seems to have broken PIE builds as I was getting asserting in the auxmap code this morning. I haven't had a chance to investigate yet though. Tom
In message <20050517102947.27592.qmail@ktown.kde.org> Julian Seward <jseward@acm.org> wrote: > > vex amd64->IR: unhandled instruction bytes: 0x92 0xC3 0x90 0x90 > > It's not entirely clear what instruction that was intended to be. > Could you disassemble the relevant section of code and send it to > me? You may find it useful to run with --trace-flags=10000000 > to see what Valgrind thought the instructions leading up to this > one were. It's "xchg %rdx, %rax" if I'm reading the arch manual right. It might be "xchg %r10, %rax" if there is a REX prefix but I think that would have shown in the error wouldn't it? Tom
Please update your VEXs to r1200 and try again. This should fix: * #27 (Achim Herwig, unhandled 0x92 0xC3 0x90 0x90) * #26 (Christoph Bartoschek, unhandled 0x34 0x1 0x41 0x88) Confirmation that these fixes would OK would be appreciated.
Re #25, #28 (Mark Gilbert): I'd like to fix this, but I need a more complete log to see what really happened. Can you send one?
Is the AMD64 version of valgrind expected to work under EM64T? It builds nicely, but when running, I get: Memcheck: mc_translate.c:2436 (isBogusAtom): Assertion 'isIRAtom(at)' failed. ==21114== at 0x7FB002D139: ??? Basic block ctr is approximately 0 sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==21114== at 0x1402600A80: (within /lib64/ld-2.3.3.so) (svn revision 3767)
> ------- Is the AMD64 version of valgrind expected to work under EM64T? Yes. > Memcheck: mc_translate.c:2436 (isBogusAtom): Assertion 'isIRAtom(at)' > failed. ==21114== at 0x7FB002D139: ??? Interesting. That's the second time I've seen that in the past 24 hours. Can you help out here? mc_translate.c:2436 for me says this: tl_assert(isIRAtom(at)); Can you put this in front of it: if (!isIRAtom(at)) { VG_(printf)("failing on: "); ppIRAtom(at); VG_(printf)("\n"); } and send me what it prints out? J
> Can you put this in front of it: > > if (!isIRAtom(at)) { > VG_(printf)("failing on: "); > ppIRAtom(at); > VG_(printf)("\n"); > } Hmm. That should be ppIRExpr(at), not ppIRAtom(at). But now I have a different question: are both your Valgrind and VEX trees completely up to date? I suspect this is caused by them not being in sync. Does the problem go away if you svn up both of them and completely rebuild everything from scratch? J
My bad, you're absolutely right, my vex was extremely old. But I'm now having other problems: gcc -fpie -m64 -fomit-frame-pointer -DELFSZ=64 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -o stage2 -Wl,--export-dynamic -g -Wl,-version-script ./valgrind.vs -Wl,--whole-archive m_replacemalloc/libreplacemalloc_core.a -Wl,--no-whole-archive -pie m_debuglog.o m_errormgr.o m_execontext.o m_hashtable.o m_mallocfree.o m_options.o m_skiplist.o m_stacktrace.o m_tooliface.o m_translate.o m_transtab.o ume.o vg_scheduler.o vg_main.o vg_messages.o vg_mylibc.o vg_dummy_profile.o vg_signals.o vg_symtab2.o vg_threadmodel.o vg_pthreadmodel.o vg_redir.o vg_dwarf.o vg_stabs.o vg_symtypes.o m_dispatch/libdispatch.a m_demangle/libdemangle.a m_aspacemgr/libaspacemgr.a m_sigframe/libsigframe.a m_syscalls/libsyscalls.a amd64-linux/libplatform.a amd64/libarch.a linux/libos.a /home.local/zeev/vex/libvex.a -ldl /usr/bin/ld: /home.local/zeev/vex/libvex.a(irdefs.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC /home.local/zeev/vex/libvex.a: could not read symbols: Bad value --- If I try to build vex with -fPIC, I'm getting: Memcheck: mc_main.c:268 (find_or_alloc_in_auxmap): the 'impossible' happened. ==5544== at 0x7FB002D3B9: ??? Basic block ctr is approximately 68337 sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==5544== at 0x1402D2276C: mmap (in /lib64/tls/libc-2.3.3.so) ==5544== by 0x1402C88E5E: _nl_load_locale_from_archive (in /lib64/tls/libc-2.3.3.so) ==5544== by 0x1402C87FBF: _nl_find_locale (in /lib64/tls/libc-2.3.3.so) ==5544== by 0x1402C87A15: setlocale (in /lib64/tls/libc-2.3.3.so) ==5544== by 0x406B09: (within /bin/ls) ==5544== by 0x1402C7E4C9: __libc_start_main (in /lib64/tls/libc-2.3.3.so) ==5544== by 0x4028F9: (within /bin/ls)
> Please update your VEXs to r1200 and try again. This should > fix: > > * #27 (Achim Herwig, unhandled 0x92 0xC3 0x90 0x90) > * #26 (Christoph Bartoschek, unhandled 0x34 0x1 0x41 0x88) > > Confirmation that these fixes would OK would be appreciated. SuSE 9.1 x86_64 Vex Rev. 1201 Valgrind Rev. 3767 seems to work. Thanks a lot!
> On Wednesday 18 May 2005 14:33, Zeev Suraski wrote: > If I try to build vex with -fPIC, I'm getting: Uh, you need to configure with --disable-pie. Try that. pie builds just seem to give trouble on amd64. Tom Hughes might have further insight on that front. J
In message <20050518133330.18205.qmail@ktown.kde.org> Zeev Suraski <zeev-kdebugs@zend.com> wrote: > My bad, you're absolutely right, my vex was extremely old. But I'm now having other problems: > > gcc -fpie -m64 -fomit-frame-pointer -DELFSZ=64 -Wmissing-prototypes -Winline -Wall -Wshadow -O -g -Wno-long-long -o stage2 -Wl,--export-dynamic -g -Wl,-version-script ./valgrind.vs -Wl,--whole-archive m_replacemalloc/libreplacemalloc_core.a -Wl,--no-whole-archive -pie m_debuglog.o m_errormgr.o m_execontext.o m_hashtable.o m_mallocfree.o m_options.o m_skiplist.o m_stacktrace.o m_tooliface.o m_translate.o m_transtab.o ume.o vg_scheduler.o vg_main.o vg_messages.o vg_mylibc.o vg_dummy_profile.o vg_signals.o vg_symtab2.o vg_threadmodel.o vg_pthreadmodel.o vg_redir.o vg_dwarf.o vg_stabs.o vg_symtypes.o m_dispatch/libdispatch.a m_demangle/libdemangle.a m_aspacemgr/libaspacemgr.a m_sigframe/libsigframe.a m_syscalls/libsyscalls.a amd64-linux/libplatform.a amd64/libarch.a linux/libos.a /home.local/zeev/vex/libvex.a -ldl > > /usr/bin/ld: /home.local/zeev/vex/libvex.a(irdefs.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC > /home.local/zeev/vex/libvex.a: could not read symbols: Bad value If you do a PIE build of valgrind you need to use EXTRA_CFLAGS="-fpie" when you build vex. > If I try to build vex with -fPIC, I'm getting: > > Memcheck: mc_main.c:268 (find_or_alloc_in_auxmap): the 'impossible' happened. > ==5544== at 0x7FB002D3B9: ??? You've blown the limit on the number of auxiliary maps because in PIE builds most shared libraries load above the point where memcheck has to use auxmaps. Increase the limit in the code and recompile and it should work. Tom
Works fine now - thanks!
> Tom H: > You've blown the limit on the number of auxiliary maps because in PIE > builds most shared libraries load above the point where memcheck has > to use auxmaps. Increase the limit in the code and recompile and it > should work. Ah, ok. What value do you need to set it to? Also, whereabouts in the address space are these shared libraries getting loaded right now? In general hitting the auxmaps hard is not good for performance. Hmm. What I intended was, when aspacemgr is rewritten to be more flexible in layout, it can force the shared libraries to load below 16G (that being the current waterline) and so the slowness of the auxmaps is avoided. J
In message <20050518140238.12597.qmail@ktown.kde.org> Julian Seward <jseward@acm.org> wrote: >> You've blown the limit on the number of auxiliary maps because in PIE >> builds most shared libraries load above the point where memcheck has >> to use auxmaps. Increase the limit in the code and recompile and it >> should work. > > Ah, ok. What value do you need to set it to? I've got it set to 5000 but that was entirely arbitrary. > Also, whereabouts in the address space are these shared libraries > getting loaded right now? Well on FC3 prelinked ones seem to wind up around 0x3c70000000 or so and non-prelinked ones (and other arbitrary mmaps) around 0x2a0000000000 or so. > In general hitting the auxmaps hard is not good for performance. > Hmm. What I intended was, when aspacemgr is rewritten to be > more flexible in layout, it can force the shared libraries to load > below 16G (that being the current waterline) and so the slowness > of the auxmaps is avoided. I guess the plan was probably to do something along those lines. Tom
> * #27 (Achim Herwig, unhandled 0x92 0xC3 0x90 0x90) > * #26 (Christoph Bartoschek, unhandled 0x34 0x1 0x41 0x88) > Confirmation that these fixes would OK would be appreciated. Number #26 seems to work fine. However using vex revision 1201 and valgrind revision 3756 I get: valgrind: vg_symtab2.c:387 (vgPlain_addCfiSI): Assertion 'cfisi->len > 0 && cfisi->len < 1000000' failed. Revision 3774 of valgrind does not compile.
In message <20050519072844.24666.qmail@ktown.kde.org> Christoph Bartoschek <bartoschek@gmx.de> wrote: > Number #26 seems to work fine. However using vex revision 1201 and > valgrind revision 3756 I get: > > valgrind: vg_symtab2.c:387 (vgPlain_addCfiSI): Assertion 'cfisi->len > > 0 && cfisi->len < 1000000' failed. That's related to the stack unwind information in your program. It is claiming a single set of unwind rules that cover a rather large region of your code. It might be a bug in valgrind's CFI reader. > Revision 3774 of valgrind does not compile. Try 3775 instead - I've just fixed the breakage. Tom
btw, why is valgrind not (yet?) switched back to the main KDE repositories - as they've svn since some time now, too? thx, Christian.
> Christoph Bartoschek <bartoschek gmx de> wrote: > > Number #26 seems to work fine. However using vex revision 1201 and > > valgrind revision 3756 I get: > > > > valgrind: vg_symtab2.c:387 (vgPlain_addCfiSI): Assertion 'cfisi->len > > > 0 && cfisi->len < 1000000' failed. > > It might be a bug in valgrind's CFI reader. Yes. Can you figure out which .so this is happening on? (run with -v and look for the "Reading syms from ..." line immediately prior to the crash). Then, send both: * The output from running V with --trace-cfi=yes (this will be huge) * The output of readelf --debug-dump=frames the_relevant.so (also huge) I might be able to figure out what's going on from that info.
> why is valgrind not (yet?) switched back to the main KDE repositories - as > they've svn since some time now, too? We're not going to switch back. We wanted to have the repo at valgrind.org.
On Thursday 19 May 2005 3:02 pm, Nicholas Nethercote wrote: > > why is valgrind not (yet?) switched back to the main KDE repositories - > > as they've svn since some time now, too? > > We're not going to switch back. We wanted to have the repo at > valgrind.org. why this extra-role? you're a part/sub project of KDE e.v. (AFAIK), so you've started there, but yet want your own svn repos? (which makes extra work effords?) I do not understand. Christian Parpart.
Created attachment 11119 [details] Standard log from failed run This was a run using valgrind and vex uptodate as of a few minutes ago.
Created attachment 11120 [details] bzip2ed trace log from failed run Same run as attachment 11119 [details], but with --trace-flags=10000000. BZipped for your convenience.
Julian, hope this is more helpful, sorry for the delay.
Mark -- I just added a folding rule for 1Uto64. Update your vex (to r1202) and try again. -- J
This fixes it. I would've answered you earlier, but I wanted to get you better regtest info. Aside from my large production programs which now work, here are the regtest results. The ones which needed to be cut off from the cpu were pth_atfork, coolo_sigaction, and threaded-fork. Which I see as an improvement (assuming the others from the earlier trials now merely segfault). Good work! == 153 tests, 24 stderr failures, 10 stdout failures ================= memcheck/tests/addressable (stdout) memcheck/tests/addressable (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/sigaltstack (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stdout) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) corecheck/tests/pth_atfork1 (stdout) corecheck/tests/pth_atfork1 (stderr) none/tests/async-sigs (stdout) none/tests/async-sigs (stderr) none/tests/coolo_sigaction (stdout) none/tests/coolo_sigaction (stderr) none/tests/exec-sigmask (stderr) none/tests/faultstatus (stderr) none/tests/fork (stdout) none/tests/fork (stderr) none/tests/syscall-restart1 (stderr) none/tests/syscall-restart2 (stderr) none/tests/thread-exits (stdout) none/tests/thread-exits (stderr) none/tests/threaded-fork (stdout) none/tests/yield (stdout)
../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:138: __libc_fork: Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (((size_t) &((struct pthread *)0)->tid))); else if (sizeof (__value) == 4) asm volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); else { if (sizeof (__value) != 8) abort (); asm volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (((size_t) &((struct pthread *)0)->tid))); } __value; }) != ppid' failed. vex amd64->IR: unhandled instruction bytes: 0xF4 0xBF 0x7F 0x0 That was the only (internal) error message vex/valgrind printed. Let me know if I have to do a trace run or you need some other info.
> ------- Additional Comments From mg_abimail yahoo com 2005-06-01 07:42 > ------- ../nptl/sysdeps/unix/sysv/linux/x86_64/../fork.c:138: __libc_fork: > Assertion `({ __typeof (self->tid) __value; if (sizeof (__value) == 1) asm > volatile ("movb %%fs:%P2,%b0" : "=q" (__value) : "0" (0), "i" (((size_t) > &((struct pthread *)0)->tid))); else if (sizeof (__value) == 4) asm > volatile ("movl %%fs:%P1,%0" : "=r" (__value) : "i" (((size_t) &((struct > pthread *)0)->tid))); else { if (sizeof (__value) != 8) abort (); asm > volatile ("movq %%fs:%P1,%q0" : "=r" (__value) : "i" (((size_t) &((struct > pthread *)0)->tid))); } __value; }) != ppid' failed. > vex amd64->IR: unhandled instruction bytes: 0xF4 0xBF 0x7F 0x0 0xF4 is HLT which isn't valid in user-mode, aiui. It suggests your program was already hosed by this point, possibly as a result of the assertion failure. Can you see if you can package this up in an easy-to-reproduce way?
The program was segfaulting, yes (-: I figured I'd try and see if vg was stable enough to provide any insight. I'll see what I can do about an easy-to-reproduce test case for you, but it may take a couple days.
The vex problem (not the original segv) was occurring in the signal handler that caught the segv, but I've been completely unable to distill a small testcase which reliably reproduces the bug, with one exception. I ran into the same problem with AbiWord, which has a somewhat similar signal handler, when it (reproduceably) segfaulted in testing. It isn't small, but it is public and reliable. See the program's ap_UnixApp.cpp for catchSignals(int) [iirc]. I'm sorry that it's the best I can do for now. Unless you want me to provide a static build of AbiWord and instructions for crashing it (-: I'm not sure what else I can do for you. I tried skimming it down to a signal handler _without_ a word processor attached but valgrind would just report the error and exit normally (no unhandled HLT). I also tried mucking around with some compiler settings to replicate that end of it from the original encounter with the bug, but no luck.
I've receiving you just fine! ---John On 3 Jun 2005 18:48:04 -0000, Mark Gilbert <mg_abimail@yahoo.com> wrote: [bugs.kde.org quoted mail]
I'm receiving you just fine! ---John On 3 Jun 2005 18:48:04 -0000, Mark Gilbert <mg_abimail@yahoo.com> wrote: [bugs.kde.org quoted mail]
I've tried an svn checkout on a dual Opteron 246 system running FC2 with a vanilla 2.6.11.3 kernel. Everything builds fine but valgrind dies parsing command line options. Unfortunately, this happens before "--wait-for-gdb" takes effect, so there's no way for me to find out where this is occuring. The only clue is that valgrind prints out "valgrind: Bad option '*'; aborting." where '*' is a sequence of control characters. The characters are repeatable for a given invocation but vary as different command line options are used. I was able to run most of the regtest suite (output below). Any clue on how to proceed? /usr/bin/perl tests/vg_regtest memcheck cachegrind corecheck massif lackey none -- Running tests in memcheck/tests ------------------------------------ addressable: valgrind ./addressable badaddrvalue: valgrind -q ./badaddrvalue badfree-2trace: valgrind --num-callers=2 -q ./badfree badfree: valgrind -q ./badfree badjump: valgrind ./badjump badjump2: valgrind -q ./badjump2 badloop: valgrind -q ./badloop badpoll: valgrind -q ./badpoll badrw: valgrind -q ./badrw brk: valgrind ./brk brk2: valgrind ./brk2 buflen_check: valgrind -q ./buflen_check clientperm: valgrind -q ./clientperm custom_alloc: valgrind -q ./custom_alloc describe-block: valgrind ./describe-block doublefree: valgrind -q ./doublefree error_counts: valgrind --log-fd=-1 ./error_counts errs1: valgrind -q ./errs1 execve: valgrind -q ./execve execve2: valgrind -q --trace-children=yes ./execve2 exitprog: valgrind -q ./exitprog fprw: valgrind -q ./fprw fwrite: valgrind -q ./fwrite inits: valgrind -q ./inits inline: valgrind -q ./inline leak-0: valgrind ./leak-0 leak-cycle: valgrind --leak-resolution=high ./leak-cycle leak-regroot: valgrind ./leak-regroot leak-tree: valgrind --leak-resolution=high ./leak-tree leakotron: valgrind ./leakotron malloc1: valgrind -q ./malloc1 malloc2: valgrind -q ./malloc2 malloc3: valgrind -q ./malloc3 manuel1: valgrind -q ./manuel1 manuel2: valgrind -q ./manuel2 manuel3: valgrind -q ./manuel3 match-overrun: valgrind --suppressions=match-overrun.supp ./match-overrun memalign2: valgrind -q ./memalign2 memalign_test: valgrind -q ./memalign_test memcmptest: valgrind -q ./memcmptest mempool: valgrind -q --leak-check=yes ./mempool mismatches: valgrind -q ./mismatches mmaptest: valgrind -q ./mmaptest nanoleak: valgrind --leak-check=yes -q ./nanoleak nanoleak_supp: valgrind --leak-check=yes --suppressions=nanoleak.supp -q ./nanoleak new_nothrow: valgrind -q ./new_nothrow new_override: valgrind ./new_override null_socket: valgrind -q ./null_socket overlap: valgrind -q ./overlap pointer-trace: valgrind --leak-check=yes ./pointer-trace post-syscall: valgrind ./post-syscall realloc1: valgrind -q ./realloc1 realloc2: valgrind -q ./realloc2 realloc3: valgrind -q ./realloc3 sigaltstack: valgrind -q ./sigaltstack *** sigaltstack failed (stderr) *** signal2: valgrind -q ./signal2 sigprocmask: valgrind -q ./sigprocmask *** sigprocmask failed (stderr) *** str_tester: valgrind -q ./str_tester strchr: valgrind -q ./strchr *** strchr failed (stderr) *** supp1: valgrind --suppressions=supp.supp -q ./supp1 supp2: valgrind --suppressions=supp.supp -q ./supp2 suppfree: valgrind -q ./suppfree toobig-allocs: valgrind ./../../tests/toobig-allocs trivialleak: valgrind --leak-check=yes -q ./trivialleak vgtest_ume: valgrind -q ./vgtest_ume *** vgtest_ume failed (stderr) *** weirdioctl: valgrind -q ./weirdioctl < weirdioctl.c *** weirdioctl failed (stderr) *** writev: valgrind -q ./writev xml1: valgrind --xml=yes ./xml1 *** xml1 failed (stderr) *** zeropage: valgrind -q ./zeropage -- Finished tests in memcheck/tests ------------------------------------ -- Running tests in cachegrind/tests ---------------------------------- chdir: valgrind ./chdir dlclose: valgrind ./dlclose -- Finished tests in cachegrind/tests ---------------------------------- -- Running tests in corecheck/tests ----------------------------------- as_mmap: valgrind ./as_mmap as_shm: valgrind ./as_shm erringfds: valgrind ./erringfds fdleak_cmsg: valgrind --track-fds=yes ./fdleak_cmsg < /dev/null fdleak_creat: valgrind --track-fds=yes ./fdleak_creat < /dev/null fdleak_dup: valgrind --track-fds=yes ./fdleak_dup < /dev/null fdleak_dup2: valgrind --track-fds=yes ./fdleak_dup2 < /dev/null fdleak_fcntl: valgrind --track-fds=yes ./fdleak_fcntl < /dev/null *** fdleak_fcntl failed (stderr) *** fdleak_ipv4: valgrind --track-fds=yes ./fdleak_ipv4 < /dev/null fdleak_open: valgrind --track-fds=yes ./fdleak_open < /dev/null fdleak_pipe: valgrind --track-fds=yes ./fdleak_pipe < /dev/null fdleak_socketpair: valgrind --track-fds=yes ./fdleak_socketpair < /dev/null pth_atfork1: valgrind ./pth_atfork1 pth_cancel1: valgrind ./pth_cancel1 pth_cancel2: valgrind ./pth_cancel2 pth_cvsimple: valgrind ./pth_cvsimple pth_empty: valgrind ./pth_empty pth_exit: valgrind ./pth_exit pth_exit2: valgrind ./pth_exit2 pth_mutexspeed: valgrind ./pth_mutexspeed pth_once: valgrind ./pth_once pth_rwlock: valgrind ./pth_rwlock res_search: valgrind -q ./res_search www.yahoo.com sigkill: valgrind ./sigkill stack_changes: valgrind -q ./stack_changes threadederrno: valgrind -q ./threadederrno vgprintf: valgrind ./vgprintf -- Finished tests in corecheck/tests ----------------------------------- -- Running tests in massif/tests -------------------------------------- toobig-allocs: valgrind ./../../tests/toobig-allocs true_html: valgrind --format=html ./../../tests/true true_text: valgrind --format=text ./../../tests/true -- Finished tests in massif/tests -------------------------------------- -- Running tests in lackey/tests -------------------------------------- true: valgrind ./../../tests/true -- Finished tests in lackey/tests -------------------------------------- -- Running tests in none/tests ---------------------------------------- -- Running tests in none/tests/amd64 ---------------------------------- insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_sse: valgrind ./insn_sse insn_sse2: valgrind ./insn_sse2 -- Finished tests in none/tests/amd64 ---------------------------------- args: valgrind ./args a b "1 2 3" async-sigs: valgrind ./async-sigs bitfield1: valgrind ./bitfield1 blockfault: valgrind ./blockfault closeall: valgrind ./closeall cmdline1: valgrind --help --tool=none cmdline2: valgrind --help-debug --tool=none cmdline3: valgrind cmdline4: valgrind --bad-bad-option ./../../tests/true cmdline5: valgrind ./no-such-program-my-friend cmdline6: valgrind ./cmdline6.vgtest coolo_sigaction: valgrind ./coolo_sigaction coolo_strlen: valgrind ./coolo_strlen discard: valgrind ./discard exec-sigmask: valgrind ./exec-sigmask execve: valgrind ./execve faultstatus: valgrind ./faultstatus *** faultstatus failed (stderr) *** fcntl_setown: valgrind ./fcntl_setown floored: valgrind ./floored fork: valgrind -q ./fork fucomip: valgrind ./fucomip gxx304: valgrind ./gxx304 manythreads: valgrind ./manythreads map_unaligned: valgrind ./map_unaligned map_unmap: valgrind --sanity-level=3 ./map_unmap mq: valgrind ./mq mremap: valgrind ./mremap munmap_exe: valgrind ./munmap_exe pending: valgrind ./pending pth_blockedsig: valgrind ./pth_blockedsig pth_stackalign: valgrind ./pth_stackalign rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile selfrun: (skipping, prereq failed: grep '^#define HAVE_PIE 1' ../../config.h > /dev/null) sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts sigstackgrowth: valgrind --sanity-level=3 ./sigstackgrowth smc1: valgrind ./smc1 stackgrowth: valgrind --sanity-level=3 ./stackgrowth susphello: (skipping, prereq failed: false) syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system thread-exits: valgrind ./thread-exits threaded-fork: valgrind ./threaded-fork tls: valgrind ./tls yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 156 tests, 8 stderr failures, 0 stdout failures ================= memcheck/tests/sigaltstack (stderr) memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/vgtest_ume (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) corecheck/tests/fdleak_fcntl (stderr) none/tests/faultstatus (stderr)
> Everything builds fine but valgrind dies parsing command line options. This happened to me because of a .valgrindrc file in my home directory. Check if you have one and rename it to see if it makes everything go again.
> > Everything builds fine but valgrind dies parsing command line options. > > This happened to me because of a .valgrindrc file in my home directory. > Check if you have one and rename it to see if it makes everything go > again. Wow, that's pretty strange. Robert, do you know if this an amd64-specific bug or also occurs on x86 ?
> > This happened to me because of a .valgrindrc file in my home directory. > > Check if you have one and rename it to see if it makes everything go > > again. > > Wow, that's pretty strange. Robert, do you know if this an amd64-specific > bug or also occurs on x86 ? I haven't checked yet. I'll mess around with it tonight when I get home and let you know what I see.
Latest SVN just freezes for me here is the strace : execve("/usr/local/bin/valgrind", ["valgrind"], [/* 32 vars */]) = 0 uname({sys="Linux", node="southpark", ...}) = 0 brk(0) = 0x5a9000 brk(0x5a9878) = 0x5a9878 arch_prctl(0x1002, 0x5a9850) = 0 brk(0x5ca878) = 0x5ca878 brk(0x5cb000) = 0x5cb000 getrlimit(0x9, 0x7ffffff893f0) = 0 setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0 open("/usr/local/lib/valgrind/stage2", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=3482999, ...}) = 0 geteuid() = 1000 getegid() = 1000 getgroups(32, [4, 20, 24, 25, 29, 30, 44, 46, 107, 108, 109, 1000]) = 12 pread(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300#\1\0"..., 4096, 0) = 4096 pread(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300#\1\0"..., 64, 0) = 64 pread(3, "\6\0\0\0\5\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0"..., 448, 64) = 448 pread(3, "/lib64/ld-linux-x86-64.so.2\0", 28, 512) = 28 open("/lib64/ld-linux-x86-64.so.2", O_RDONLY) = 4 pread(4, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\n\0\0"..., 64, 0) = 64 pread(4, "\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 280, 64) = 280 mmap(0x7ffff0000000, 1175552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7ffff0000000 mmap(0x7ffff021f000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11f000) = 0x7ffff021f000 mmap(0x7ffff0228000, 5206016, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff0228000 mmap(0x7ffff1000000, 1142056, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff1000000 mmap(0x7ffff1000000, 90112, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x7ffff1000000 mmap(0x7ffff1116000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x16000) = 0x7ffff1116000 close(4) = 0 close(3) = 0 open("/tmp/.pad.5.1", O_RDWR|O_CREAT|O_EXCL, 0) = 3 unlink("/tmp/.pad.5.1") = 0 open("/proc/self/maps", O_RDONLY) = 4 read(4, "00400000-00483000 r-xp 00000000 "..., 10240) = 929 close(4) = 0 mmap(NULL, 4194304, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0 mmap(0x483000, 1044480, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x483000 mmap(0x5cb000, 140737213845504, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x5cb000 mmap(0x7ffff011f000, 1048576, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7ffff011f000 mmap(0x7ffff071f000, 9310208, PROT_NONE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x7ffff071f000 open("/proc/self/exe", O_RDONLY) = 4 uname({sys="Linux", node="southpark", ...}) = 0 brk(0) = 0x5cb000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff1117000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff1118000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 5 fstat(5, {st_mode=S_IFREG|0644, st_size=51531, ...}) = 0 mmap(NULL, 51531, PROT_READ, MAP_PRIVATE, 5, 0) = 0x7ffff111a000 close(5) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\17\0\0"..., 640) = 640 fstat(5, {st_mode=S_IFREG|0644, st_size=10056, ...}) = 0 mmap(NULL, 1056664, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7ffff1127000 mprotect(0x7ffff1129000, 1048472, PROT_NONE) = 0 mmap(0x7ffff1228000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1000) = 0x7ffff1228000 close(5) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \305\1\0"..., 640) = 640 fstat(5, {st_mode=S_IFREG|0644, st_size=1261976, ...}) = 0 mmap(NULL, 2321416, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7ffff1229000 mprotect(0x7ffff1357000, 1084424, PROT_NONE) = 0 mmap(0x7ffff1456000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x12d000) = 0x7ffff1456000 mmap(0x7ffff145c000, 15368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff145c000 close(5) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff1460000 mprotect(0x7ffff0000000, 1175552, PROT_READ|PROT_WRITE) = 0 mprotect(0x7ffff0000000, 1175552, PROT_READ|PROT_EXEC) = 0 arch_prctl(0x1002, 0x7ffff14606d0) = 0 munmap(0x7ffff111a000, 51531) = 0 getrlimit(0x2, 0x7ffff05ddb00) = 0 setrlimit(RLIMIT_DATA, {rlim_cur=0, rlim_max=RLIM_INFINITY}) = 0 getrlimit(0x3, 0x7ffff05ddb20) = 0 open("/home/cartman/.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory) open("./.valgrindrc", O_RDONLY) = -1 ENOENT (No such file or directory) brk(0) = 0x5cb000 brk(0x5ec000) = 0x5cb000 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ffff1461000 open("/usr/local/lib/valgrind/vgtool_memcheck.so", O_RDONLY) = 5 read(5, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220X\0\0"..., 640) = 640 fstat(5, {st_mode=S_IFREG|0755, st_size=331157, ...}) = 0 mmap(NULL, 3792272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0x7ffff1561000 mprotect(0x7ffff157a000, 3689872, PROT_NONE) = 0 mmap(0x7ffff1679000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x18000) = 0x7ffff1679000 mmap(0x7ffff167b000, 2637200, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ffff167b000 close(5) = 0 access("/usr/local/lib/valgrind/vgpreload_memcheck.so", R_OK) = 0 mmap(0x3c3c34a00000, 1048576, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x3c3c34a00000 munmap(0, 66229278605312 Though I need to copy vex includes manually to valgrind/include, I don't think thats the problem.
> > Everything builds fine but valgrind dies parsing command line options. > This happened to me because of a .valgrindrc file in my home directory. > Check if you have one and rename it to see if it makes everything go > again. That worked! Thanks, and sorry it's taken me so long to confirm the problem.
The bug in the .valgrindrc reading should be fixed in the SVN trunk, if you update.
On Thu, 2005-06-23 at 10:43, Nicholas Nethercote wrote: > The bug in the .valgrindrc reading should be fixed in the SVN trunk, if > you update. Yes, that fixed it. Thanks, David
Shouldn't this bug be closed out now? AMD64 support is now quite usable and acceptable.
On Thursday 23 June 2005 21:04, Robert Walsh wrote: [bugs.kde.org quoted mail] See my report. It doesn't even start here.
I agree with Robert. The original issue has been addressed. New bug reports should be created for remaining bugs in the amd64 implementation. Julian do you agree?
> I agree with Robert. The original issue has been addressed. New > bug reports should be created for remaining bugs in the amd64 > implementation. Julian do you agree? Yes. I think this "bug" has been comprehensively "fixed" :-)
so, this means that there is a release for x86_64 now?
No, but we close bugs as soon as they have been addressed in the repository. We don't wait for a release before closing them. If you have outstanding bugs on AMD64, please start a new bug report. Thanks. And a big thanks to Julian and Tom for all their hard work in getting this working!
> And a big thanks to Julian and Tom for all their hard work in getting this > working! Not to forget Nick, Jeremy, PaulM, whose behind-the-scenes restructuring of the code base in various ways was critical to achieving a viable multi-platform Valgrind.
Thank you for the work you have done!
*** Bug 108983 has been marked as a duplicate of this bug. ***