|
From: Michael A. <mic...@go...> - 2009-01-04 22:05:57
|
Hi, I am running the 3.4.0 release on a 64 bit Ubuntu box. While running the linbox (linalg.org) test suite under ptr-check I am seeing the following: mabshoff@sage:~/build/linbox-testing/linbox-svn3066/tests/foo$ ~/build/eMPIRe/sage-3.2.3.final/local/bin/valgrind --tool=ex p-ptrcheck ./test-gmp-rational ==29373== exp-ptrcheck, a heap, stack & global array overrun detector. ==29373== NOTE: This is an Experimental-Class Valgrind Tool. ==29373== Copyright (C) 2003-2008, and GNU GPL'd, by OpenWorks Ltd et al. ==29373== Using LibVEX rev 1878, a library for dynamic binary translation. ==29373== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==29373== Using valgrind-3.4.0, a dynamic binary instrumentation framework. ==29373== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==29373== For more details, rerun with: -v ==29373== sysno == 98 exp-ptrcheck: the 'impossible' happened: unhandled syscall ==29373== at 0x3801069C: report_and_quit (m_libcassert.c:140) ==29373== by 0x380107B4: panic (m_libcassert.c:215) ==29373== by 0x380107F9: vgPlain_tool_panic (m_libcassert.c:230) ==29373== by 0x3800368D: h_post_syscall (h_main.c:2449) ==29373== by 0x38035A82: vgPlain_post_syscall (syswrap-main.c:1178) ==29373== by 0x38036471: vgPlain_client_syscall (syswrap-main.c:1090) ==29373== by 0x38033802: handle_syscall (scheduler.c:824) ==29373== by 0x3803483E: vgPlain_scheduler (scheduler.c:1018) ==29373== by 0x380461F3: run_a_thread_NORETURN (syswrap-linux.c:89) ==29373== by 0xFFFFFFFFFFFFFFFF: ??? ==29373== by 0xDEADBEEFDEADBEEE: ??? ==29373== by 0x38094474: unsafeIRDirty_0_N (irdefs.c:2711) ==29373== by 0x385A86B0: ??? ==29373== by 0x402001150: ??? ==29373== by 0x2: ??? ==29373== by 0x383FB808: ??? ==29373== by 0x402001150: ??? ==29373== by 0x2: ??? ==29373== by 0x385A9898: ??? ==29373== by 0x1: ??? ==29373== by 0x403BFB980: ??? ==29373== by 0x385A99D8: ??? ==29373== by 0x385A9538: ??? ==29373== by 0x3813D446: ado_treebuild_BB (iropt.c:4158) ==29373== by 0x1385A8B38: ??? ==29373== by 0x403BFBB68: ??? ==29373== by 0x402001150: ??? ==29373== by 0x3FFFE8: ??? ==29373== by 0x403BFBA80: ??? ==29373== by 0x403BFBA81: ??? ==29373== by 0x403BFB998: ??? ==29373== by 0x380924C3: typeOfIRExpr (irdefs.c:1933) ==29373== by 0x5000000250000000: ??? ==29373== by 0x381421AE: (within /home/mabshoff/build/eMPIRe/sage-3.2.3.final/local/lib/valgrind/amd64-linux/exp-ptrcheck) ==29373== by 0x11: ??? ==29373== by 0x3807C040: myvprintf_str (m_debuglog.c:467) ==29373== by 0x2: ??? ==29373== by 0x7C23B: ??? ==29373== by 0x8000000400000011: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==29373== at 0x6B7DE17: getrusage (in /lib/libc-2.7.so) ==29373== by 0x409224: LinBox::UserTimer::start() (timer.C:100) ==29373== by 0x409A09: LinBox::Timer::start() (timer.C:147) ==29373== by 0x409B98: LinBox::Commentator::start(char const*, char const*, unsigned long) (commentator.C:135) ==29373== by 0x409D0F: main (test-gmp-rational.C:41) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. Thoughts? Cheers, Michael |
|
From: Tom H. <to...@co...> - 2009-01-04 23:53:03
|
Michael Abshoff wrote: > I am running the 3.4.0 release on a 64 bit Ubuntu box. While running the > linbox (linalg.org) test suite under ptr-check I am seeing the following: Can you please raise a bug for this in bugzilla... Actually you might want to check the existing bugs first as I think somebody may already have reported this, but without the syscall number. If that is the case then just adding the syscall number would be good. I assume this is a 64 bit x86 program? In which case the syscall is getrusage. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Michael A. <mic...@go...> - 2009-01-05 00:29:29
|
Tom Hughes wrote: > Michael Abshoff wrote: Hi Tom, thanks for your prompt help. >> I am running the 3.4.0 release on a 64 bit Ubuntu box. While running >> the linbox (linalg.org) test suite under ptr-check I am seeing the >> following: > > Can you please raise a bug for this in bugzilla... Actually you might > want to check the existing bugs first as I think somebody may already > have reported this, but without the syscall number. If that is the case > then just adding the syscall number would be good. There is another ticket where an unknown syscall popped up with exp-ptrcheck: https://bugs.kde.org/show_bug.cgi?id=179618 Julian asked for feedback, but hasn't gotten any yet, so I added my info there for now. Should it turn out to be a different syscall I guess the ticket can be cloned. > I assume this is a 64 bit x86 program? In which case the syscall is > getrusage. Yes, it is. And the trace seems to indicate getrusage. > Tom I have also been playing with exp-ptrcheck and some Python code, but Python needs a couple suppressions to get the noise down. So after creating them and adding them to my personal Python suppression file they do not seem to work. Assuming suppressions are supposed to work for exp-ptrcheck I can supply some example once I am sure I am not screwing up since I wrote most of that supp file for Valgrind 3.3.1. Cheers, Michael |
|
From: Michael A. <mic...@go...> - 2009-01-05 00:41:39
|
Tom Hughes wrote: > Michael Abshoff wrote: Hi Tom, >> I am running the 3.4.0 release on a 64 bit Ubuntu box. While running >> the linbox (linalg.org) test suite under ptr-check I am seeing the >> following: > > Can you please raise a bug for this in bugzilla... Actually you might > want to check the existing bugs first as I think somebody may already > have reported this, but without the syscall number. If that is the case > then just adding the syscall number would be good. > > I assume this is a 64 bit x86 program? In which case the syscall is > getrusage. I just played around a little more and discovered another unsupported syscall when running chown, i.e. mabshoff@sage:~/build/linbox-testing/linbox-svn3066/tests/foo$ ~/build/eMPIRe/sage-3.2.3.final/local/bin/valgrind --tool=exp-ptrcheck chown mabshoff:mabshoff TODO ==2132== exp-ptrcheck, a heap, stack & global array overrun detector. ==2132== NOTE: This is an Experimental-Class Valgrind Tool. ==2132== Copyright (C) 2003-2008, and GNU GPL'd, by OpenWorks Ltd et al. ==2132== Using LibVEX rev 1878, a library for dynamic binary translation. ==2132== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==2132== Using valgrind-3.4.0, a dynamic binary instrumentation framework. ==2132== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==2132== For more details, rerun with: -v ==2132== sysno == 262 I have appended the remaining info to https://bugs.kde.org/show_bug.cgi?id=179618 > Tom I am willing to test a bunch of shell utilities and code to find more syscalls that are missing, but should I open individual tickets for each syscall or stuff them onto the existing ticket? Cheers, Michael |
|
From: Julian S. <js...@ac...> - 2009-01-05 02:10:02
|
> I am willing to test a bunch of shell utilities and code to find more > syscalls that are missing, but should I open individual tickets for each > syscall or stuff them onto the existing ticket? Put them all on the existing ticket. The important information is, in each case, the syscall number and the architecture (x86, amd64, etc). Actually if you look at the function setup_post_syscall_table in h_main.c it's easy to add the missing entries. Syscalls which don't return pointers (almost all syscalls) can just be added to the table without any further thought. (The important distinction here is: does this syscall return a pointer, or a non-pointer) ? J |
|
From: Michael A. <mic...@go...> - 2009-01-05 02:28:37
|
Julian Seward wrote: Hi Julian, >> I am willing to test a bunch of shell utilities and code to find more >> syscalls that are missing, but should I open individual tickets for each >> syscall or stuff them onto the existing ticket? > > Put them all on the existing ticket. The important information is, in > each case, the syscall number and the architecture (x86, amd64, etc). Ok, will do. > Actually if you look at the function setup_post_syscall_table in h_main.c > it's easy to add the missing entries. Adding _NR_getursage to that table fixes the issue I observed, I haven't tried the other syscall yet. > Syscalls which don't return > pointers (almost all syscalls) can just be added to the table without > any further thought. (The important distinction here is: does this > syscall return a pointer, or a non-pointer) ? Excellent to know - at least something I can contribute patches for as valgrind n00b coder :) I assume syscalls that return pointers are somewhat more difficult to deal with? > J > Cheers, Michael |
|
From: Julian S. <js...@ac...> - 2009-01-05 08:31:05
|
> > Syscalls which don't return > > pointers (almost all syscalls) can just be added to the table without > > any further thought. (The important distinction here is: does this > > syscall return a pointer, or a non-pointer) ? > > Excellent to know - at least something I can contribute patches for as > valgrind n00b coder :) I assume syscalls that return pointers are > somewhat more difficult to deal with? Syscalls that return pointers are indeed a bit more tricky, but they are also very rare (eg, mmap) and I don't think you are likely to encounter any. The ideal is that you add entries to setup_post_syscall_table() so as to make it work for you, and then send us the patch (attach it to the bugzilla entry). Thanks, J |