2038 mitigations

General Discussion
1

Are there any plans or actions already taken for addressing the 2038 problem?

2

Are there any specific areas where you think action is needed in GStreamer? I’m not aware of anybody having gone systematically through the code to check if there’s something that would break, but I’m not aware of any specific code that would break as long as you use a Y2038-compatible libc.

3

I noticed that GST_TIME_TO_TIMEVAL asserts that the value will fit in a long before storing it in a GTimeVal. According to the documentation

on 32-bit systems, a timeval has a range of only 2^32 - 1 seconds, which is about > 68 years. Expect trouble if you want to schedule stuff in your pipeline for 2038.

4

That’s used in two places:

  • Passing to select() in gstpoll.c. It’s a relative number there so unless you plan to have a timeout >68 years in the future that’s not a problem
  • v4l2 timestamps. That’s potentially a problem but would require the v4l2 syscalls to be updated

There’s also the inverse GST_TIMEVAL_TO_TIME

  • v4l2, see above
  • getrusage() in the tracer and the transcoder CPU throttling clock, basically the same answer
  • rtsp-session: deprecated API only
  • pulse plugin: For debug logs, but libpulse API uses this and there’s not much we can do about that

Also struct timeval is only a problem on 32 bit systems, which we hopefully don’t run anymore in 14 years from now. And if your 32 bit Linux/glibc system is compiled with -D_TIME_BITS=64 (as will be the case for everything but x86 for all major distros) this is also not a concern.

5

Thanks for your quick response! That sound promising, so if I’ve understood you correctly 32-bit systems can be saved by compiling the with -D_TIME_BITS=64. But the macro asserts that the value will fit in a glong which will still be 32 bits?

6

Yes, see the definition of struct timeval on recent glibc:

struct timeval
{
#ifdef __USE_TIME_BITS64
  __time64_t tv_sec;		/* Seconds.  */
  __suseconds64_t tv_usec;	/* Microseconds.  */
#else
  __time_t tv_sec;		/* Seconds.  */
  __suseconds_t tv_usec;	/* Microseconds.  */
#endif
};

The macro would assert and that needs to be fixed. Also that unconditional usage of glong inside the macro.

Thanks for pointing that out :slight_smile: This should be fixed in clock: Fix 32 bit assertions in GST_TIME_TO_TIMEVAL (!6869) · Merge requests · GStreamer / gstreamer · GitLab

7

I’m happy to assist! :partying_face: I’ll let you know if I encounter anything else, though I’m not planning on examining everything :slight_smile:

1 Like
8

The Linux side of v4l2 have been addressed, I need to check whats the implications for GStreamer if any.

9

Probably have to use a new ioctl with new struct variants on the affected platforms at least? Currently it would probably fail at runtmie because we use the userspace version of struct timeval apparently, and that one will switch types depending on -D_TIME_BITS=64 and because of that doesn’t necessarily match what the kernel expects.

10

Use GDateTime instead of gmtime() (!6872) · Merge requests · GStreamer / gstreamer · GitLab is another related case. Doesn’t really matter as it would do the right thing anyway if -D_TIME_BITS=64 is used, but it also simplifies the code and make this someone else’s (GLib) problem.