[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#814668: installing libglib2.0-0:kfreebsd-i386 on amd64 resets system clock to 1970



Package: libglib2.0-0
Version: 2.46.2-3
User: helmutg@debian.org
Usertags: rebootstrap

Hi,

I was wondering why my clock is wrong so often. It goes back to 1970
occasionally. After some bisection, I could narrow the issue down to
installing libglib2.0-0. This sounds completely wrong as libglib2.0-0 is
never supposed to change the clock at all. How could it possibly contain
code to do that? So let's look at how to reproduce this:

# dpkg --print-architecture
amd64
# dpkg --add-architecture kfreebsd-i386
# apt-get update
...
# apt-get install libglib2.0-0:kfreebsd-i386
...
Setting up libglib2.0-0:kfreebsd-i386 (2.46.2-3) ...
Segmentation fault
Segmentation fault
Processing triggers for libc-bin (2.21-7) ...
# date
Fri Jan  2 14:37:50 UTC 1970
#

The culprit is in the postinst. There it invokes:

/usr/lib/i386-kfreebsd-gnu/glib-2.0/glib-compile-schemas /usr/share/glib-2.0/schemas

Running strace on it reveals:

| execve("/usr/lib/i386-kfreebsd-gnu/glib-2.0/glib-compile-schemas", ["/usr/lib/i386-kfreebsd-gnu/glib-"..., "/usr/share/glib-2.0/schemas"], [/* 25 vars */]) = 0
| strace: [ Process PID=16574 runs in 32 bit mode. ]
| getuid()                                = 0
| stime([139068])                         = 0
| getgid()                                = 0
| times({tms_utime=0, tms_stime=0, tms_cutime=0, tms_cstime=0}) = 1963081704
| break()                                 = -1 ENOSYS (Function not implemented)
| getuid()                                = 0
| access("", W_OK|0x50)                   = -1 EINVAL (Invalid argument)
| --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
| +++ killed by SIGSEGV +++

What happens here is that a kfreebsd-i386 binary is run on a linux
kernel. Unfortunately, their syscall interfaces are sufficiently similar
that some syscalls actually are successful in doing what they never
intended: changing the system clock.

I wish I could tell you how to fix this, but I don't know a good way.
Possibly glibc should do something different? In any case, I am
documenting the issue here and I added d-cross@l.d.o to seek ideas
there.

Helmut


Reply to: