|
From: Simon B. <sbo...@gm...> - 2012-12-05 17:18:21
|
Hi Guys, I am trying to track a memory leak in a vmware service and I tried to use valgrind to track the leak. Unfortunately it is stopping for the following instruction. vex x86->IR: unhandled instruction bytes: 0xF 0xB 0xFF 0x85 I am using a busybox 1.20.0. Help would be highly appreciated. Regards Simon |
|
From: John R. <jr...@bi...> - 2012-12-05 19:56:42
|
On 12/05/2012 09:18 AM, Simon Bonello wrote: > I am trying to track a memory leak in a vmware service and I tried to use valgrind to track the leak. Unfortunately it is stopping for the following instruction. > > vex x86->IR:unhandled instruction bytes:0xF 0xB 0xFF 0x85 > > I am using a busybox 1.20.0.||Help would be highly appreciated. Use plain text for posting, not HTML. Which version of valgrind? What was the shell command that you invoked in order to get the error? "0x0f 0x0b" is 'ud2', the blessed-by-Intel opcode for "undefined instruction." It means that the compiler's code generator thought that it was impossible to get to that point. The cause of the "real" error happened some time ago. So look at the traceback, or sometimes even farther back than that. (Is the traceback from glibc, uClibc, or the app itself?) -- |
|
From: Philippe W. <phi...@sk...> - 2012-12-05 20:54:29
|
On Wed, 2012-12-05 at 11:57 -0800, John Reiser wrote: > On 12/05/2012 09:18 AM, Simon Bonello wrote: > > I am trying to track a memory leak in a vmware service and I tried to use valgrind to track the leak. Unfortunately it is stopping for the following instruction. > > > > vex x86->IR:unhandled instruction bytes:0xF 0xB 0xFF 0x85 > > > > I am using a busybox 1.20.0.||Help would be highly appreciated. > > > Use plain text for posting, not HTML. > > Which version of valgrind? What was the shell command that you invoked > in order to get the error? > > "0x0f 0x0b" is 'ud2', the blessed-by-Intel opcode for "undefined instruction." > It means that the compiler's code generator thought that it was impossible > to get to that point. The cause of the "real" error happened some time ago. > So look at the traceback, or sometimes even farther back than that. > (Is the traceback from glibc, uClibc, or the app itself?) > You might also look at thread http://comments.gmane.org/gmane.comp.debugging.valgrind.devel/17911 which speaks about specific vmware stuff and how it was finally supported (without patch in Valgrind, instead using client requests). Philippe |