Probably I should stop using unreleased github code. Release 2023c does not have this bug. On 24.11.23 16:29, Alois Treindl via tz wrote:
correction, the bug is also in RHEL 9 with gcc version 11.4.1
Just make all from fresh git clone, and run ./zdump -c 1880,2010 -v Europe/London Africa/Johannesburg
On 24.11.23 16:19, Alois Treindl via tz wrote:
I can demonstrate the bug. Please try
zdump -c 1880,2010 -v Europe/London Africa/Johannesburg in gdb debugger
b tzload
it stops 3 times. I let it run tzloadbody.
Once it loaded Johannesburg, I look at structure st
p *sp $1 = {leapcnt = 0, timecnt = 6, typecnt = 5, charcnt = 9, goback = false, goahead = true, ...
The goahead=true is incorrect.
It should be goahead=false
This happens only when I load several zones, i.e. Johannesburg after London.
None of the compile options like -std=c99 or -std=gnu11 fixes that issue on my RHEL 7 compiler gcc version 4.8.5.
I also tried compiler gcc version 9.3.1, same problem.
When I compile on RHEL 9 with gcc version 11.4.1 the problem does not appear. it gives goahead=false
The patch memset(&ls, 0, sizeof(ls)); fixes the issue for gcc version 4.8.5 and gcc version 9.3.1.
On 23.11.23 19:32, Alois Treindl via tz wrote:
I have observed occasional crashes in localtime.c in the current github version.
In one of my applications, localtime() is called multiple times for several zones.
The condition when the segmentation fault appears are herd to reproduce or demonstrate.
This patch in function tzload() however solves the issue:
--- localtime.c 2023-11-16 20:18:01.904577574 +0100 +++ a/localtime.c 2023-11-23 19:22:21.062249899 +0100 @@ -769,6 +769,7 @@ } #else union local_storage ls; + memset(&ls, 0, sizeof(ls)); return tzloadbody(name, sp, doextend, &ls); #endif }