[email protected] 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. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
