Bug 3614 - userinfo (not finger) eats my memory; kills X as result
userinfo (not finger) eats my memory; kills X as result
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: usermode (Show other bugs)
6.0
i386 Linux
high Severity high
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-06-21 09:31 EDT by Telsa Gwynne
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-09-27 14:45:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Telsa Gwynne 1999-06-21 09:31:13 EDT
I thought initially this was a GNOME bug but perhaps not. Running GNOME on RH6.0 (with a 2.2.9-ac-something kernel) on an i586.
man userinfo: typo in "options" - should be no apostrophe in 'its'. (same in man userhelper, come to think of it)
And when you run userinfo in X, either from a gnome-terminal or from the gnome menu, it displays the information, gives you two options (Okay and Exit) and clicking on okay leads to a 'error: invalid call to subprocess' message. If you peer at this error message long enough without clicking okay on it ("long enough" for me is about fifteen seconds) everything goes very slow and begins to lock up.
First time I did this, I finally got back to a virtual console to find the errors just in time to see the X server die. userinfo kept running and 'top' showed it eating 129meg and with 30% of CPU and 60% of the memory.
Ouch.
If you run it from a gnome-terminal, you get an additional error message about "/usr/sbin/userhelper: option requires an argument -- f".
Marked as high because I think killing X servers and eating memory like that is probably a bit worse than typos.
Comment 1 Jay Turner 1999-06-21 10:27:59 EDT
Typo needs to be fixed.  In addition, I am able to recreate error
after clicking "OK" in the display.  Not able to recreate the memory
leak as described.
Comment 2 Michael K. Johnson 1999-07-13 11:07:59 EDT
I have recreated the memory leak once, but cannot do it reliably.
It only happened once while I was debugging trying to find another
problem, which also went away.

See also bug #2362, which I was debugging when I saw this problem.
Comment 3 Michael K. Johnson 1999-08-27 21:01:59 EDT
Just reported that clearing a field can cause this, will be
investigating...
Comment 4 Michael K. Johnson 1999-08-27 21:22:59 EDT
Unfortunately, I can't reproduce that problem, either, on my machine.
What version of glib are you running?
(rpm -q glib)
Comment 5 Michael K. Johnson 1999-09-21 17:23:59 EDT
Found and fixed -- or, since I can't reproduce this on demand, I
have made a change in the source code to something that might
have been causing this and was certainly wrong.  If you can
reproduce this with usermode-1.14 or later, I definitely want
to know about it.
Comment 6 Michael K. Johnson 1999-09-21 18:27:59 EDT
Actually, get usermode-1.15 or later, as that fixes some other
bugs where "random" things wouldn't get set properly.
Comment 7 Telsa Gwynne 1999-09-26 14:25:59 EDT
Get usermode-1.15 from where? I couldn't get onto redhat's ftp site,
and hensa (ftp.hensa.ac.uk, a reasonably good mirror) has 1.10 as the
latest. That aside, I eventually got a copy, and yes, appears fixed:

	no error message when I run it from gnome-terminal
	a 'password' box pops up instead of the error message now
	and I haven't managed to make it go mad again since.

Thanks!
Comment 8 Michael K. Johnson 1999-09-27 14:45:59 EDT
Thanks for testing.

Note You need to log in before you can comment on or make changes to this bug.