valgrind on FreeBSD?

Jeremy Chadwick freebsd at jdc.parodius.com
Sun Oct 9 13:46:09 UTC 2011


On Sun, Oct 09, 2011 at 03:25:23PM +0200, V??clav Zeman wrote:
> Bakul Shah wrote, On 6.10.2011 8:40:
> > On Wed, 05 Oct 2011 23:06:04 +0200 =?UTF-8?B?VsOhY2xhdiBaZW1hbg==?= <v.haisman at sh.cvut.cz>  wrote:
> >> Hi.
> >>
> >> No matter what I try, valgrind on 7.3-STABLE is giving me this, both Valgrind
> >> ports:
> >>
> >> valgrind: Startup or configuration error:
> >>    Can't establish current working directory at startup
> >> valgrind: Unable to start up properly.  Giving up.
> >>
> >> What do I need to do to make it work?
> > 
> > Try running valgrind under ktrace (& view with kdump). That
> > will tell you what directory it is trying to access or what
> > syscall fails and why.
> Hi.
> 
> So I have done that and more. I have first updated from 7.3 to 8.2 (RELENG_8
> actually). I have not managed to recompile all of the installed Ports yet,
> but I made sure to recompile valgrind and its dependencies. The same thing
> has happened!
> 
> As I have said, I have done the ktrace and here is the interesting bit:
> 
>  78028 valgrind NAMI  "/usr/local/lib/valgrind/memcheck-amd64-freebsd"
>  78028 memcheck-amd64-free RET   execve 0
>  78028 memcheck-amd64-free CALL  getpid
>  78028 memcheck-amd64-free RET   getpid 78028/0x130cc
>  78028 memcheck-amd64-free CALL
> __sysctl(0x39a91450,0x4,0x389a3800,0x39a91468,0,0)
>  78028 memcheck-amd64-free SCTL  "kern.proc.vmmap.78028"
>  78028 memcheck-amd64-free RET   __sysctl 0
>  78028 memcheck-amd64-free CALL
> mmap(0x400009000,0x400000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffffffffffff,0)
>  78028 memcheck-amd64-free RET   mmap 17179906048/0x400009000
>  78028 memcheck-amd64-free CALL  getrlimit(RLIMIT_DATA,0x39e6a780)
>  78028 memcheck-amd64-free RET   getrlimit 0
>  78028 memcheck-amd64-free CALL  setrlimit(RLIMIT_DATA,0x39a919e0)
>  78028 memcheck-amd64-free RET   setrlimit 0
>  78028 memcheck-amd64-free CALL  getrlimit(RLIMIT_STACK,0x39e6a790)
>  78028 memcheck-amd64-free RET   getrlimit 0
>  78028 memcheck-amd64-free CALL  __getcwd(0x3882d700,0x3ff)
>  78028 memcheck-amd64-free NAMI  ".."
>  78028 memcheck-amd64-free RET   __getcwd -1 errno 2 No such file or directory
>  78028 memcheck-amd64-free CALL  write(0x2,0x3830b060,0x6c)
>  78028 memcheck-amd64-free GIO   fd 2 wrote 108 bytes
>        "valgrind: Startup or configuration error:
>         valgrind:    Can't establish current working directory at startup
>        "
>  78028 memcheck-amd64-free RET   write 108/0x6c
>  78028 memcheck-amd64-free CALL  write(0x2,0x3830b060,0x33)
>  78028 memcheck-amd64-free GIO   fd 2 wrote 51 bytes
>        "valgrind: Unable to start up properly.  Giving up.
>        "
>  78028 memcheck-amd64-free RET   write 51/0x33
>  78028 memcheck-amd64-free CALL  exit(0x1)
> 
> Now what? Why would the __getcwd call be failing with "No such file or
> directory"?

I can't reproduce this problem on our RELENG_7 system (7.4-STABLE,
though i386).  Filesystem being accessed by valgrind is UFS2 + SU.

$ valgrind /usr/local/bin/mysql
==47587== Memcheck, a memory error detector
==47587== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==47587== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==47587== Command: /usr/local/bin/mysql
==47587==
Welcome to the MySQL monitor.  Commands end with ; or \g.
{snip}

And this is what I see under "ktrace valgrind /usr/local/bin/mysql":

 47590 memcheck-x86-freebs RET   execve 0
 47590 memcheck-x86-freebs CALL  getpid
 47590 memcheck-x86-freebs RET   getpid 47590/0xb9e6
 47590 memcheck-x86-freebs CALL  __sysctl(0x3955b604,0x4,0x38473200,0x3955b62c,0,0)
 47590 memcheck-x86-freebs SCTL  "kern.proc.vmmap.47590"
 47590 memcheck-x86-freebs RET   __sysctl 0
 47590 memcheck-x86-freebs CALL  mmap(0x5fe08000,0x400000,PROT_READ|PROT_WRITE|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffff,0
,0)
 47590 memcheck-x86-freebs RET   mmap 1608548352/0x5fe08000
 47590 memcheck-x86-freebs CALL  getrlimit(RLIMIT_DATA,0x3984cf30)
 47590 memcheck-x86-freebs RET   getrlimit 0
 47590 memcheck-x86-freebs CALL  setrlimit(RLIMIT_DATA,0x3955bb98)
 47590 memcheck-x86-freebs RET   setrlimit 0
 47590 memcheck-x86-freebs CALL  getrlimit(RLIMIT_STACK,0x3984cf40)
 47590 memcheck-x86-freebs RET   getrlimit 0
 47590 memcheck-x86-freebs CALL  __sysctl(0x3955b62c,0x2,0x3955b604,0x3955b634,0x3818cab2,0x12)
 47590 memcheck-x86-freebs SCTL  "sysctl.name2oid"
 47590 memcheck-x86-freebs RET   __sysctl 0
 47590 memcheck-x86-freebs CALL  __sysctl(0x3955b604,0x2,0x3955b678,0x3955b674,0,0)
 47590 memcheck-x86-freebs SCTL  "hw.instruction_sse"
 47590 memcheck-x86-freebs RET   __sysctl 0
 47590 memcheck-x86-freebs CALL  __getcwd(0x38316fa0,0x3ff)
 47590 memcheck-x86-freebs NAMI  "/home/jdc"
 47590 memcheck-x86-freebs RET   __getcwd 0
 47590 memcheck-x86-freebs CALL  open(0x3955add0,O_RDONLY,<unused>0x100)
 47590 memcheck-x86-freebs NAMI  "/home/jdc/.valgrindrc"
 47590 memcheck-x86-freebs RET   open -1 errno 2 No such file or directory
 47590 memcheck-x86-freebs CALL  open(0x38e79260,O_RDONLY,<unused>0)
 47590 memcheck-x86-freebs NAMI  "/usr/local/bin/mysql"
 47590 memcheck-x86-freebs RET   open 3
 47590 memcheck-x86-freebs CALL  stat(0x38e79260,0x3955a2a4)
 {snip}

I also tried doing:

$ cd /usr/local/sbin
$ ktrace -f /home/jdc/ktrace.out -t+ valgrind ../bin/mysql
==47645== Memcheck, a memory error detector
==47645== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==47645== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==47645== Command: ../bin/mysql
==47645==
Welcome to the MySQL monitor.  Commands end with ; or \g.
{snip}

You get the idea.

Stuff I can think of:

>From the same directory you ran valgrind above, please provide the
output from commands "ls -ldoi ." and "ls -ldoi ..".

Other relevant questions:

* What filesystem type is associated with . and .. on the system?  Be
  sure to note if softupdates are in use or not too.
* Has this system crashed recently or even many months ago?
* If so, did you run fsck manually from single-user rather than rely
  on background fsck?  (There are confirmed cases of background fsck
  not fixing everything)
* If not, have you actually tried booting single-user and running fsck
  to see if you have some filesystem corruption in some weird way?
  This is completely 100% possible.
* Is this being run within a FreeBSD jail environment?

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |



More information about the freebsd-stable mailing list