From: Cyrus H. <ch...@bo...> - 2007-02-07 19:27:34
|
Ok, I think the claim "valgrind finds lots of errors" is bogus. On Feb 7, 2007, at 10:38 AM, bvds wrote: > > Here is what sbcl startup looks like on Linux, x86: > > vanlehn15> valgrind sbcl > ==11918== Memcheck, a memory error detector. > ==11918== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward > et al. > ==11918== Using LibVEX rev 1732, a library for dynamic binary > translation. > ==11918== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. > ==11918== Using valgrind-3.2.3, a dynamic binary instrumentation > framework. > ==11918== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward > et al. > ==11918== For more details, rerun with: -v > ==11918== > ==11918== Syscall param futex(futex) points to unaddressable byte(s) > ==11918== at 0x9D6B82: syscall (in /lib/tls/libc-2.3.3.so) > ==11918== by 0x805A959: main (runtime.c:340) I think this is OK and is an acceptable use of the futex API. > ==11918== Address 0x0 is not stack'd, malloc'd or (recently) free'd not sure where this is coming from > ==11918== Warning: set address range perms: large range 536870912 > (defined) > ==11918== Warning: set address range perms: large range 268431360 > (defined) probably ok > This is SBCL 1.0.2, an implementation of ANSI Common Lisp. > More information about SBCL is available at <http://www.sbcl.org/>. > > SBCL is free software, provided as is, with absolutely no warranty. > It is mostly in the public domain; some portions are provided under > BSD-style licenses. See the CREDITS and COPYING files in the > distribution for more information. > ==11918== > ==11918== Syscall param modify_ldt(ptr) points to uninitialised byte > (s) > ==11918== at 0x9D6B82: syscall (in /lib/tls/libc-2.3.3.so) > ==11918== by 0x805BD75: create_initial_thread (thread.c:130) > ==11918== by 0x805AD60: main (runtime.c:425) I'm confused as to why the stack trace isn't showing the intervening function calls. This looks like it's really coming out of arch_os_thread_init. I haven't looked at the linux/x86 ldt code and I'm not enough of a C language pedant to now if this is kosher, but, yes it seems to be uninitialized and the SYS_modify_ldt code initializes it. It's a valid address and I don't see why it needs to be gratuitously initialized before it gets overwritten. > ==11918== Address 0xBEFF25EC is on thread 1's stack > ==11918== Warning: client switching stacks? SP change: 0xBEFF2608 > --> 0x461B000==11918== to suppress, use: --max- > stackframe=1164085752 or greater yes, we switch stacks. > vex x86->IR: unhandled instruction bytes: 0xCC 0xA 0x6 0x22 > ==11918== valgrind: Unrecognised instruction at address 0x928C91D. > ==11918== Your program just tried to execute an instruction that > Valgrind > ==11918== did not recognise. There are two possible reasons for this. > ==11918== 1. Your program has a bug and erroneously jumped to a non- > code > ==11918== location. If you are running Memcheck and you just saw a > ==11918== warning about a bad jump, it's probably your program's > fault. > ==11918== 2. The instruction is legitimate but Valgrind doesn't > handle it, > ==11918== i.e. it's Valgrind's fault. If you think this is the > case or > ==11918== you are not sure, please let us know and we'll try to > fix it. > ==11918== Either way, Valgrind will now raise a SIGILL signal which > will > ==11918== probably kill your program. > fatal error encountered in SBCL pid 11918(tid 67212864): > fake_foreign_call fell through > LDB monitor > ldb> quit Ok, this looks like SBCLs trap handling and is totally expected. You'd have to teach valgrind to deal with this if you want to use it with SBCL, I think. Cyrus |