|
From: Samuel B. <na...@gm...> - 2009-06-25 00:09:00
|
Hi. I'm trying to run some DPMI code under DOSEMU under valgrind,
hoping to track down some sort of leak, but valgrind gets stuck on
some of the segmentation-related instructions. For example, trying to
run DJGPP's ls, I get this:
,----
| 0x473600D: lss (%esp,,),%esp
|
| ------ IMark(0x473600D, 4) ------
| PUT(60) = 0x473600D:I32
| t14 = GET:I32(16)
| PUT(16) = LDle:I32(t14)
| PUT(290) = LDle:I16(Add32(t14,0x4:I32))
|
| 0x4736011: vex x86->IR: unhandled instruction bytes: 0x2E 0xFF 0x2D 0x0
| ------ IMark(0x4736011, 0) ------
| PUT(60) = 0x4736011:I32
| PUT(60) = 0x4736011:I32
| goto {NoDecode} 0x4736011:I32
|
| . 0 4736000 17
| . 89 D4 0F A9 0F A1 07 1F 61 83 C4 10 9D 0F B2 24 24
|
| ==13075== Warning: client switching stacks? SP change: 0xbed3e730 --> 0x821dba0
| ==13075== to suppress, use: --max-stackframe=1229845616 or greater
| ==13075== Warning: client switching stacks? SP change: 0x821dbe4 --> 0x760
| ==13075== to suppress, use: --max-stackframe=136434820 or greater
| ==13075== valgrind: Unrecognised instruction at address 0x4736011.
| ==13075== Your program just tried to execute an instruction that Valgrind
| ==13075== did not recognise. There are two possible reasons for this.
| ==13075== 1. Your program has a bug and erroneously jumped to a non-code
| ==13075== location. If you are running Memcheck and you just saw a
| ==13075== warning about a bad jump, it's probably your program's fault.
| ==13075== 2. The instruction is legitimate but Valgrind doesn't handle it,
| ==13075== i.e. it's Valgrind's fault. If you think this is the case or
| ==13075== you are not sure, please let us know and we'll try to fix it.
| ==13075== Either way, Valgrind will now raise a SIGILL signal which will
| ==13075== probably kill your program.
`----
-- and that's AFTER adding support for the LSS instruction to VEX.
It turns out that the unrecognized instruction is some kind of
indirect far jump that ndisasm renders as:
00000000 2EFF2D00010203 jmp dword far [dword cs:0x3020100]
and objdump as:
0: 2e ff 2d 00 01 02 03 ljmp *%cs:0x3020100
(the address part is mostly bogus since I'm just working with the four
bytes that VEX dumped for me, but that shouldn't matter.)
It does not look as if either VEX or valgrind supports having CS refer
to a non-flat segment; how crazy would it be to try to add this?
P.S. The code for LSS should be in
https://code.launchpad.net/~naesten/valgrind/vex-segmented soon; it's
not there quite yet on account of having to push the entire SVN trunk
history of vex, which is taking a bit -- it's been almost ten minutes
already, and the progress bar looks to be at about 50%, though I have
my doubts as to whether or not it means anything.
|
|
From: Samuel B. <na...@gm...> - 2009-06-26 03:22:51
|
Ping?
At Wed, 24 Jun 2009 20:08:32 -0400,
Samuel Bronson <na...@gm...> wrote:
>
> Hi. I'm trying to run some DPMI code under DOSEMU under valgrind,
> hoping to track down some sort of leak, but valgrind gets stuck on
> some of the segmentation-related instructions. For example, trying to
> run DJGPP's ls, I get this:
>
> ,----
> | 0x473600D: lss (%esp,,),%esp
> |
> | ------ IMark(0x473600D, 4) ------
> | PUT(60) = 0x473600D:I32
> | t14 = GET:I32(16)
> | PUT(16) = LDle:I32(t14)
> | PUT(290) = LDle:I16(Add32(t14,0x4:I32))
> |
> | 0x4736011: vex x86->IR: unhandled instruction bytes: 0x2E 0xFF 0x2D 0x0
> | ------ IMark(0x4736011, 0) ------
> | PUT(60) = 0x4736011:I32
> | PUT(60) = 0x4736011:I32
> | goto {NoDecode} 0x4736011:I32
> |
> | . 0 4736000 17
> | . 89 D4 0F A9 0F A1 07 1F 61 83 C4 10 9D 0F B2 24 24
> |
> | ==13075== Warning: client switching stacks? SP change: 0xbed3e730 --> 0x821dba0
> | ==13075== to suppress, use: --max-stackframe=1229845616 or greater
> | ==13075== Warning: client switching stacks? SP change: 0x821dbe4 --> 0x760
> | ==13075== to suppress, use: --max-stackframe=136434820 or greater
> | ==13075== valgrind: Unrecognised instruction at address 0x4736011.
> | ==13075== Your program just tried to execute an instruction that Valgrind
> | ==13075== did not recognise. There are two possible reasons for this.
> | ==13075== 1. Your program has a bug and erroneously jumped to a non-code
> | ==13075== location. If you are running Memcheck and you just saw a
> | ==13075== warning about a bad jump, it's probably your program's fault.
> | ==13075== 2. The instruction is legitimate but Valgrind doesn't handle it,
> | ==13075== i.e. it's Valgrind's fault. If you think this is the case or
> | ==13075== you are not sure, please let us know and we'll try to fix it.
> | ==13075== Either way, Valgrind will now raise a SIGILL signal which will
> | ==13075== probably kill your program.
> `----
>
> -- and that's AFTER adding support for the LSS instruction to VEX.
>
> It turns out that the unrecognized instruction is some kind of
> indirect far jump that ndisasm renders as:
>
> 00000000 2EFF2D00010203 jmp dword far [dword cs:0x3020100]
>
> and objdump as:
>
> 0: 2e ff 2d 00 01 02 03 ljmp *%cs:0x3020100
>
> (the address part is mostly bogus since I'm just working with the four
> bytes that VEX dumped for me, but that shouldn't matter.)
>
> It does not look as if either VEX or valgrind supports having CS refer
> to a non-flat segment; how crazy would it be to try to add this?
>
> P.S. The code for LSS should be in
> https://code.launchpad.net/~naesten/valgrind/vex-segmented soon; it's
> not there quite yet on account of having to push the entire SVN trunk
> history of vex, which is taking a bit -- it's been almost ten minutes
> already, and the progress bar looks to be at about 50%, though I have
> my doubts as to whether or not it means anything.
|
|
From: Nicholas N. <n.n...@gm...> - 2009-06-26 07:06:10
|
On Fri, Jun 26, 2009 at 1:22 PM, Samuel Bronson<na...@gm...> wrote: > Ping? Can you file a bug report? http://www.valgrind.org/support/bug_reports.html Thanks. Nick > At Wed, 24 Jun 2009 20:08:32 -0400, > Samuel Bronson <na...@gm...> wrote: >> >> Hi. I'm trying to run some DPMI code under DOSEMU under valgrind, >> hoping to track down some sort of leak, but valgrind gets stuck on >> some of the segmentation-related instructions. For example, trying to >> run DJGPP's ls, I get this: >> >> ,---- >> | 0x473600D: lss (%esp,,),%esp >> | >> | ------ IMark(0x473600D, 4) ------ >> | PUT(60) = 0x473600D:I32 >> | t14 = GET:I32(16) >> | PUT(16) = LDle:I32(t14) >> | PUT(290) = LDle:I16(Add32(t14,0x4:I32)) >> | >> | 0x4736011: vex x86->IR: unhandled instruction bytes: 0x2E 0xFF 0x2D 0x0 >> | ------ IMark(0x4736011, 0) ------ >> | PUT(60) = 0x4736011:I32 >> | PUT(60) = 0x4736011:I32 >> | goto {NoDecode} 0x4736011:I32 >> | >> | . 0 4736000 17 >> | . 89 D4 0F A9 0F A1 07 1F 61 83 C4 10 9D 0F B2 24 24 >> | >> | ==13075== Warning: client switching stacks? SP change: 0xbed3e730 --> 0x821dba0 >> | ==13075== to suppress, use: --max-stackframe=1229845616 or greater >> | ==13075== Warning: client switching stacks? SP change: 0x821dbe4 --> 0x760 >> | ==13075== to suppress, use: --max-stackframe=136434820 or greater >> | ==13075== valgrind: Unrecognised instruction at address 0x4736011. >> | ==13075== Your program just tried to execute an instruction that Valgrind >> | ==13075== did not recognise. There are two possible reasons for this. >> | ==13075== 1. Your program has a bug and erroneously jumped to a non-code >> | ==13075== location. If you are running Memcheck and you just saw a >> | ==13075== warning about a bad jump, it's probably your program's fault. >> | ==13075== 2. The instruction is legitimate but Valgrind doesn't handle it, >> | ==13075== i.e. it's Valgrind's fault. If you think this is the case or >> | ==13075== you are not sure, please let us know and we'll try to fix it. >> | ==13075== Either way, Valgrind will now raise a SIGILL signal which will >> | ==13075== probably kill your program. >> `---- >> >> -- and that's AFTER adding support for the LSS instruction to VEX. >> >> It turns out that the unrecognized instruction is some kind of >> indirect far jump that ndisasm renders as: >> >> 00000000 2EFF2D00010203 jmp dword far [dword cs:0x3020100] >> >> and objdump as: >> >> 0: 2e ff 2d 00 01 02 03 ljmp *%cs:0x3020100 >> >> (the address part is mostly bogus since I'm just working with the four >> bytes that VEX dumped for me, but that shouldn't matter.) >> >> It does not look as if either VEX or valgrind supports having CS refer >> to a non-flat segment; how crazy would it be to try to add this? >> >> P.S. The code for LSS should be in >> https://code.launchpad.net/~naesten/valgrind/vex-segmented soon; it's >> not there quite yet on account of having to push the entire SVN trunk >> history of vex, which is taking a bit -- it's been almost ten minutes >> already, and the progress bar looks to be at about 50%, though I have >> my doubts as to whether or not it means anything. > > ------------------------------------------------------------------------------ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Samuel B. <na...@gm...> - 2009-06-30 17:57:50
|
On Fri, Jun 26, 2009 at 3:06 AM, Nicholas Nethercote<n.n...@gm...> wrote: > Can you file a bug report? For the record: filed as https://bugs.kde.org/show_bug.cgi?id=197978 |