Re: [Valgrind-developers] vmware backdoor patch

[Sunny D. <int...@ya...>]

Philippe,

I am using valgrind-3.6.1, which is the stable version on Gentoo.

Here is the message:
==5377== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==5377==  Access not within mapped region at address 0x100000008

Looks like process died, not the valgrind. Other than that message in the end, the log file consists of backtraces of usual 'invalid reads' and some non-leak leaks etc. There is a core file created which when I do a 'file' on, it says core was generated by valgrind, but gdb'ing it with valgrind or my binary doesn't produce a valid backtrace. Note that I can gdb both valgrind and my binary with line numbers and all debugs perfectly fine.

Do u think its died in tricky JITted code? How do I debug this? I am slipping deadlines here...:( I have used valgrind for a very long time and never gotten stuck like this.


Thanks for all the help. I appreciate it.

-Sunny



----- Original Message -----
From: Philippe Waroquiers <phi...@sk...>
To: Sunny Das <int...@ya...>
Cc: "val...@li..." <val...@li...>
Sent: Thursday, June 7, 2012 10:37 AM
Subject: Re: [Valgrind-developers] vmware backdoor patch

On Wed, 2012-06-06 at 16:08 -0700, Sunny Das wrote:
> I went ahead and ripped all the 8 functions out and replaced the 
> part which does backdoor assembly into their own functions with correct signature,
>  handling the returns properly. And I went past that issue of backdoor.
That is good news.
> 
> Now, I am running into another weird issue where valgrind crashed 
> somewhere and I can't figure out where because the backtrace is 
> all '??'. This happens even if I run the program inline inside
>  the gdb. valgrind was built with splitdebug in gentoo and so was glibc.
> The valgrind debug symbols are all in /usr/lib/debug/usr/lib64/valgrind/
>  and /usr/lib/debug/usr/bin/valgrind.debug and glibc debug symbols are
>  in/usr/lib/debug/lib64. Why is gdb refusing to give me a proper backtrace?
Might be because the problem happens in JITted code (i.e. the code
dynamically generated by Valgrind starting from your application code).
GDB then does not have any information about what these program counters
could be.

Now, if Valgrind is "internally" crashing, usually (at least for me), it
outputs a nice crash message, giving its own backtrace, and a backtrace 
for all the "application threads".
It would help to have some info such as:
   * which Valgrind version
   * what is the exact crash message you get

If you obtain no stacktrace at all, I would suggest to avoid
compiling V with separate debug info.

Philippe