system/musl: src/time/__tz.c: scan_trans: line 299 the a-1 is what's wrong. necessarily a==0 at that line
Should we apply this?
03:11 < rcombs> user's running into a crash and I'm pretty sure it's musl's bug here: https://github.com/bminor/musl/blob/master/src/time/__tz.c#L299
03:11 < feepbot> musl/__tz.c at master · bminor/musl · GitHub (Unofficial mirror of etalabs musl repository. Updated daily. - musl/__tz.c at master · bminor/musl)
03:12 < rcombs> not sure what this code is trying to do, but what it actually does (AFAICT) is read the last byte of the transition-times table and use it as an index into the local time types table
04:16 < quinq> rcombs, maybe sharing a crashing code would help too
04:17 < rcombs> user is seeing a crash with this tzif file: https://puu.sh/IHXP9/8c2eeb49cc
04:29 < rcombs> I assume the input time is far in the past
04:29 < rcombs> in a call to mktime
05:39 < rcombs> I can't repro the crash on unmodified musl, but only because the file always gets mapped in with a readable page afterwards for some reason
...
14:46 < Hello71> rcombs: are you running it in gdb
14:58 < dalias> rcombs, is the tz file valid?
14:59 < dalias> rcombs, maybe mmap PROT_NONE before calling any time functions?
15:02 < dalias> what time do you use as input to test it?
15:03 < dalias> i tried mapping a PROT_NONE page after it and still no crash
15:03 < dalias> ok tm_year=-100 crashes
15:35 < dalias> yes i believe scan_trans just has an off-by-one in the binary search :(
15:35 < dalias> anyone up for reading it with me to figure out what it should be doing?
15:36 < dalias> hmm no not sure...
15:41 < dalias> ahh no, it's not that
15:46 < dalias> it's the index[m-1] that's invalid
15:47 < dalias> for distant past where m=0
15:47 < dalias> hmm no.. n>1 so m=0 is not reachable in the loop
15:51 < sh4_> hmm, reading you it would appear you debug without gdb...
15:52 < dalias> :)
15:52 < dalias> line 299 the a-1 is what's wrong. necessarily a==0 at that line
15:52 < dalias> but it's not clear what the logic should be
16:24 < dalias> ok the problem this code is trying to solve is that, if the input timestamp is in local time, we can't tell if it's before or after the transition without knowing the pre-transition offset
16:47 < dalias> that code was all wrong-ish; i think this fixes it: http://ix.io/3P9e