On Thu, 2012-04-26 at 16:42 -0400, Matt Broadstone wrote: > 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 (I believe >= 6.5) > > otherwise GDB does not understand the "|" target. > > > > Two alternatives: > > * compile + install a recent GDB > > (there is a kind of "magic" security signing which is needed). > > * alternatively: > > valgrind --vgdb-error=0 prog > > # and then in another shell, run: > > vgdb --port=1234 > > # in a third shell: > > gdb prog > > (gdb) target remote :1234 > > > > (NB: with this technique, there is no security: anybody which > > have access to your system can connect to the vgdb port nr). > > > > Philippe > > > > Okay, I was able to get that working. That is good news. You are now the unofficial MacOS Valgrind gdbserver tester :). ... > Here is the result of disassembling that instruction: > 0x0000000003a36b87 <__abort+220>: callq 0x3a9c772 <dyld_stub_sigprocmask> > 0x0000000003a36b8c <__abort+225>: ud2a This looks to match what Julian suggested (i.e. that it would be a ud2 invalid instruction). >From what I can see, the "small abort test" you did is calling another abort: Your small abort test case is causing a call to __kill: at 0x2C182A: __kill (in /usr/lib/system/libsystem_kernel.dylib)
while the invalid instruction you see is in another abort: ==66368== at 0x3A36B8C: __abort (in /usr/lib/system/libsystem_c.dylib) ==66368== by 0x3A36AAA: abort (in /usr/lib/system/libsystem_c.dylib) It looks like this last abort is implemented with an invalid instruction. => I believe that the invalid instruction is not the problem. It looks like TextEdit behaves differently for a native run and for a run under Valgrind. Only suggestions I have is to investigate the difference in execution between a native run and a run under Valgrind. One way to do that is to use two GDBs (one for native run, one for running under Valgrind). It would be much easier if you have the sources of _SCSessionUniverseByUIDAcquireAndLock If the behaviour difference is caused by syscalls not behaving the same way, you might investigate this using "strace" (if that exists on MacOS) and/or --trace-syscalls=yes arg of Valgrind. Philippe ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
