valgrind-users

[Valgrind-users] More selective --auto-run-dsymutil

[Luc B. <luc...@ma...>]

Hello there,

I am developing Python extensions (in C++, using Boost.Python but it  
does not matter). I run all my Python test cases through valgrind,

	valgrind --auto-run-dsymutil python foo.py

so as to catch bugs in those Python extensions. The problem is that  
valgrind wants to run dsymutil not only on my Python extensions but  
also on the Python executable and the whole of the standard Python  
library. Those dsymutil calls fail, of course, because valgrind wants  
to write the dSYM directories next to those and since I run valgrind  
as a normal user, it does not have the permission to do that.

Would there be a workaround for that problem? This is quite annoying  
because it produces so much noise…

Luc Bourhis

Re: [Valgrind-users] More selective --auto-run-dsymutil

[Luc B. <luc...@ma...>]

> Have a look at the function "is_systemish_library_name" in
> coregrind/m_debuginfo/readmacho.c.  This causes V not to try to run
> dsymutil in various system directories (it's obvious if you look
> at the code).  Maybe the path to your Python installation is not
> covered by the tests in this function?

  Thanks for your helpful answer.

I am not running system Python but MacPorts python, in /opt/local/...  
indeed (because I need Python 2.6 whereas the version shipped with my  
system is only 2.5). Is patching is_systemish_library_name the only  
work around then? I guess adding "/opt/" or "/opt/local/" would work  
for everybody except perhaps the MacPorts porters.

Luc

Re: [Valgrind-users] More selective --auto-run-dsymutil

[Julian S. <js...@ac...>]

On Friday 22 May 2009, Luc Bourhis wrote:
> > Have a look at the function "is_systemish_library_name" in
> > coregrind/m_debuginfo/readmacho.c.  This causes V not to try to run
> > dsymutil in various system directories (it's obvious if you look
> > at the code).  Maybe the path to your Python installation is not
> > covered by the tests in this function?
>
>   Thanks for your helpful answer.
>
> I am not running system Python but MacPorts python, in /opt/local/...
> indeed (because I need Python 2.6 whereas the version shipped with my
> system is only 2.5). Is patching is_systemish_library_name the only
> work around then?

Well, it's here, it's now, it's zero effort, and it should work.
I guess there could be fancier solutions in future involving a command
line specification, or some such, if really necessary.

J

Re: [Valgrind-users] More selective --auto-run-dsymutil

[Luc B. <luc...@ma...>]

On 22 May 2009, at 16:33, Julian Seward wrote:

>>  Is patching is_systemish_library_name the only work around then?
>
> Well, it's here, it's now, it's zero effort, and it should work.

True enough. It works like a charm. I added /sw/ to content Fink users  
too.

*** coregrind/m_debuginfo/readmacho.c (10109)	2009-05-22 17:48:16 +0200
--- coregrind/m_debuginfo/readmacho.c (working version)	2009-05-22  
17:48:16 +0200
***************
*** 647,653 ****
--- 647,655 ----
   {
      vg_assert(name);
      if (0 == VG_(strncasecmp)(name, "/usr/", 5)
+        || 0 == VG_(strncasecmp)(name, "/opt/", 5)
+        || 0 == VG_(strncasecmp)(name, "/sw/", 4)
          || 0 == VG_(strncasecmp)(name, "/bin/", 5)
          || 0 == VG_(strncasecmp)(name, "/sbin/", 6)
          || 0 == VG_(strncasecmp)(name, "/System/", 8)

Thanks a lot.

Luc

Re: [Valgrind-users] More selective --auto-run-dsymutil

[Julian S. <js...@ac...>]

Have a look at the function "is_systemish_library_name" in
coregrind/m_debuginfo/readmacho.c.  This causes V not to try to run
dsymutil in various system directories (it's obvious if you look
at the code).  Maybe the path to your Python installation is not
covered by the tests in this function?  LMK if it needs to be
changed.  (or if this does not help).

J

On Friday 22 May 2009, Luc Bourhis wrote:
> Hello there,
>
> I am developing Python extensions (in C++, using Boost.Python but it
> does not matter). I run all my Python test cases through valgrind,
>
> 	valgrind --auto-run-dsymutil python foo.py
>
> so as to catch bugs in those Python extensions. The problem is that
> valgrind wants to run dsymutil not only on my Python extensions but
> also on the Python executable and the whole of the standard Python
> library. Those dsymutil calls fail, of course, because valgrind wants
> to write the dSYM directories next to those and since I run valgrind
> as a normal user, it does not have the permission to do that.
>
> Would there be a workaround for that problem? This is quite annoying
> because it produces so much noise…
>
> Luc Bourhis