On Wed, Jul 5, 2017 at 9:13 AM, Johannes Schultz <deb...@sagamusix.de> wrote: > mktime is supposed to return -1 and, according to cplusplus.com, has a > no-throw guarantee for C++ code. So even if some internal memory cannot be > allocated, I expect mktime to return with an error value and not cause a > SIGABRT. > I found it difficult to reproduce this outside my afl-instrumented > environment, but I hope the stack trace helps with verifying whether this is > a valid bug. If you need a test case to reproduce, let me know.
If an internal assertion in tzfile.c triggers then it means that the integrity of the library is compromised. None of the internal assertions in tzfile.c have to do with low memory, they have to do with logical consistency and expected outcomes. I've reviewed tzfile.c, tzset.c, and mktime.c and it's hard for me to see what low-memory path could trigger the assertion. One possible hypothesis is that your program is corrupting library data given certain AFL input. You will have to review your AFL input in more detail to see why it is causing a SIGABRT. In general the library should not SIGABRT for normal conditions like low-memory. I agree that if you find that is *really* the case, then we can fix this upstream. Cheers, Carlos.