On Sat, Apr 28, 2012 at 1:39 PM, Matt Broadstone mbroa...@gmail.com wrote:
On Fri, Apr 27, 2012 at 6:42 PM, Julian Seward jsew...@acm.org wrote:
On Friday, April 27, 2012, Matt Broadstone wrote:
On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote:
* change the line
On Fri, Apr 27, 2012 at 6:42 PM, Julian Seward jsew...@acm.org wrote:
On Friday, April 27, 2012, Matt Broadstone wrote:
On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote:
* change the line
MACX_(__NR___pthread_sigmask, __pthread_sigmask),
to read
On Thu, Apr 26, 2012 at 5:08 PM, Julian Seward jsew...@acm.org wrote:
Okay, I was able to get that working. Here is the result of
disassembling that instruction:
0x03a36b8c __abort+225: ud2a
Yeah, so as expected it's died on ud2a, as the
vex amd64-IR: unhandled instruction
I reproduced this with the trunk on 10.7.3 using TextEdit, as you said.
It's pretty clear from --trace-flags=1000 output that it happens
because the syscall __pthread_sigmask isn't supported, and so returns
with failure. This presumably spooks /usr/lib/libsystem_c.dylib and
so it calls
* change the line
MACX_(__NR___pthread_sigmask, __pthread_sigmask),
to read
MACX_(__NR___pthread_sigmask, __pthread_sigmask),
Oops. I mean, change it to
MACXY(__NR___pthread_sigmask, __pthread_sigmask),
J
On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote:
* change the line
MACX_(__NR___pthread_sigmask, __pthread_sigmask),
to read
MACX_(__NR___pthread_sigmask, __pthread_sigmask),
Oops. I mean, change it to
MACXY(__NR___pthread_sigmask,
On Friday, April 27, 2012, Matt Broadstone wrote:
On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote:
* change the line
MACX_(__NR___pthread_sigmask, __pthread_sigmask),
to read
MACX_(__NR___pthread_sigmask, __pthread_sigmask),
Oops. I mean,
On Thursday, April 26, 2012, John Reiser wrote:
It's a *BUG* in valgrind that valgrind does not print the bytes [or words,
etc.] of the instruction stream that valgrind does not understand.
[This is immediately obvious to *EVERY* user, but so far the developers
have been oblivious.]
It
On Thu, 2012-04-26 at 09:29 -0400, Matt Broadstone wrote:
As for doing a db-attach, that seems to have failed as well - I never
make it to a gdb session. Here is the full output of a db-attach
valgrind run on TextEdit.app:
==76980== Attach to debugger ? --- [Return/N/n/Y/y/C/c]
On Thu, Apr 26, 2012 at 2:06 PM, Philippe Waroquiers
philippe.waroqui...@skynet.be wrote:
On Thu, 2012-04-26 at 09:29 -0400, Matt Broadstone wrote:
As for doing a db-attach, that seems to have failed as well - I never
make it to a gdb session. Here is the full output of a db-attach
valgrind
On Thu, 2012-04-26 at 14:17 -0400, Matt Broadstone wrote:
and then:
(gdb) target remote | /usr/local/bin/vgdb
| /usr/local/bin/vgdb: Undefined error: 0
You must have a version of gdb recent enough (I believe = 6.5)
otherwise GDB does not understand the | target.
Two alternatives:
*
On Thu, Apr 26, 2012 at 3:27 PM, Philippe Waroquiers
philippe.waroqui...@skynet.be wrote:
On Thu, 2012-04-26 at 14:17 -0400, Matt Broadstone wrote:
and then:
(gdb) target remote | /usr/local/bin/vgdb
| /usr/local/bin/vgdb: Undefined error: 0
You must have a version of gdb recent enough
Okay, I was able to get that working. Here is the result of
disassembling that instruction:
0x03a36b8c __abort+225: ud2a
Yeah, so as expected it's died on ud2a, as the
vex amd64-IR: unhandled instruction bytes: 0xF 0xB
line implies -- 0F 0B is ud2a.
The real question is, why
On Tue, Apr 24, 2012 at 6:16 PM, Philippe Waroquiers
philippe.waroqui...@skynet.be wrote:
On Tue, 2012-04-24 at 14:06 -0400, Matt Broadstone wrote:
Not sure how to post to this thread having just signed up for the
list, but hopefully this routes correctly..
Hi,
I wanted to confirm that the
Not sure how to post to this thread having just signed up for the
list, but hopefully this routes correctly..
Hi,
I wanted to confirm that the aes changes in trunk do indeed solve that
unrecognized instruction issue, however,
I am still experiencing immediate termination whenever I use valgrind
On Tue, 2012-04-24 at 14:06 -0400, Matt Broadstone wrote:
Not sure how to post to this thread having just signed up for the
list, but hopefully this routes correctly..
Hi,
I wanted to confirm that the aes changes in trunk do indeed solve that
unrecognized instruction issue, however,
I am
On Thu, 2012-02-09 at 13:40 +, Tom Hughes wrote:
On 09/02/12 13:00, Eliot Moss wrote:
0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST.
Someone else will have to address that (if at all).
There's a bug for that already:
https://bugs.kde.org/show_bug.cgi?id=290655
I just attached
Hi All,
I am trying to use Valgrind on OS X 10.7.3, and when I try to start a Cocoa
application, it always crashes at the following point:
vex amd64-IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8
0x6A
==71202== valgrind: Unrecognised instruction at address 0x3945c0b.
On 2/9/2012 6:55 AM, Istvan Csanady wrote:
Hi All,
I am trying to use Valgrind on OS X 10.7.3, and when I try to start a Cocoa
application, it always crashes at the following point:
vex amd64-IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8
0x6A
That looks like a variant
On 09/02/12 13:00, Eliot Moss wrote:
0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST.
Someone else will have to address that (if at all).
There's a bug for that already:
https://bugs.kde.org/show_bug.cgi?id=290655
Tom
--
Tom Hughes (t...@compton.nu)
http://compton.nu/
On Thu, Feb 9, 2012 at 5:00 PM, Eliot Moss m...@cs.umass.edu wrote:
I was wrong :-( ...
0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST.
Someone else will have to address that (if at all).
Sorry ... Eliot
There used to be a bug about incorrect declaration of AESKEYGENASSIST:
On 02/09/2012 03:50 AM, Istvan Csanady wrote:
vex amd64-IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8
0x6A
Any help is greatly appreciated.
Such as, RTFM? It's even a FAQ!!
Begin at http://valgrind.org . Notice Documentation in the sidebar.
Click on FAQ.
On Thu, 2012-02-09 at 17:47 +0400, Alexander Potapenko wrote:
under Valgrind on your machine?
If it returns 0, it means that the code you're running is incorrectly
assuming AES support on the CPU (this is still a reason to fix
AESKEYGENASSIST)
Otherwise cpuid is broken under Valgrind.
at runtime if AES is supported or not (e.g. if this is checked at
installation time and different executable is installed depending on
this install check, then no luck (until Valgrind supports the AES
instructions).
Yeah, I agree with that analysis. The failing instruction is in a
system
FYI: I am busy working on implementing the AES instructions. Not very
advanced yet, but I guess it should arrive in the coming weeks.
Philippe, it is great that you are working on this, would be very useful
for the project I am working on. Unfortunately I am not qualified to help,
but hope your
25 matches
Mail list logo
