On Fri, Jul 31, 2015 at 5:51 AM, Jon TURNEY wrote: > It would be very helpful if you could tweak the testcase there and produce > one which reproduces your problem. > > [1] > https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=75d5f68aabf62c42884ff935f888b12bbcd00001 > [2] https://sourceware.org/ml/newlib/2015/msg00321.html > I took one more shot at reproduction and I think the problem is that if code does a member-by-member initialization based on the fields defined by POSIX, it is likely that tm_zone won't be initialized and it could end up with a really bad value. Then strftime is likely to dereference it.
You can improve the likelihood of a crash by filling a struct tm with 0x54, like I did, but random circumstances could also effectively cause the same thing. We could implore the local Cygwin maintainer of mozjs to make sure that the code I mentioned earlier in that library zeros the struct tm, but there is only defensive programming recommending that, not a specification. And there could be other libraries or applications already tripping over this but not yet spending time on investigating it. If I took the time to think it through I think the additional logic for handling a NULL tm_zone is not necessarily the cause of the regression I'm facing, because the code I'm using through mozjs was not setting that field to NULL in the first place. I'm going to be away from the machines where I have this code at hand for the next two weeks, reading email but not equipped to do anything complicated about it. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
