Hi there!
Comparing the output from gdb attached to valgrind gdbserver and the
core file valgrind creates, the thread order is inverted.
As I have more minor issues with gdb and valgrind core files, I do not
known if this is always the case.
For exactly this problem I have two possible
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 Fri, 2012-04-27 at 11:49 +0200, Matthias Schwarzott wrote:
Hi there!
Comparing the output from gdb attached to valgrind gdbserver and the
core file valgrind creates, the thread order is inverted.
As I have more minor issues with gdb and valgrind core files, I do not
known if this is
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,
