Anybody know how to debug things like this?

[Hal Murray]

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
> that?   

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.