|
From: mark r. <mar...@ya...> - 2004-06-02 01:24:33
|
Hello:
I'm trying to debug my application, but encountering a valgrind error in a
shared library I'm using (fmod sound lib.)
Can someone tell me if there's a way to skip around this, in essence to tell
valgrind "I know about that one, but ignore it for now."?
Thank you.
/m
Error text:
<snip>
==8208== warning: Valgrind's pthread_setschedparam does nothing
==8208== (scheduling not changeable)
==8208== your program may misbehave as a result
disInstr: unhandled instruction bytes: 0xF2 0xA5 0xF 0x77
at 0x3C3FC8C8: (within /usr/local/lib/libfmod-3.72.so)
==8208==
==8208== Process terminating with default action of signal 4 (SIGILL):
dumping
ore
==8208== Illegal operand at address 0xB802165C
==8208== at 0x3C3FC8C8: (within /usr/local/lib/libfmod-3.72.so)
==8208== by 0x3C3F67ED: FSOUND_Software_ClipAndCopy (in
/usr/local/lib/libf
d-3.72.so)
==8208== by 0xB800F45C: do__quit (vg_scheduler.c:1792)
==8208==
</snip>
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-02 09:09:24
Attachments:
repne-movs.patch
|
On Tue, 1 Jun 2004, mark risher wrote: > I'm trying to debug my application, but encountering a valgrind error in a > shared library I'm using (fmod sound lib.) > disInstr: unhandled instruction bytes: 0xF2 0xA5 0xF 0x77 > Can someone tell me if there's a way to skip around this, in essence to tell > valgrind "I know about that one, but ignore it for now."? You can't skip it, it's an instruction Valgrind doesn't know about. I've decoded this as "repne movs". The strange thing is, according to page 3-677 of the Intel x86 manual (vol 2), "movs" isn't allowed to take a "repne" prefix. What processor are you using? I assume this program works ok when not run under Valgrind. Anyway, it's not hard to deal with, try the attached partially-tested patch (against current CVS HEAD, but should work with eg. 2.1.1). N |
|
From: Tom H. <th...@cy...> - 2004-06-02 09:33:37
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> I've decoded this as "repne movs". The strange thing is, according to
> page 3-677 of the Intel x86 manual (vol 2), "movs" isn't allowed to take a
> "repne" prefix. What processor are you using? I assume this program
> works ok when not run under Valgrind.
Oops. I misread the A5 as A2 earlier... That'll teach me to look
things up when I'm barely awake ;-)
Searching on Google reveals one comment which suggests that although
it is undefined it actually does the same a REP MOVS which is not what
you'd expect... See this thread:
http://www.codecomments.com/A86_Assembler/message196060.html
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-06-02 09:57:46
|
On Wed, 2 Jun 2004, Tom Hughes wrote: > > I've decoded this as "repne movs". The strange thing is, according to > > page 3-677 of the Intel x86 manual (vol 2), "movs" isn't allowed to take a > > "repne" prefix. What processor are you using? I assume this program > > works ok when not run under Valgrind. > > Searching on Google reveals one comment which suggests that although > it is undefined it actually does the same a REP MOVS which is not what > you'd expect... See this thread: > > http://www.codecomments.com/A86_Assembler/message196060.html Which comment? I see this quote: I had problems - there is REP MOVS represented as REPE MOVS. Any other instructions with prefixes are treated as undefined. But in some programs, REPNE MOVS is used - it has different opcode, maybe undefined in Intel's docs, but it works (~ does the same). which maybe implies this, although I would have thought it means that "REPNE MOVS works, and does what you'd expect". But it's unclear. Perhaps some experimentation is in order? N |
|
From: Tom H. <th...@cy...> - 2004-06-02 11:02:24
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 2 Jun 2004, Tom Hughes wrote:
>
>> > I've decoded this as "repne movs". The strange thing is, according to
>> > page 3-677 of the Intel x86 manual (vol 2), "movs" isn't allowed to take a
>> > "repne" prefix. What processor are you using? I assume this program
>> > works ok when not run under Valgrind.
>>
>> Searching on Google reveals one comment which suggests that although
>> it is undefined it actually does the same a REP MOVS which is not what
>> you'd expect... See this thread:
>>
>> http://www.codecomments.com/A86_Assembler/message196060.html
>
> Which comment? I see this quote:
>
> I had problems - there is REP MOVS represented as REPE MOVS. Any other
> instructions with prefixes are treated as undefined. But in some
> programs, REPNE MOVS is used - it has different opcode, maybe undefined
> in Intel's docs, but it works (~ does the same).
>
> which maybe implies this, although I would have thought it means that
> "REPNE MOVS works, and does what you'd expect". But it's unclear.
> Perhaps some experimentation is in order?
It was the "(~ does the same)" that I was assuming meant it behaved
the same as REPE but maybe not. Maybe the "~" was meaning "not". Some
testing is in order anyway.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|