|
From: Madhan S. <mad...@gm...> - 2009-06-05 05:39:01
|
Hello, The code below helps to find if we are running on Xen VM and uses "ud2a" http://xen-3.1.sourcearchive.com/documentation/3.1.0/xen-detect_8c-source.html and as expected Valgrind 3.4.1 throws the following warning: vex x86->IR: unhandled instruction bytes: 0xF 0xB 0x78 0x65 ==31055== valgrind: Unrecognised instruction at address 0x80484a2. ==31055== Your program just tried to execute an instruction that Valgrind ==31055== did not recognise. There are two possible reasons for this. ==31055== 1. Your program has a bug and erroneously jumped to a non-code ==31055== location. If you are running Memcheck and you just saw a ==31055== warning about a bad jump, it's probably your program's fault. ==31055== 2. The instruction is legitimate but Valgrind doesn't handle it, ==31055== i.e. it's Valgrind's fault. If you think this is the case or ==31055== you are not sure, please let us know and we'll try to fix it. ==31055== Either way, Valgrind will now raise a SIGILL signal which will ==31055== probably kill your program. ==31055== ==31055== Process terminating with default action of signal 4 (SIGILL) ==31055== Illegal opcode at address 0x80484A2 ==31055== at 0x80484A2: cpuid (b.c:43) ==31055== by 0x8048601: main (b.c:91) Is there a way to suppress this warning. Thanks, Madhan. |
|
From: Tim P. <ec...@ec...> - 2009-06-05 09:47:29
|
Hi, On Fri, 2009-06-05 at 11:08 +0530, Madhan Sadasivam wrote: > Hello, > > The code below helps to find if we are running on Xen VM and uses > "ud2a" > http://xen-3.1.sourcearchive.com/documentation/3.1.0/xen-detect_8c-source.html > > and as expected Valgrind 3.4.1 throws the following warning: I ran into the same problem. What I ended up doing was along the lines of: #ifndef NDEBUG #include <valgrind/valgrind.h> #else #define RUNNING_ON_VALGRIND 0 #endif main() { ..... if (RUNNING_ON_VALGRIND) signal(SIGILL, dummy_valgrind_handler) else signal(SIGILL, normal_sigill_handler) Of course that's just a quick example, you probably want to use sigaction(). I know its an ugly hack, but it works. I could not figure out how to suppress that either. Cheers, --Tim |
|
From: Nicholas N. <n.n...@gm...> - 2009-06-29 05:10:16
|
On Fri, Jun 5, 2009 at 7:47 PM, Tim Post<ec...@ec...> wrote: > Hi, > > On Fri, 2009-06-05 at 11:08 +0530, Madhan Sadasivam wrote: >> Hello, >> >> The code below helps to find if we are running on Xen VM and uses >> "ud2a" >> http://xen-3.1.sourcearchive.com/documentation/3.1.0/xen-detect_8c-source.html >> >> and as expected Valgrind 3.4.1 throws the following warning: > > I ran into the same problem. What I ended up doing was along the lines > of: > > #ifndef NDEBUG > #include <valgrind/valgrind.h> > #else > #define RUNNING_ON_VALGRIND 0 > #endif > > main() > { > ..... > if (RUNNING_ON_VALGRIND) > signal(SIGILL, dummy_valgrind_handler) > else > signal(SIGILL, normal_sigill_handler) > > Of course that's just a quick example, you probably want to use > sigaction(). I know its an ugly hack, but it works. I could not figure > out how to suppress that either. FWIW, this is in the bug database: https://bugs.kde.org/show_bug.cgi?id=191062 Nick |
|
From: Tim P. <ec...@ec...> - 2009-07-11 20:17:24
|
On Mon, 2009-06-29 at 15:10 +1000, Nicholas Nethercote wrote: > FWIW, this is in the bug database: > > https://bugs.kde.org/show_bug.cgi?id=191062 > > Nick What was hacky now becomes viral :) Sorry to be delayed in my Xen patches, my free time has degenerated into int64_t in the last two weeks. This seems to be a persistent problem, so I'll send patches to xen-devel for a more valgrind commented and friendly snippet to exist. BTW, FWIW, I quite like the current behavior when dealing with something that _should_ generate a fault, its quite easy to work around when you _know_ its bogus. Cheers, --Tim |