From bruen...@google.com on June 08, 2011 08:30:50

the __nptl_create_event routine, AFAICT, is used as part of the
communication between pthreads and gdb. gdb seems to set a hidden
breakpoint there. DR then decodes an int3 prior to ret (0xcc 0xc3) and
puts it into the code cache. the debugger then hits a trap on every
pthread_create or other place which calls __nptl_create_event. at
that point, the app code is 0xf3 0xc3 (repz ret) and the int3 is no longer
there, but DR has no way of detecting this change made by the debugger via
the kernel. the debugger handles these traps so this is just an annoyance
at this point but worth documenting.

interp: start_pc = 0x00007f21ada9e483
0x00007f21ada9e483 e8 48 e5 ff ff call $0x00007f21ada9c9d0 %rsp -> %rsp 0xfffffff8(%rsp)
0x00007f21ada9c9d0 cc int3
0x00007f21ada9c9d1 c3 ret %rsp (%rsp) -> %rsp
end_pc = 0x00007f21ada9c9d2

Program received signal SIGTRAP, Trace/breakpoint trap.

(gdb) x/5i 0x00007f21ada9e483
0x7f21ada9e483 <__pthread_create_2_1+1827>: callq 0x7f21ada9c9d0 <__nptl_create_event>

(gdb) disas __nptl_create_event
Dump of assembler code for function __nptl_create_event:
0x00007f21ada9c9d0 <+0>: repz retq
End of assembler dump.
(gdb) x/5bx 0x7f21ada9c9d0
0x7f21ada9c9d0 <__nptl_create_event>: 0xf3 0xc3 0x66 0x66 0x66

this is inside libpthread.so.0

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=490