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