[Bug 12304] New: modem_applet: waitpid()'s return value causes wedging.
bugzilla-daemon at bugzilla.ubuntu.com
bugzilla-daemon at bugzilla.ubuntu.com
Thu Jun 30 21:05:57 UTC 2005
Please do not reply to this email. You can add comments at
http://bugzilla.ubuntu.com/show_bug.cgi?id=12304
Ubuntu | gnome-applets
Summary: modem_applet: waitpid()'s return value causes wedging.
Product: Ubuntu
Version: unspecified
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gnome-applets
AssignedTo: seb128 at ubuntu.com
ReportedBy: ralph at inputplus.co.uk
QAContact: desktop-bugs at lists.ubuntu.com
The other day the modem applet got wedged into a state where one of the
`Activate' or `Deactivate' menu items was sensitive yet selecting it did
nothing. It didn't alter ppp0's state, nor did the menu items switch
sensitivity.
Attaching ltrace to the running program showed it was repeatedly doing
{waitpid(), usleep(), gtk_main_iteration()}.
Today, inspecting the source finds
$ sed -n 614,620p gnome-applets-2.10.1/modemlights/modem-applet.c
while (waitpid (priv->pid, NULL, WNOHANG) <= 0)
{
usleep (2000);
while (gtk_events_pending ())
gtk_main_iteration ();
}
$
I think this is wrong. waitpid(2) says:
waitpid(): on success, returns the process ID of the child whose
state has changed; on error, -1 is returned; if WNOHANG was
specified and no child(ren) specified by pid has yet changed state,
then 0 is returned.
I was seeing -1 being returned, yet the code doesn't distinguish between
0 and -1. On 0, it should sleep and try again. On -1 it should maybe
sleep and try again depending on errno's value. For some values of
errno, e.g. ECHILD and EINVAL, it should not continue blindly looping
which would cause the observed symptoms.
Why waitpid() was unexpectedly returning -1 I don't know, probably
priv->pid didn't exist anymore. Code to distinguish between 0 and -1
may shed some light on that problem.
There may be other calls to waitpid() with similar issues.
--
Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
More information about the desktop-bugs
mailing list