After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 336114 - desktop locks immediately after changing the system clock
desktop locks immediately after changing the system clock
Status: RESOLVED FIXED
Product: gnome-screensaver
Classification: Deprecated
Component: daemon
2.14.x
Other All
: Normal normal
: ---
Assigned To: gnome-screensaver maintainers
gnome-screensaver maintainers
: 336123 336965 341790 347723 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-26 21:06 UTC by Frank Arnold
Modified: 2006-08-28 03:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (4.21 KB, patch)
2006-08-22 22:12 UTC, Matthias Clasen
none Details | Review
second attempt (4.84 KB, patch)
2006-08-22 23:49 UTC, Matthias Clasen
none Details | Review

Description Frank Arnold 2006-03-26 21:06:07 UTC
As already stated in the summary, when one is changing the system time forward the screensaver will kick in.

We had two reports to Fedora BTS about this issue:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181882
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186800

Just to repeat my first comment on 186800, I think it is a bad choice to use time(2) values to calculate the elapsed time. GTimer would be more appropriate. But perhaps I'm missing something...
Comment 1 Sergej Kotliar 2006-03-26 22:40:20 UTC
*** Bug 336123 has been marked as a duplicate of this bug. ***
Comment 2 Christopher Brown 2006-03-27 13:35:32 UTC
I can confirm I am also seeing this after updating system clock following British Summer Time change. Have previously filed confirmation under:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181882
Comment 3 William Jon McCann 2006-03-30 16:50:58 UTC
I agree that using GTimer would be simpler and more portable.  CVS now uses GTimer.  However, I don't think this will have any effect on this.

The problem is that there doesn't seem to be a way to distinguish the jumping ahead of the clock from DST versus jumping ahead due to waking from hibernation.
Comment 4 Frank Arnold 2006-03-31 20:23:07 UTC
Hmm, haven't verified the behavior of GTimer until now. I would have expected it's independant from system clock, but obviously it isn't.
An odd scenario because of this: If you start a timer and roll your clock back, g_timer_elapsed gives 0 until the timer turns back positive.

A CPU timer would be nice, but I have no clue where to get or how to create one and make it portable... :(
Comment 5 Sergej Kotliar 2006-04-02 22:22:48 UTC
*** Bug 336965 has been marked as a duplicate of this bug. ***
Comment 6 Fabio Bonelli 2006-05-15 08:07:28 UTC
*** Bug 341790 has been marked as a duplicate of this bug. ***
Comment 7 William Jon McCann 2006-07-17 01:22:53 UTC
*** Bug 347723 has been marked as a duplicate of this bug. ***
Comment 8 William Jon McCann 2006-07-17 02:43:22 UTC
So we need to patch glib's gtimer to use clock_gettime(CLOCK_MONOTONIC, &v) if it is available.
Comment 9 Matthias Clasen 2006-08-22 17:54:34 UTC
William, do you happen to have a patch for that ? 
Comment 10 Matthias Clasen 2006-08-22 22:12:50 UTC
Created attachment 71409 [details] [review]
patch

Never mind, here is a patch. 

Does this fix your problem ?
Comment 11 William Jon McCann 2006-08-22 22:33:35 UTC
Matthias: That is basically what I tried first.  However, I don't think it is correct because it seems that 1) having clock_gettime doesn't mean that CLOCK_MONOTONIC is available 2) having clock_gettime and CLOCK_MONOTONIC as symbols doesn't mean that they are implemented and it needs to be checked via sysconf().

Wget has some example code:
http://svn.dotsrc.org/repo/wget/trunk/src/ptimer.c

So, we'd need to try clock_gettime() and fallback to gettimeofday() if it fails or is unavailable.  That likely means not storing the native time value in the structure and abstracting the computations in implementation specific functions or something...
Comment 12 Matthias Clasen 2006-08-22 23:49:35 UTC
Created attachment 71415 [details] [review]
second attempt

Hmm, I see.
Does this look better ?

Ignoring for now some of the fine points of the wget implementation, like
solaris HIRES clocks, preventing skew for nonmonotonic clocks, and windows
hires timers.
Comment 13 William Jon McCann 2006-08-24 17:12:20 UTC
Hmm, for some reason that additional check in configure.in interferes with the pthreads checks.  I get:

 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../glib -I../gthread -DG_LOG_DOMAIN=\"GThread\" -D_POSIX4_DRAFT_SOURCE -D_POSIX4A_DRAFT10_SOURCE -U_OSF_SOURCE -DG_ENABLE_DEBUG -DG_DISABLE_DEPRECATED -pthreads -g -O2 -Wall -MT gthread-impl.lo -MD -MP -MF .deps/gthread-impl.Tpo -c gthread-impl.c  -fPIC -DPIC -o .libs/gthread-impl.o
gcc: unrecognized option '-pthreads'
/bin/sh ../libtool --mode=link gcc  -g -O2 -Wall   -o libgthread-2.0.la -rpath /opt/gnome/lib  -version-info 1200:3:1200 -export-dynamic   gthread-impl.lo  -lpthreads ../glib/libglib-2.0.la -lrt
rm -fr  .libs/libgthread-2.0.la .libs/libgthread-2.0.lai .libs/libgthread-2.0.so .libs/libgthread-2.0.so.0 .libs/libgthread-2.0.so.0.1200.3 .libs/libgthread-2.0.so.0.1200.3T
gcc -shared  .libs/gthread-impl.o  -Wl,--rpath -Wl,/home/mccannwj/gnome2/glib/glib/.libs -Wl,--rpath -Wl,/opt/gnome/lib -lpthreads ../glib/.libs/libglib-2.0.so -lrt  -Wl,-soname -Wl,libgthread-2.0.so.0 -o .libs/libgthread-2.0.so.0.1200.3
/usr/bin/ld: cannot find -lpthreads
collect2: ld returned 1 exit status
make[2]: *** [libgthread-2.0.la] Error 1
make[2]: Leaving directory `/home/mccannwj/cvs/gnome2/glib/gthread'
make[1]: *** [all-recursive] Error 1
Comment 14 William Jon McCann 2006-08-24 17:21:59 UTC
Simply moving the check for clock_gettime to the end of configure.in seems to work.  And the patch does indeed fix the problem.  Thanks Matthias.
Comment 15 Matthias Clasen 2006-08-27 17:00:43 UTC
William, the pthreads problem is a missing include in the test program thats
included in configure.in, apparently triggered by some changes  in the glibc include structure now. I've fixed that in cvs
Comment 16 Matthias Clasen 2006-08-28 03:06:15 UTC
2006-08-27  Matthias Clasen  <mclasen@redhat.com>

	* configure.in: Check for clock_gettime.
	* glib/gtimer.c: Use Posix monotonic clocks instead of 
	gettimeofday when available.  (#336114, William Jon McCann)