@reinob - no need to apologize, you're amongst the last i'd feel offended from .

however, if you're going to look at h-h code, you'd better use the CSSU one (https://gitorious.org/community-ssu/hildon-home)

I had a quick look and it seems that it's all actually handled by libhildon-plugins-notify-sv.so (nsv_plugin_play_event).

But that library seems to be closed.
Interesting strings in it:

nsv_profile_get_volume
nsv_profile_get_system_volume
nsv_util_valid_rootfs_sound_file
nsv_util_valid_sound_file
register_alarm_clock
register_alarm_calendar
pb_playback_* (libplayback-1)

It may also be a problem in the way it interacts with pulseaudio (pa_* -- libpulse, libpulse-mainloop-glib, libsndfile).

If anybody (freemangordon?) has the chance/time/skills to decompile libhildon-plugins-notify-sv.so, we might get to the end of this..

Let me chime in here and cross link to the h-h bug thread (see this and ff posts).

After aspersing sh (also bb-power) and some fruitful discussions with iDont (many thanks to him), I am very convinced that freemangordon is right and we suffer from that ppoll/pselect armel bug.
Meanwhile I made a "possible workaround" (again THX iDont):
I put all my widget commands (that were suspicious to not give back output and hereby blocking h-h, which in fact causes alarm to popup but not sound) into single excutable sh scripts.
Then I changed code in DCEW to
This should timeout the called command and hereby ends it and unblock h-h. But this is still in testing (maybe for weeks) and there is no positive test report to be expected.Only time counts

So maybe all others experiencing this alarm bug (especially don and mr_pingu) could you try my approach also, please? (precondition: bb-power or timeout)

But I would be glad to get that lib decompiled and found that bug inside. Nevertheless I saw a command that just did not terminate and this for sure will block h-h.

Sounds plausible from what've read about it. AFAIK, both glibc and kernel need to be changed, and glibc already received a patch (2.5.1-1eglibc27+0m5+cssu0 which i have). I guess at least a kernel (pre-kp52/cssu3) got one too?

Damn!

I got h-h hanged again today.
So, it seems my workaround with wrapping all widget commands into sh scripts and call them with timeout does not work (which I do not understand).
We should continue this specific bug here, right?


--edit
This one is solved, see above mentioned link and ff.

Sorry, started to post in CSSU devel thread ...

Hey freemangordon,

your guinea pig maybe has something new?

But it could also be caused again by hildon-home (you remember? ). I cannot remember 100% if I had that behaviour before using your lib, but I think so that it happened to me before ...

I had an alarm ringing this morning (yeah, ringing with sound), popup came up asking to snooze or stop. But as I wanted to snooze: no chance. No reaction on stop either. Even pressing beside that pop up did not do anything. Nor pushing the power button helped.
So I let it ring out and relied on my N9 to wake me up

After waking up I could push snooze and popup came up again after 5 minutes. Then I pushed stop and it vanished.

Then I checked my logs and they showed that at waking up the hildon-home was not frozen (at least not with "read(xx, <unfinished>". But after I was able to push stop, the h-h was frozen. And it got unlocked by my script some time later.

Any idea why the pop up did not react?

--edit
rechecked my logs
and after rethinking that shows that most probable the h-h was not frozen at ring time (08:15), but got instantly at the pop up came up. I think, h-h got waked up to show the alarm ui pop up, hereby trying to update the widgets (event: on desktop change) and BOOM: hanging. So no reaction anymore possible to the popup. And that also explains why the snoozes did not ring.
And also
So looks like a h-h problem again, hmm?

But what I do not get (yet) is why did the pop up not respond first (but rang), but on second snooze pop (not ringing)?
I checked manually the "hanging" status at 08:20.and that showed So it should have still been unresponsive, or?

--another edit
Oops, sorry.
Think this post belongs to this thread: [ANNOUNCE] Alarm-UI replacement.
So I copied this post and pasted it here. Let us continue in this thread.

--edit
For all who are following:
I could verify this today morning. Pop up comes up, alarm IS ringing, but buttons do not respond (you need to cut power or let it ring out). After that there is no snooze function (pop up yes, but no ring tone).
It is definitely the widgets hanging.
Possible solution to this is to set the loop time to less than snooze time (e.g. 4 minutes).
For sure I do not know how to get the pop up to respond to stop/snooze the alarm.

So I think we may "forward" this behaviour to here.

I've just seen this one too, only with CSSU-Thumb.

Edit: osso-systemui-alarm version 0.3.3+0cssu0

Cant find it in the repos. I would to download the thumb version. Thanks

http://wiki.maemo.org/Community_SSU/Thumb#Installation

Thumb uses separate repos. If merlin1991 doesn't ring a bell then follow the link above.

There is x86 binary, I run IDA against it, it is not impossible to RE it and fix the problem, but I wonder if it really makes sense.