[Jaunty] alarm-clock causes screen to freeze

Bug #321176 reported by Ivan Stetsenko on 2009-01-25
214
This bug affects 29 people
Affects Status Importance Assigned to Milestone
GNOME Automate
Undecided
Unassigned
Nominated for Trunk by Kẏra
PyGTK
Invalid
Undecided
Unassigned
Nominated for Main by Kẏra
Ubuntu
Low
Unassigned
Jaunty
Low
Unassigned
alarm-clock (Ubuntu)
High
Scott Kitterman
Jaunty
High
Unassigned
python2.6 (Ubuntu)
Low
Unassigned
Jaunty
Undecided
Unassigned

Bug Description

Steps to reproduce:

1. launch alarm-clock

What happens:

Image on the screen becomes frozen. Mouse pointer is moving, but if I'm clicking on something, I cannot see any reaction (however, there is a reaction, because if I'm trying to launch a program, I am able to see it after switching to terminal by ctrl-alt-f1 and running ps aux). It happens both with compiz and with metacity.

ii xserver-xorg-core 2:1.5.99.901-1ubuntu1
ii xserver-xorg-video-intel 2:2.6.1-1ubuntu1
ii alarm-clock 0.9.18-2

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

stetzen@stetzen-laptop:~$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Intel(R) 965GM GEM 20090114 x86/MMX/SSE2

TEST CASE:

Start alarm-clock, watch your system hang.

Reset the system.

Install the updated package.

Start alarm-clock, watch your system not hang.

i'm confirming this bug too.
i use Jaunty alpha3 fully updated
running the program from commandline doesn't give something about the freeze, actually no output at all.
also nothing found to the logs : .xsession-errors , /var/log/messages.

as noted to the general debug procedures https://wiki.ubuntu.com/DebuggingProgramCrash
the reporter should provide :
- a backtrace https://wiki.ubuntu.com/DebuggingProgramCrash - NOT attached because i haven't found any debug symbol packages (alarm-clock--dbgsym)
- an strace https://wiki.ubuntu.com/Strace - i attempted to provide an strace, log attached, but i had to kill alarm-clock after that so i am not sure how valid the .log is
- a valgrind https://wiki.ubuntu.com/Valgrind - i attempted to provide an Valgrind, log attached, but i had to kill Valgrind to make my desktop usable again so i am not sure how valid the .log is

also running Valgrind with application's name didn't work, log attached. i had to specify full path to start it with Valgrind

we certainly need some guidance here in order to provide useful bug report and feedback.
please tell us how because the desktop becomes completely unusable.

Changed in alarm-clock:
status: New → Confirmed
Tyler Crenshaw (tdcrenshaw) wrote :

i'm also seeing this on jaunty alpha 5 64bit

Still in alpha6.

Sander Stuurwold (sstuurwold) wrote :

I used it on 8.10 Now it gives me the message with title "You have old alarms" and body "It seems you missed some alarms, because your old alarm list is not empty.". When I click on "Close" it freezes.

zb (zaredb) wrote :

9.04 beta here

I've had this same problem. First crashed during my upgrade.

Had to uninstall from recovery console.

Took me many attempts to find out alarm-clock was the cause of the crash.

sabby7890 (tsalacinski) wrote :

Regarding Sander Stuurwold's response:

After clicking "OK" Alarm Clock initializes Python's threading system by calling:

gtk.gdk.threads_init()

And it seems this is where the crash occurs. I really can't do anything about that, since this function is required for AC to work and seems broken on Ubuntu (since it crashes on Ubuntu only).

Please verify if C version of Alarm Clock (Alarm-Clock-1.0a1) have this problem too.

I can confirm that the C version works.

On Sat, Mar 28, 2009 at 7:47 AM, sabby7890 <email address hidden> wrote:

> Regarding Sander Stuurwold's response:
>
> After clicking "OK" Alarm Clock initializes Python's threading system by
> calling:
>
> gtk.gdk.threads_init()
>
> And it seems this is where the crash occurs. I really can't do anything
> about that, since this function is required for AC to work and seems
> broken on Ubuntu (since it crashes on Ubuntu only).
>
> Please verify if C version of Alarm Clock (Alarm-Clock-1.0a1) have this
> problem too.
>
> --
> [Jaunty] alarm-clock causes screen to freeze
> https://bugs.launchpad.net/bugs/321176
> You received this bug notification because you are a direct subscriber
> of the bug.
>

swulf (swulf) wrote :

I have exactly the same issue as Sander Stuurwold above. On logging in I get a message box telling me 'You have old alarms - It seems you missed some alarms, because your old alarm list is not empty.' Closing this dialog freezes the system, although I can still move the mouse. However nothing responds to mouse clicks. System has to be hard rebooted.

This is following an update from Ubuntu 8.10 to Jaunty 9.04.

sabby7890 (tsalacinski) wrote :

If the C version works, this bug is no longer valid.

Also, it's an Ubuntu problem that the screen freezes - Python is just a scripting language and shouldn't be even able to hang the whole system. This bug should be posted as Ubuntu bug.

Kẏra (thekyriarchy) wrote :

It can't be posted as just an "Ubuntu" bug once a package has been assigned-- we must identify the package causing this error

ljuksi (ljuksi) wrote :

I attached a core dump, on my Jaunty Beta x64 machine it outputs this:

*** glibc detected *** /usr/bin/python: double free or corruption (fasttop): 0x0000000003202580 ***

sabby7890 (tsalacinski) wrote :

As I've told before, this isn't Alarm Clock's fault.

Why? Because this is written in Python and from Python side I can't even manage memory to crash like this. There is a bug in Python binding to some library in new Ubuntu (I know because it crashes for me too).

The only way to manage memory is to use Python's garbage collector which won't cause crash like this.

/var/lib/python-support/python2.6/gtk-2.0/gtk/_gtk.so[0x7f6fbf7218e0]

This line tells that it's because of broken GTK binding for Python in Ubuntu 8.10. If Python code can crash C library it's not the Python application's bug but security issue in Python or Python binding for some library - Python is only a scripting language just like perl or php.

It seems like a bug in PyGTK. As I said, it crashes right after starting the thread system.

Kẏra (thekyriarchy) on 2009-04-03
Changed in alarm-clock (Ubuntu):
status: Confirmed → Invalid
Changed in alarmclock:
status: New → Invalid
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report. This will greatly help us in tracking down your problem.

Changed in pygtk (Ubuntu):
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete

I can also confirm the bug. The attachment in my reply shows what happens when I start the application in the terminal.

Thanks.

ch_a_m_p (ch-a-m-p) wrote :

Confirmed in 9.04 beta

nguyenthanhvuh (thanhvu) wrote :

I also experience this bug

Okki (gnomelibre) wrote :

Same problem here

alarm-clock - 0.9.18-3
python2.6 - 2.6.2~rc1-0ubuntu1

Benjamin Tegge (livewirebt) wrote :

Since this seems to be a python issue and jaunty uses python 2.6 as default instead of 2.5 as intrepid did, has anyone tried running alarm-clock with python 2.5 on jaunty? How can do this? Simply changing:

#!/usr/bin/python
to
#!/usr/bin/python2.5

in /usr/bin/alarm-clock does not work for me.

Gustavo Carneiro (gjc) wrote :

It seems to be a python issue, but only when dealing with legacy/deprecated classes. It would not be hard to fix the applications; where you see:

class Foo:
    ...

Change it to:

class Foo(object):
   ...

And the problem should go away.

Christopher Berner (cberner) wrote :

I have the same problem in Jaunty RC, is there a workaround for this?

CRCarl (craigkcarl) wrote :

All -
      I am not quite sure how to proceed. I can confirm the issue is the use of deprecated classes. Running alarm-clock using Python 2.5 on Jaunty resolves the issue with alarm-clock. Having 2.5 installed along-side 2.6 broke all kinds of other things in my VM, I wouldn't suggest it. Python should be handling the errors a lot better, c'est la vie.
     I have managed to patch my local copy, it seems to be working fine. I can;
              1. Post the diffs where google can find them, people will have to apply the patches.
              2. Fork the project, post the updated code to github then forget about.
              3. Fork the project, rename/rebrand it, ask the MOTU's to add it to the repos.
                       3a. We are way, way past the Jaunty hard freeze, this likely wouldn't happen soon.
                       3b. Also, I hate to do that to the original developer.
              4. Something else? Can I get my patch added to the current package with the original developer?

Suggestions?

BTW - We might be to late already - https://bugs.launchpad.net/ubuntu/+source/alarm-clock/+bug/363937

C

Christopher Berner (cberner) wrote :

could you post the patch here as an attachment? I tried editing my local files, but wasn't able to fix the bug by changing the class style.

sabby7890 (tsalacinski) wrote :

I don't think updating the Python package will make any sense, because I am working on new version which is working perfectly under Ubuntu.

Christopher Berner (cberner) wrote :

If the python package is not going to be updated then it should be removed from 9.04, since right now it renders the user's desktop useless if it is used.

Severe bugs can be dealt with in a post release update once a clear fix is
available.

Christopher Berner (cberner) wrote :

Ok, but for anyone who upgrades from 8.10 to 9.04 and uses alarm-clock, their desktop will be inaccessible to them. (they will have to use recovery mode to uninstall alarm-clock, or a virtual console to kill it). This seems like a major problem that needs to be address *before* release, so that users of alarm-clock don't end up being locked out of their desktop. It seems like alarm-clock should be removed by the 9.04 upgrade utility if it is installed.

Scott Kitterman (kitterman) wrote :

So far no one has produced a solid patch for this problem, so where to upload it is moot. A fix in -updates would help upgraders too, so it's not to late.

Sebastien Bacher (seb128) wrote :

the valgrind log shows error in the python code and no pygtk lines

affects: pygtk (Ubuntu) → python2.6 (Ubuntu)
Changed in python2.6 (Ubuntu):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
status: Incomplete → New
Sebastien Bacher (seb128) wrote :

the issue is not a pygtk one

Changed in pygtk:
status: New → Invalid
sabby7890 (tsalacinski) wrote :

So if it's not a PyGTK bug, it must be Python. Basically, Python is a scripting language so it *SHOULD NOT* be able to crash entire machine. If it does, then there's a bug in Python. I'll try to create the new version as soon as possible, so someone can package it and push upstream.

Nico Bauer (oshelpdesk) wrote :

maybe someone can upload the new version to a PPA here at launchpad?

sabby7890 (tsalacinski) wrote :

This is the still unreleased alpha, although it's working fine but it's missing some features:

http://www.alarm-clock.pl/alarm-clock-1.0a2.tar.bz2

Moreno Garcia (gnumoreno) wrote :

I'm having the same problem here and I'm available to work with some developer by providing logs, etc.

Best Regards,

dirk (dirk-kuijsten) wrote :

I had the same problem upgrading to 9.04. The system crashed during the upgrade (twice!), but was far enough with upgrading the system just started normal. And after a "dpkg --configure -a" in the rescue mode, I thought all was done. But now alarm-clock started this bug after login. Not knowing what was causing the hang (i could go back to the other virtual terminals of course with ctrl-alt-Fn), I figured that the failed upgrade itself was the cause and had messed up my system. Thus I went through a backup restore process and trying the upgrade again (which failed again btw). It then finally dawned me it was something that was crashing the system during the gnome startup of the panel (alarm-clock was autostarted). And finally, about 4 hours later i found about the alarm-clock and how I could remove the applet, hidden in the .gconf/apps/panel/applets/ directory. Now my system works great, but alarm-clock is gone from my system.

I don't know which idiot thought this could be released in 9.04, but it should have been disabled or have given a warning during the upgrade!! It irritates me that this was known for months and nobody did anything to alleviate this bug. That's what the whole unstable testing release cycle is for: to make sure these bugs are not affecting normal users.
Sorry for the bashing, but this really bugged me.

I agree. If it was just alarm-clock, it'd been ok. It's not a critical application, and it's not supported. But it isn't just alarm-clock. This also happens if you try to strace something in gnome-terminal at least. Other things cause this to happen as well. I think this bug should've been marked with high priority and fixed before release. I hope it'll be fixed quickly, cause this is really annoying, and as you said, people who are running alarm-clock on startup, will have a useless system unless they're able to figure this out. Not everyone will be able to.

Christopher Berner (cberner) wrote :

why is this marked Invalid? This is 100% reproducible in the current package in the Jaunty repository.

Changed in alarm-clock (Ubuntu):
status: Invalid → Confirmed
Scott Kitterman (kitterman) wrote :

You start asking why and end up assuming you know there is no why. Why it's mark invalid against alarm-clock is that the bug (that manifests via alarm-clock) is caused by a problem in another package.

Please don't just start marking on bugs and filing people's in boxes. If you don't understand, ask. #ubuntu-bugs on Freenode IRC is a great place for this.

Changed in alarm-clock (Ubuntu):
status: Confirmed → Invalid
Andrew (andrew-rw-robinson) wrote :

I am not only seeing alarm-clock hang the UI, but it is locking up my computer. Happened 2x in a row.

This is on Jaunty amd64. I don't have time to troubleshoot it, so am removing the package.

Mikko Rantalainen (mira) wrote :

I don't care if the issue is in the alarm-clock, pygtk or somewhere else. The fact is that if I select Applications - Add/Remove... and search for an alarm clock I get package "alarm-clock". If I then proceed to install it and ever start it, my X session is immediately frozen. Happens on both x86_64 and i386 variants. Luckily, I know how to kill the application from another virtual terminal (I had to try killing processes until I hit alarm-clock, though...). However, an average Ubuntu user would think that the whole Ubuntu install just crashed.

Just upgrade, downgrade or remove the alarm-clock from the repositories immediately. It's clear that the software was NEVER even started during the release process of Jaunty! If *somebody* is able to successfully start and use Alarm Clock in Jaunty, then put it into the repository.

sabby7890 (tsalacinski) wrote :

Go to alarm-clock.pl and download alarm-clock-0.9.19 - fixes the bug. Ubuntu packagers can update the package so it won't cause freeze anymore. It can be easily packaged, because it's a small update of Python version.

hype (hypeuser-lp) wrote :

http://www.gnomefiles.org/app.php/Alarm_Clock

Indeed, just saw that on gnome-files.

I'll try that soon; thanks in advance for fixing the issue in 9.04 :>

Mikko Rantalainen, before whining:
1) just do it ...
2) there's no 2)

Christopher Berner (cberner) wrote :

@Scott Kitterman
The bug was, as far as I could tell in alarm-clock, not some other package. which is why I changed the status. And if you'll look at the <http://www.alarm-clock.pl/> webpage, you'll see that a new version has been released which fixes this bug. So it was in fact a bug in alarm-clock.

Back on topic. I can confirm that version 0.9.19 fixes this bug. After installing, I did have to move the glade and scalable folders from /usr/local/share/alarm-clock/ to /usr/share/alarm-clock/ so that AlarmClock could find them.

Scott Kitterman (kitterman) wrote :

OK. We can't do a wholesale update post-release, but if someone can figure
out which change/patch fixed this, we can get an update in.

hype wrote:
> http://www.gnomefiles.org/app.php/Alarm_Clock
>
> Indeed, just saw that on gnome-files.
>
> I'll try that soon; thanks in advance for fixing the issue in 9.04 :>
>
> Mikko Rantalainen, before whining:
> 1) just do it ...
> 2) there's no 2)
>

'It's clear that the software was NEVER even started during
the release process of Jaunty!'

Mikko is right. Stating the facts is not 'whining'.

sabby7890 (tsalacinski) wrote :
  • Fix Edit (357 bytes, text/x-diff)

It was a bug in Alarm Clock, indeed. But, it's still a bug in other package too - with this bug, a userspace application can hang the whole user's machine on purprose - this is called a virus. This can be used even by some malicious Firefox extensions. I strongly recommend someone to take a look at this and fix it in PyGTK package. I know that everything user needs to do is to switch to console and killall alarm-clock. But removing viruses from Windows is easy too, and causal users usually don't know how to do this.

If any application will call repeatedly a GTK function (in this case it was updating the status icon) from outside of the main GTK loop, it will hang. I forgot to enter the main loop, but as everyone noticed it was working in previous Ubuntu releases.

Mike Basinger (mike.basinger) wrote :

I have built version 0.9.19 which fixes the problem. I have added it to my ppa, https://edge.launchpad.net/~mike.basinger/+archive/ppa (as soon as it builds). I would suggest making this a backport if possible.

This should be done as a stable release update, not a backport.

kernel_script (kernelscript) wrote :

Same bug here.

I'm using Jaunty final.

Mike Basinger (mike.basinger) wrote :

Here is a debdiff for the package in Ubuntu 9.04. It is my first, so let me know if I need to change anything.

sabby7890 (tsalacinski) wrote :

Ok, Alarm Clock is fine, but what about the bug that caused screen to freeze? Will it be fixed or can I start writing a virus?;)

Scott Kitterman (kitterman) wrote :

The best contrubtion towards getting the underlying problem addressed would
be a minimal test case program that demonstrates the problem.

sabby7890, please stop nagging about viruses. This has nothing to do with viruses at all! A virus is an executable file that copies itself into another executable. This bug wouldn't in any way permit a user to write to its executable, nor any other executable, hence it's not a virus.

Though it is annoying that a bug in one application is able to "hang" the entire desktop, it is not in any way a security issue since you have to install the application and run it manually. You should be aware that any application you run will have all the same rights as you do, including deleting all your files, which would be alot more problematic than this bug. Also, this bug doesn't affect other users.

sabby7890 (tsalacinski) wrote :

Mr Jo-Erlend Schinstad,

Virus is an application that forces computer not to work properly. Notice that most Windows viruses nowdays are not copying itself to other executables, they're just starting when computer starts (they're placed in registry - HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Run if I remember correctly).

Recipe for virus:

Write a Firefox extension that will contain malicious code using this bug, use _UNPROTECTED_ .bashrc file in user's directory and start this app by doing:

sleep 10; DISPLAY=:0 ./virus_start

With this trick someone can hang user's desktop 10 seconds after he logs in. User only needs to download this extension (and this is possible to create such file because it's possible to save wallpaper in user's home directory from Firefox).

Of course this code needs to be injected to .bashrc, which is not write-protected (normal user can modify his own bashrc file). So this IS clearly a security issue. You see, most Windows computers are infected because of users installing software from P2P networks. Anyone can even post an application on GnomeFiles.org, no one checks these. If someone will install such app (even from DEB package) on his computer, you known what can happen. So IMHO this should be fixed immediately! With this trick, someone can make user's computer unusable. Before someone figures out to check .bashrc, user will reinstall Linux or install Windows. You can even name the virus instead of "virus_start" something like "gnome-session" or similiar. Any app from Gnomefiles or Firefox extension can make the executable working by doing "chmod +x virus". See? No need to infect other executables in order to destroy a system.

If someone will post that "this app on Gnomefiles makes computer hang on every boot", virus could activate for example on 1st of September. That's why I think that bug with hanging desktop should be fixed with nr 1 priority.

But there's another thing:

This X11-hanging bug happens in Fedora 11 too, so it's not Ubuntu-specific. I am trying to reproduce this bug by writing a test case, no luck though.

Gustavo Carneiro (gjc) wrote :

Here's how I think you can reproduce the problem. Just write a program (C or Python, doesn't matter) that:

 1. Creates a toplevel window (make it a fullscreen window for increased effect)
 2. calls gdk_pointer_grab on that window
 3. never calls gdk_pointer_ungrab

From that moment on, the program captures the pointer (and as side effect also the keyboard). Consequently, the clueless user thinks that "X is frozen", when in actual fact is just "poorly written app grabs the pointer and never ungrabs it".

This is *NOT* a PyGTK bug. This is *NOT* a Gtk+ bug. This is *NOT* a Xorg bug.

Every programmer that ever needed to write code to grab the mouse pointer will occasionally temporarily write code that grabs the pointer but forgets to ungrab it. I have been there myself. But the X session is not completely frozen. You can recover by pressing <Ctrl><Alt>F1, login in a linux console, and manually kill the offending program. Then you can go back to the X11 console (normally <Alt>F7), and everything is back to normal.

And by the way, I am tired of receiving these messages about a non-pygtk bug just because I am watching pygtk bugs in general. If someone knows of a way for me to opt out, please let me know. Thanks!

sabby7890 (tsalacinski) wrote :

Gustavo:

Click unsubscribe on the right.

I am actually tired of this bug too. I've fixed it, it works, bug is closed. It's not my fault thoguh that the whole session is frozen - it was working previously, right now someone changed something somewhere and it started to freeze. If you want - upgrade the package, remove the package, fix the other broken package, but please stop posting here info that you don't care where the bug is or that I am nagging you. If you don't like my app just don't use it - you have it completely for free, I am wasting my time to write it, just to hear that I've made a small mistake and my work should be completely removed, sorry.

Please post here only if really necessary.

Gustavo Carneiro (gjc) wrote :

Sorry, sabby, I hope I wasn't too offensive, not my intention. Hoping you meant someone else. :)

You are right, this is a very tiny mistake. The X11 API makes it very easy to "freeze" the desktop, as I explained.

I am only annoyed that I have received over 60 comments on a bug that isn't even pygtk related. There is no Unsubscribe on the right, because I am not directly subscribed, only the launchpad team "GNOME Python Maintainers" is subscribed, so I received emails too. Even though this is not Python related, I do not know how to remove myself or the team. If anything I am annoyed at launchpad, not at any individual participating in this discussion.

This bug is not closed. It's not related to alarm-clock, sabby, it's related to Python. It's not fixed. Upgrading alarm-clock will not prevent the same thing from happening when you run strace, for instance.

To say that a "Virus is an application that forces computer not to work properly" is false. However, this is not the place to discuss it.

If you want to unsubscribe from this bug (please do), you can click the link marked "Unsubscribe". It's on the upper right, right above the list of subscribers.

Scott Kitterman (kitterman) wrote :

>If you want to unsubscribe from this bug (please do), you can click the
>link marked "Unsubscribe". It's on the upper right, right above the list
>of subscribers.

Not if, like many of us, you are subscribed to the bug because you or a team you are a member
of is subscribed to bugs for the package.

Scott Kitterman (kitterman) wrote :

>This bug is not closed. It's not related to alarm-clock, sabby, it's
>related to Python.

It does seem that alarm clock triggers the bug. If there any disagreement that the proposed
alarm clock patch avoids it?

sabby7890 (tsalacinski) wrote :

I won't unsubscribe, because this patricular bug number 321176 is related to my application Alarm Clock. I am subscribed automatically to any bug that is triggered in my application, because I am the main developer. I wanted to say that THIS bug can be closed because Alarm Clock no longer suffers from it, and freezing desktop when you do strace is not a bug in Alarm Clock. Please don't tell me to unsubscribe from my own bugzilla.

Anyway, I am trying to write a testcase to demonstrate the bug. The bug itself was caused (I think) by doing changes on the status icon from outside of main GTK loop without gtk.gdk.threads_enter() and gtk.gdk.threads_leave(). This funcion reads birthdays from a file on hard drive, checks if there's a birthday today, and then changes the status icon tooltip and icon.

This is not efficent, because it does that every second and every second it sets the Alarm-Clock's tray icon to normal or alarm-caution.svg. That's why I am reimplementing it, but this seems to trigger the bug.

On Fri, May 1, 2009 at 11:00 AM, sabby7890 <email address hidden> wrote:
> <snip>
> I wanted to say that THIS bug can be closed because Alarm
> Clock no longer suffers from it, and freezing desktop when you do strace
> is not a bug in Alarm Clock.
> <snip>

I agree, lets have the alarm clock bug fixed and close this bug. If
there is a bug it GTK then it should be reported as a separate bug.

>Anyway, I am trying to write a testcase to demonstrate the bug.

Thank you. This is a very valuable step towards getting to the root of this.

whitis (whitis) wrote :

This is a serious bug that renders the entire system unusable until reboot unless the user knows about console switching and killall and even though the bug itself may not be in the package code, this bug can not be closed until there is a new package that requires a version of python packages that does not activate the bug. A bug in the dependency listing of a package is a valid bug even if a new version of the dependencies does not yet exist to fix the problem.

Changed in alarm-clock (Ubuntu):
status: Invalid → Confirmed
whitis (whitis) wrote :

Original, more detailed, version of this comment lost due to launchpad bugs.

This bug is present on Ubuntu 9.04 with the latest version of the package from the repository installed (including stable, testing, and unstable).

gustavo appears to be incorrect; this is not your run of the mill grab pointer bug; the system responds to mouse events, you just can't see the result.

sabby7890's patch is already applied. It is also a bad patch file since it was produced without using "diff -u" and will therefore apply incorrectly and without warning to a modified or different version of the file.

I have changed the status from invalid to confirmed. This package is broken, whether or not the problem exists in the application code itself. Until a new package is released that has either a workaround that actually works or depends on a new version of pygtk that fixes the problem, this bug should not be closed.

The new package version alluded to in #369549 is not available to apt-get in stable/testing/unstable/jaunty-updates. Perhaps this will change soon. But until you can "apt-get update alarm-clock" and fix the problem, this is an open bug.

Linux cervantes 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux
ii python-gtk2 2.14.1-1ubuntu1
ii nvidia-173-modaliases 173.14.16-0ubuntu1 Modaliases for the NVIDIA binary X.Org drive
ii nvidia-180-kernel-source 180.44-0ubuntu1 NVIDIA binary kernel module source
ii nvidia-180-libvdpau 180.44-0ubuntu1 Video Decode and Presentation API for Unix
ii nvidia-180-modaliases 180.44-0ubuntu1 Modaliases for the NVIDIA binary X.Org drive
ii nvidia-71-modaliases 71.86.08-0ubuntu1 Modaliases for the NVIDIA binary X.Org drive
ii nvidia-96-modaliases 96.43.10-0ubuntu1 Modaliases for the NVIDIA binary X.Org drive
ii nvidia-common 0.2.11 Find obsolete NVIDIA drivers
ii nvidia-glx-180 180.44-0ubuntu1 NVIDIA binary Xorg driver
ii nvidia-settings 180.25-0ubuntu1 Tool of configuring the NVIDIA graphics driv
ii alarm-clock 0.9.18-3

Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty

Changed in alarm-clock (Ubuntu):
assignee: nobody → Scott Kitterman (kitterman)
importance: Undecided → High
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package alarm-clock - 0.9.18-3ubuntu1

---------------
alarm-clock (0.9.18-3ubuntu1) karmic; urgency=low

  * Work around GTK related hang to fix LP: #321176

 -- Mike Basinger <email address hidden> Wed, 29 Apr 2009 16:41:24 -0600

Changed in alarm-clock (Ubuntu):
status: In Progress → Fix Released
Scott Kitterman (kitterman) wrote :

@Mike: thanks for the debdiffs. They look good to me except a couple of minor changelog issues. I rewrote your debian/changelog entries to make them more verbose. Also the target for a post-release update should be jaunty-proposed (I fixed that too).

Changed in alarm-clock (Ubuntu Jaunty):
assignee: nobody → Scott Kitterman (kitterman)
importance: Undecided → High
milestone: none → jaunty-updates
status: New → In Progress
Scott Kitterman (kitterman) wrote :

I've uploaded Mike's change for Jaunty. From here is has to be approved by the motu-sru team, accepted by an archive-administrator, and then it goes to jaunty-proposed for testing. Once it tests out, it will be copied to jaunty-updates for everyone.

description: updated
Changed in alarm-clock (Ubuntu Jaunty):
assignee: Scott Kitterman (kitterman) → nobody
status: In Progress → Fix Committed
sabby7890 (tsalacinski) wrote :

Hello,

I've managed to write a simple testcase in Python. Hope that helps. I have something to do today, but I'll try to check out if it's possible in C. After starting crash.py by doing python crash.py you need to kill it by doing killall -9 python.

Gustavo Carneiro (gjc) wrote :

About your test case:

 1. It uses threads with incorrect locking, see attached patch to fix it;

 2. In my system, X is not frozen, just becomes very slow. But the program is asking for trouble by continually updating the status icon in a while True: loop without even a pause for breath between each loop;

3. I am actually able to kill the program with a simple Ctrl-C, evidencing that X is not completely frozen.

So perhaps this is just a performance issue wrt gtk status icons. I see no bug here, just a denial of service. Or we could consider a gtk bug for momentarily freezing an entire X session while a status icon is being updated.

motu-sru ACK.

Scott Kitterman (kitterman) wrote :

Accepted into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in pygtk (Ubuntu Jaunty):
status: New → Fix Committed
Changed in python2.6 (Ubuntu Jaunty):
status: New → Fix Committed
tags: added: verification-needed
Changed in pygtk (Ubuntu Jaunty):
status: Fix Committed → New
Scott Kitterman (kitterman) wrote :

Sorry about that. It's alarm-clock that's been accepted.

Changed in python2.6 (Ubuntu Jaunty):
status: Fix Committed → New
icantcontrol (icantcontrol) wrote :

I install all updates of ubuntu9.04 and still have this problem. I updated my laptop from 8.10 to 9.04.

Then i also installed it on my friends Sony Vaio and his laptop also freezed after starting alarm clock.

The fix for jaunty-proposed is still waiting to be built. We're in the
middle of the first sync from Debian for Karmic, so things are very backed
up currently.

nakki (titibanjekistan) wrote :

no more freeze installing Alarm Clock 0.9.19 from getdeb http://www.getdeb.net/app/Alarm+Clock

sabby7890 (tsalacinski) wrote :

@Gustavo Carneiro

Yes, that's the whole point. Just forgot to add time.sleep(1) to make this happen every one second - then X won't be busy at all.

That's the whole point - when developer forgets to add gtk.gdk.threads_enter() and gtk.gdk.threads_leave() this happens.If you add time.sleep(1) GTK won't be constantly updating the status icon (it will do it every one second) and top will show nothing, but screen will be still frozen.

Sebastien Bacher (seb128) wrote :

let's change this task so pygtk subscribers stop being spammed

affects: pygtk (Ubuntu) → ubuntu
Changed in ubuntu:
importance: Undecided → Low
status: New → Invalid
Steve Beattie (sbeattie) wrote :

Closing python tasks, since this is an issue with alarm-clock itself.

Changed in python2.6 (Ubuntu):
status: New → Invalid
Changed in python2.6 (Ubuntu Jaunty):
status: New → Invalid
Paul Elliott (omahn) wrote :

I'm pleased to report that alarm-clock 0.9.18-3ubuntu0.1 from jaunty-proposed no longer hangs my system.

tags: added: verification-done
removed: verification-needed
Steve Beattie (sbeattie) wrote :

I have also verified that the version of alarm-clock in jaunty-proposed fixes the issue and appears to set alarms properly.

Christopher Berner (cberner) wrote :

This seems to have fixed the freezing issue. However with the version from jaunty-proposed, the repeat sound feature seems to be broken. If I create an alarm that's suppose to ring, it will ring once and then stop, even if I've set it to ring multiple times. Is anyone else experiencing that?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package alarm-clock - 0.9.18-3ubuntu0.1

---------------
alarm-clock (0.9.18-3ubuntu0.1) jaunty-proposed; urgency=low

  * Backport change for 0.9.19 to work around GTK related hang, LP: #321176

 -- Mike Basinger <email address hidden> Wed, 29 Apr 2009 16:41:24 -0600

Changed in alarm-clock (Ubuntu Jaunty):
status: Fix Committed → Fix Released
Nils Blomqvist (cew5813) wrote :

I installed Alarm Clock using the built in feature in Ubuntu. When I start it the screen freezes, just like what this bugreport describes. I can however just press CTRL+ALT+1 and kill the application. From what I read this is already supposed to be fixed?

Christopher Berner (cberner) wrote :

I don't think the fix was ever accepted into the main repository, try enabling jaunty-proposed and installing alarm-clock from there.

Nils Blomqvist (cew5813) wrote :

I can't even find alarm-clock version 0.9.18-3ubuntu0.1 in synaptic. It only shows 0.9.18-3. I'm very sure I have the jaunty-proposed repository enabled. I installed the .deb package from http://www.getdeb.net/release/4294 and now it works just fine! Why isn't this package in the main repository?

On Wed, Jul 08, 2009 at 01:54:43PM -0000, Nils Blomqvist wrote:
> I can't even find alarm-clock version 0.9.18-3ubuntu0.1 in synaptic. It
> only shows 0.9.18-3. I'm very sure I have the jaunty-proposed repository
> enabled. I installed the .deb package from
> http://www.getdeb.net/release/4294 and now it works just fine! Why isn't
> this package in the main repository?

Are you sure you have the jaunty-updates repository enabled? The
alarm-clock package in -proposed got promoted to -updates:

$ rmadison alarm-clock | grep jaunty
alarm-clock | 0.9.18-3 | jaunty/universe | source, all
alarm-clock | 0.9.18-3ubuntu0.1 | jaunty-updates/universe | source, all

--
Steve Beattie
<email address hidden>
http://NxNW.org/~steve/

Nils Blomqvist (cew5813) wrote :

That explains it. I had temporary disabled -updates repository because of stuff I didn't want at the time.

Kẏra (thekyriarchy) wrote :

Since the bug in alarm clock has been fixed, but the problem in whatever it was (python?) as far as i can tell was not fixed, can we open a seperate bug report for that?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers