Aw: Re: Crash when recording clock_gettime
benjaminking at web.de
Mon Aug 28 13:19:13 UTC 2017
Hi Robert (wow, you're fast)!
> > My libc is custom built with frame pointers but without further modifications.
> Can you try it with system libc?
I'll try that a bit later.
> > I have not seen this with an earlier release of rr yet. Any ideas?
> If it works in rr 4.5.0 you could bisect to find the regression.
git bisect tells me that e7b00db is the first bad commit.
> Try recording with -n to see if this is related to syscall buffering.
No, 'rr record -n a.out' does not do anything different.
When I set RR_LOG=all:warn, then I get this for commit e7b00db:
rr: Saving execution to trace directory `/home/bki/.local/share/rr/a.out-39'.
[WARN signal_state_changed() errno: SUCCESS] Delivered core-dumping signal; may misrecord CLONE_CHILD_CLEARTID memory race
=== Start rr backtrace:
=== End rr backtrace
Aborted (core dumped)
Is this what is to be expected when a tracee is crashing?
For the previous commit, there is no logging except for the "Saving execution to trace...".
> Nothing else springs to mind immediately.
I'll doublecheck with the default libc, then.
More information about the rr-dev