Anybody know how to debug things like this?
hmurray at megapathdsl.net
Fri Jul 15 03:35:11 UTC 2016
esr at thyrsus.com said:
> It's like a symbolic debugger that keeps an execution trace and lets you
> step backwards in time. Under rr you could induce the crash, then step back
> to the last syscall.
I don't think that's going to help. I'm in a signal handler from the current
attempted syscall. What I need is to get the call number. Things are
confused since the low level thread stuff is magic. (at least to me)
Normally I can just get it from the name of the next frame on the stack.
Sometimes glibc uses old or different syscalls. So far, I have always been
able to figure things out. For some of the thread stuff, I had to look at
the source for pthread_create, but google found it on github.
> I'm worried about it. Not for any specific reason, it just trips my
> "Danger! Danger!" sensors. I've got a bad feeling that it might be one of
> those 'innocuous' changes that come back to bite us in the ass.
Me too, but I can't see any solid reason.
The lock in memory needs to be moved up too. (Only root can ask for
everything, or we need another capability or ...)
I'll keep testing it. It makes finding syscalls used by threads/DNS easier,
and we'll need that in case the pool stuff decides it needs more servers.
> I want to ask a different question: why the early thread launch? Can we move
It's getting called from config_peers in ntp_config. I don't know of any
reason why we couldn't move it.
These are my opinions. I hate spam.
More information about the devel