Crash when recording clock_gettime

Benjamin King benjaminking at
Mon Aug 28 20:14:37 UTC 2017

Hi Rob,

> I could reproduce the identical issue on my laptop. This has Ubuntu 16.04
> with a stock libc6 (libc6_2.23-0ubuntu9_amd64.deb) and a stock gcc 5.4.0
> compiler.
> [...]
> I'll see if I can figure out where that address is coming from which crashes
> the process.

Could it be ASLR? I disabled it with "sudo sysctl -w
kernel.randomize_va_space=0" and now rr does not crash. My default is 2, 1
crashes as well.

I tried disabling it because I had the impression that some trampoline
function in clock_gettime jumped to a bad place with rr's commit e7b00db.

clock_gettime from my libc disassembles to this:
0000000000115810 <__clock_gettime@@GLIBC_PRIVATE>:
  115810:	55                   	push   %rbp
  115811:	53                   	push   %rbx
  115812:	48 89 f5             	mov    %rsi,%rbp
  115815:	89 fb                	mov    %edi,%ebx
  115817:	48 83 ec 08          	sub    $0x8,%rsp
  11581b:	48 8b 05 c6 3a 2b 00 	mov    0x2b3ac6(%rip),%rax        # 3c92e8 <_dl_open_hook@@GLIBC_PRIVATE+0x8>
  115822:	48 c1 c8 11          	ror    $0x11,%rax
  115826:	64 48 33 04 25 30 00 	xor    %fs:0x30,%rax
  11582d:	00 00 
  11582f:	48 85 c0             	test   %rax,%rax
  115832:	74 2c                	je     115860 <__clock_gettime@@GLIBC_PRIVATE+0x50>
  115834:	ff d0                	callq  *%rax

Both commit e7b00db and the previous one are going through this, but the call
to *%rax sends rr commit e7b00db to a bunch of instructions that are not in
the disassembly of my libc. I also fail to understand what they are supposed
to do and they crash, eventually.

The parent of e7b00db is calling into this:
mov    $0xe4,%eax
Which, I believe, is how libc handles the clock_gettime internally (0xe4
being the number of the clock_gettime-syscall).

Now, should I disable ASLR when using rr in general, or is something else
going on?


More information about the rr-dev mailing list