Compatibility issue when mrouted was built using a Y2038-ready toolchain for a 32-bit target

[jjr-simiatec]

Hey @troglobit! I discovered this when compiling mrouted 4.6-dev using a Buildroot v2024.08.1 derived toolchain that had the Build Y2038-ready code option enabled and target set to ARM Cortex-A7. This results in the following being added to CPPFLAGS:

-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64

During compilation warnings are emitted, for example:

log.c: In function ‘logit’:
log.c:125:45: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 6 has type ‘__suseconds64_t’ {aka ‘long long int’} [-Wformat=]
  125 |         fprintf(stderr, "%02d:%02d:%02d.%03ld %s", thyme->tm_hour,
      |                                         ~~~~^
      |                                             |
      |                                             long int
      |                                         %03lld
  126 |                 thyme->tm_min, thyme->tm_sec, now.tv_usec / 1000, msg);
      |                                               ~~~~~~~~~~~~~~~~~~
      |                                                           |
      |                                                           __suseconds64_t {aka long long int}

These can then translate into runtime errors if mrouted is provoked in the right way:

Core was generated by `mrouted -d all -n'.
Program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
#0  strlen () at ../sysdeps/arm/armv6t2/strlen.S:126
#1  0x76e80782 in __printf_buffer (buf=buf@entry=0x7ea1c128, format=format@entry=0x4f2a5c "%02d:%02d:%02d.%03ld %s", ap=...,
    ap@entry=..., mode_flags=mode_flags@entry=0) at vfprintf-process-arg.c:435
#2  0x76e80e66 in __vfprintf_internal (s=s@entry=0x76f43b08 <_IO_2_1_stderr_>, format=0x4f2a5c "%02d:%02d:%02d.%03ld %s",
    format@entry=0xb <error: Cannot access memory at address 0xb>, ap=..., ap@entry=..., mode_flags=mode_flags@entry=0)
    at vfprintf-internal.c:1544
#3  0x76e7a490 in __fprintf (stream=stream@entry=0x76f43b08 <_IO_2_1_stderr_>, format=0x4f2a5c "%02d:%02d:%02d.%03ld %s")
    at fprintf.c:32
#4  0x004e5ec8 in logit (severity=severity@entry=5, syserr=syserr@entry=0, format=0x4f09c0 "%s%s") at log.c:125
#5  0x004e03ba in final_init (id=id@entry=0, arg=arg@entry=0x0) at main.c:431
#6  0x004e085c in main (argc=<optimized out>, argv=<optimized out>) at main.c:413

The other symptom I noticed is that runtime counters as displayed by mroutectl appear to be slow. It's most likely a formatting problem as above, but just thought I'd mention it...

The easiest way to see this is to run an instance of mrouted on two different nodes such that they show up in each others Neighbor Table as displayed by mroutectl. One node is running the Y2038-ready build while the other is running a build with a natively sized time_t. The neightbor Uptime ticks up every second on the native node but not on the Y2038-ready node.

[troglobit]

Interesting observations, I'll have a look at it over the weekend! I've at least reproduced the build warnings. The counter issue could definitely be related, but it'll take me a while to find and dust off an old 32-bit machine ... I'll see what I can do

[troglobit]

Should be fixed now.

The other symptom I noticed is that runtime counters as displayed by mroutectl appear to be slow.

This is possibly because of 53f1916, which reverted an old change of the internal TIMER_INTERVAL from 2 seconds back to 5 seconds.