severity 309779 important
retitle 309779 gtimer: freeze followed by huge window height in config
thanks

Julian T J Midgley <[EMAIL PROTECTED]> writes:

> It does.  Ok, that looks like a separate bug in enlightenment as well
> ;-)

I'm going to reduce the severity of the bug to important, since the
critical part looks like it was Enlightenment's fault.  It's either
important or grave, depending on how reproducible the problem is.  I don't
think this should be an RC bug for sarge, based on what we know so far,
although if we find a quick solution I'll certainly try to get that
included if there's still time.

> It got into that state after gtimer froze for the first time.  As I
> remember, I switched to the desktop that gtimer was running on, and
> tried to switch from one task to another, to find that it wouldn't work
> (I believe the timer was still running, but I couldn't change tasks,
> click on any of the menus or icons, and ^I and ^D didn't increment or
> decrement the current task time).  I would then either have hit CTRL-C
> from the xterm in which I started it, or pkill'ed it (I don't remember
> which, I may have had to SIGKILL it, but I probably started with
> SIGTERM).  After this, I started it up again, and it was at this point
> that the window corruption appeared (forgive me, I may have
> misremembered this in the original bug report - it happened a couple of
> days ago).

I've just gone through all of the source code, and it looks like the
insane window size must have come from something external to gtimer.
There's only one place that gtimer ever changes the value of the window
height and that's in the exit callback, and there it changes it to the
return value of gtk_window_get_size().  Every place that it resizes its
own window, it resizes it to the value stored in the configuration file.

It sounds like something either in the Gtk libraries or in the window
manager or elsewhere on the system resized the window (maybe to some sort
of overflow or absolute value of a negative height?) and GTimer got that
value back from gtk_window_get_size and dutifully saved it to the config
file.  I don't know whether this was some sort of side effect of the hang,
or if it's what caused the hang (I think there's some evidence that the
latter may be the case, since clearly that window size causes bizarre
problems for Englightenment).

> Reproducing the freeze could be difficult - is there anything I can do
> to get you more information if/when it happens again?

If you can get this to happen again, I'd really like to see what the
GTimer process is doing during the freeze.  One or both of:

    strace -p <pid>

or

    gdb /usr/bin/gtimer
    attach <pid>
    backtrace

would be very useful.  This looks like it might be hard to track down.

-- 
Russ Allbery ([EMAIL PROTECTED])             <http://www.eyrie.org/~eagle/>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to