Possibly a bug in glibc around the getrandom(2) implementation.

[Marcin Mielniczuk]

You're right I mixed it all up. My bad.

I fixed that to use PTRACE_PEEKUSER for RSP and now the RSP matches with
what gdb reports. This means the big getrandom buffers are all ok, first
is allocated somewhere else (static?)

     getrandom request: 0x00007f5e97a659a0 0x00007f5e97a659b8
     rsp is 0x7ffcd86af260
     getrandom request: 0x00007ffcd86ad5b0 0x00007ffcd86adf70
     rsp is 0x7ffcd86acdd8
     getrandom request: 0x00007ffcd86ace40 0x00007ffcd86ad800
     rsp is 0x7ffcd86acd60

I slightly modified the code to show buf, buf+len instead of buf, len.

But if I omit the poke for the second getrandom request, the program
completes successfully... The buffer is ok, fully contained in the stack:

      7ffcd8690000-7ffcd86b1000 rw-p 00000000 00:00 0                          [stack]

I double receive all messages from the mailing list. Is this the
expected behavior? I'm subscribed.


On 17.07.2017 20:52, Florian Weimer wrote:
> * Marcin Mielniczuk:
>
>> I decided to start printing the rsp to the stdout, in the following way:
>>                       register unsigned long rsp asm("rsp");
>>                       printf("rsp is %p\n", (void*) rsp);
> Doesn't this print the %rsp value in the tracing program, and not the
> traced program?