On Wed, Jul 5, 2017 at 1:43 PM, Johannes Schultz <deb...@sagamusix.de> wrote:
>
>> None of the internal assertions in tzfile.c have to do with low
>> memory, they have to do with logical consistency and expected
>> outcomes.
>
> Okay, so let's look at the stack trace again and where it failed.
> The failing line 779 in __tzfile_compute is:
>
> if (__tzname[0] == NULL)
> {
> assert (num_types == 1); // <-- boom
>
> So, where is __tzname[0] being set? Depending on the path taken, it can be
> either of these:
>
> line 627: __tzname[0] = NULL; // initial value
> line 646: __tzname[0] = __tzstring (&zone_names[types[i].idx]);
> line 686: __tzname[0] = __tzstring (zone_names);
> line 756: __tzname[dst] = __tzstring (&zone_names[idx]);
>
> Internally, __tzstring calls malloc. If malloc fails, it returns NULL.
> So it is entirely possible that this assertion will fail because of an
> out-of-memory situation.Perfect, in which case it *should* be fixed to make this more robust in the face of low memory. > No of course this is bad, but so far the integrity has not been compromised. Agreed. > It just means that the function really should return with an error now. As > far as I can see there are currently no facilities for returning an error in > this particular function, but I guess it really should be able to propagate > allocation failures to the library functions that call it, so that those can > return an error to the user (if that is part of their API contract, that > is). I agree. If you have the opportunity please file a match bug with upstream at sourceware.org/bugzilla. That way upstream is made aware of the issue. As far as I can see we probably need to fix all cases of __tzstring returning NULL and do something appropraite. It only ever returns NULL on ENOMEM. Cheers, Carlos.
