No worries. Fix 2845 2882 2772 2948 2939 2935 2937 2814 2829 2887 2958 2962, and we will call that 0.9.2
Thanks! ..m On Mon, Jan 25, 2016 at 6:37 PM Eric S. Raymond <[email protected]> wrote: > Hal Murray <[email protected]>: > > The real question is are we going to track fixes from NTP Classic and if > so > > who, how, when, etc? There were a lot of patches released in the past > few > > days. I haven't scanned them. I don't think anybody has reviewed all the > > changes since the fork. > > Uh oh. We've had a moderately serious coordination failure here. > Fortunately > it should be recoverable without a huge amound of work. > > Just before 0.9.0 I reviewed all Classic changes from the fork to > September 29th and forward-ported everything relevant up to their fix > for bug 2902 on 29 September. The only thing I skipped that I regret a > little is pearly's cleanup of the calendar code - I have a bit set to > look back at that if we don't recruit him first. > > So the good news is we're caught up to well past the fork. > > After I did the catchup to late September I thought *you* had accepted > the job of tracking Classic's fixes while I concentrated on > capture/replay. That was in the proposed work plan I published just > after 0.9.0, which Mark approved. I thought you were obviously the best > positioned for this, since you track ntp-hackers and occasionally > contribute fixes there. > > As for where we are now, we elected not to port the Classic fix for > 2332 because we're planning to plain rewrite the async stuff. > Excluding the CVEs we already have fixes for, I don't actually see a > lot of bugfixes affter Sep 29 that need porting. I'm looking at the > Classic history now and I see these: 2845 2882 2772 2948 2939 2935 > 2937 2814 2829 2887 2958 2962. > > The better news is that most of these look like pretty trivial > patches; I'd be surprised if it takes more than a day and a half to > cross-port them all. If I'd known we'd had a disconnect and you > weren't working on this I'd have knocked off a few to relax from the > heavy stuff. > > > I looked into the ^C tangle. I'm trying to do it from scratch rather > than > > blindly copy the new code. Maybe I'll learn enough to understand why > the new > > code seems so complicated. > > > > It should be simple. The general idea is that the code that calls the > > command dispatcher does a setjmp and sets a flag for the ^C signal > handler. > > If the flag is on, the signal handler does a longjmp to bail from the > command. > > > > I put a printf in the top of the signal handler. The problem I'm seeing > is > > that the ^C handler goes away after the first jump. If it doesn't jump, > it > > keeps on working. > > Yeah, that looks like you're getting old-style resetting behavior when the > handler is called. See below... > > > > > An additional complication is that readline sets a bunch of signal > handlers. > > I haven't investigated. Since it isn't mentioned in the man page, I > assume > > it puts things back the way they were and/or calls the old signal > handler. > > > > I tried blindly setting the signal handler again but that didn't fix it. > > That's as far as I got before it was time for sleep. Maybe it's masked? > > > > I've spent some time googling but haven't found anything interesting yet. > > Are there any obvious gotchas associated with signals and longjmp that I > > should know about? > > Heh. Looks like you tripped over them already. This sort of thing is > par for the course when you mess with signal handlers. They're spooky > action at a distance and the side effects are hard to track. > > General advice: Be sure you're using sigaction(2) rather than signal(2), > the > older API may not preserve your signal bindings when a handler is fired. > Make > sure the handler flags do *not* include SA_RESETHAND. > > Be sure you signal-latch flag is declared volatile; compiler optimizations > can fuck you up otherwise. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> >
_______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
