Closed Bug 276110 Opened 20 years ago Closed 19 years ago

Shared memory segments and semaphores are not released on exit

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
1.7 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: trona, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 netscape 7.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 netscape 7.0

When Mozilla -- and Firefox -- start, shared memory segments and semaphores are
created. When Mozilla -- and Firefox -- exit, the shared memory segments and
semaphores are not removed and remain active ('ipcs' shows them). Restarting
either Mozilla or Firefox creates additional shared memory segments and
semaphores. Logging out does not remove the shared memory segments or semaphores
(I remove them with 'ipcrm').

Reproducible: Always

Steps to Reproduce:
1.Start Mozilla or Firefox
2.Exit Mozilla or Firefox
3.Execute 'ipcs'

Actual Results:  
Shared memory segments and semaphores are created on every start and additional
shared memory segments and semaphores are created on every restart.

Expected Results:  
Shared memory segments and semaphores should be released by the application on exit.
When I do this, I see the number of entries in the 'ipcs' output that have my
username attached go up by one when I start and go back down by one when I quit.

Do you have any plugins installed?  The Java plugin, specifically?

Also, isn't the kernel responsible for cleaning up structures like this when the
process terminates?
(In reply to comment #1)
> When I do this, I see the number of entries in the 'ipcs' output that have my
> username attached go up by one when I start and go back down by one when I quit.
> 
> Do you have any plugins installed?  The Java plugin, specifically?
> 
> Also, isn't the kernel responsible for cleaning up structures like this when the
> process terminates?

Plugins installed are:
-rwxr-xr-x   1 root root 2096844 2004-12-22 18:09 libflashplayer.so*
lrwxrwxrwx   1 root root      71 2004-12-18 15:12 libjavaplugin_oji.so ->
/usr/lib/j2sdk1.4.2_04/jre/plugin/i386/ns610-gcc32/libjavaplugin_oji.so*
-rwxr-xr-x   1 root root   20864 2004-12-17 09:36 libnullplugin.so*
-rwxr-xr-x   1 root root 1853430 2005-01-02 15:52 mplayerplug-in.so*
-rwxr-xr-x   1 root root   57457 2005-01-11 07:34 nphelix.so*
-rw-r--r--   1 root root  884488 2005-01-07 14:18 nppdf.so

I am evaluating the beta vesion of Adobe Reader (Acrobat 7.0).

I have other applications -- notably Informix and SETI@Home -- that use a
"shared memory model," both allocate shared memory and semaphores and both
release them when the process exits. I wouldn't swear to it, but I believe MySQL
does the same. In any event, there are no corpses left over when any of these exit.

I could be wrong, but when I've written code that uses shared memory and
semaphores, I'm responsible for releasing the segments and semaphores when the
program ends (I usually do that with a signal handler to make sure). I happened
to notice the group of segments and semaphores doing something else and tracked
them down to starting and stopping both Mozilla and Firefox. For example, I
removed the segments and semaphores before starting Mozilla to make these notes
and ipcs shows:

fubar-trona-/home/trona: ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 98861057   trona     777        393216     2          dest
0x00000000 98992130   trona     666        134976     1          dest
0x000069b7 99024899   trona     660        64528      0

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x000069b7 1605632    trona     660        1

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

If I exit Mozilla, those will still be there (nattch will be zero), if I then
restart Mozilla, there will be an additional set and that will go on as long as
I keep stopping and restarting Mozilla. Just doesn't seem right somehow.

To be honest, I don't know enough about the Linux kernel to know if it is
supposed to handle this sort of thing -- the kernel is Linux fubar 2.6.7 #1 Wed
Jun 16 16:23:03 PDT 2004 i686 unknown unknown GNU/Linux, built by Slackware as
part of the Slackware 10.0 release. I have not touched it (if I should, I'd
appreciate knowing that and thank you).

That's pretty much all I know.
no, the kernel won't release sysv ipc structures after the processes exit. the
apps must do this themselves.
So the first step is to try starting Mozilla without any of the plugins.  Does
that still cause the problem to happen?
(In reply to comment #4)
> So the first step is to try starting Mozilla without any of the plugins.  Does
> that still cause the problem to happen?

Yep.

I moved plugins in /usr/local/firefox to plugins.bak, made a new plugins
directory, copied the null plugin into it, started Firefox, stopped Firefox, and
there were the corpses. Did the same thing with Mozilla with the same result.

Like somebody said, it's the responsibility of the application to detach any
shared memory or semaphores and it just doesn't look like the application is
doing that.
Yeah, but I can't find anywhere that "the application" (Mozilla code) is
creating a shared memory segment or semaphore.  It would be somewhat interesting
to discover what code was creating it, given a breakpoint on the right glibc
symbol.  A stack for semget and shmget would be informative, though I find
myself inclined as bz is to blame a plugin, especially Java.

Can you try with a new untar of the app, and a fresh profile?
(In reply to comment #6)
> Yeah, but I can't find anywhere that "the application" (Mozilla code) is
> creating a shared memory segment or semaphore.  It would be somewhat interesting
> to discover what code was creating it, given a breakpoint on the right glibc
> symbol.  A stack for semget and shmget would be informative, though I find
> myself inclined as bz is to blame a plugin, especially Java.
> 
> Can you try with a new untar of the app, and a fresh profile?

shmget and shmdt are in libnspr4.so in /usr/local/mozilla (on my system, Mozilla
is installed in /usr/local). They are both in /usr/local/firefox/libnspr4.so.
ccing wan-teh, in case this is an NSPR issue...
Sure, NSPR wraps those functions and other equivalents on other platforms. 
Where do you see Mozilla calling into those wrappers?  My LXRing has not turned
it up, though I freely admit that I could be missing something.

Having the symbol referenced from nspr.so doesn't tell us anything; there are
lots of pieces of NSPR (such as the whole soft-threads infrastructure) that we
don't use in the client.

Have you been able to catch Mozilla "in the act" of creating one of these
segments or semaphores?  That stack would tell us a lot, and we haven't found a
developer so far who can reproduce it on their system.
(In reply to comment #9)
> Sure, NSPR wraps those functions and other equivalents on other platforms. 
> Where do you see Mozilla calling into those wrappers?  My LXRing has not turned
> it up, though I freely admit that I could be missing something.
> 
> Having the symbol referenced from nspr.so doesn't tell us anything; there are
> lots of pieces of NSPR (such as the whole soft-threads infrastructure) that we
> don't use in the client.
> 
> Have you been able to catch Mozilla "in the act" of creating one of these
> segments or semaphores?  That stack would tell us a lot, and we haven't found a
> developer so far who can reproduce it on their system.

Well, I execute ipcs (after using ipcrm to remove segements and semaphores) and
there are none, then I start Mozilla, exit Mozilla, execute ipcs and there are
shared memory segments and semaphores sitting there. So, I guess that Mozilla
just might be the culprit. Could be wrong, of course, but there you are.

So, my ISP, http://dsl.sbc.yahoo.com, has all this Flash stuff on the default
home page -- maybe that's it. I don't think there's any Java, but who knows with
SBC and Yahoo. Hey, come to think of it, who knows with much of anything nowadays.

Give me a hint, here -- if there is something I can dump and send off, I'll be
happy to. Tell me what to do and I'll do 'er. If this is something peculiar to
SBC Yahoo, I'll set up a temporary account and somebody can see if that's the
problem (you need Flash for that). If I need to build Mozilla and Firefox from
scratch, I'll be happy to do that, too (just send me the "standard
configuration" arguments so I don't have to fool around with configure for two
hours -- tell me what do you build the standard distributions with and I'll do
that on this box (which does not have anything out of the ordinary on it; stock
kernel, all that).

Right now, Mozilla has been stopped once and is (obviously) running now and this
is what ipcs looks like:

fubar-trona-/home/trona: ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 124485633  trona     777        393216     2          dest
0x73657469 124387330  trona     666        131224     0
0x000071b8 123338755  trona     660        64528      0
0x0000727f 124059652  trona     660        64528      0
0x00000000 124616709  trona     666        134976     1          dest
0x000076ea 124649478  trona     660        64528      0

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x000071b8 1867776    trona     660        1
0x0000727f 1900545    trona     660        1
0x73657469 1933314    trona     666        1
0x000076ea 1966083    trona     660        1

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

That's odd, shouldn't be, and whatever I can do to help I'll be happy to -- just
let me know what to do. Start it with debug? Make it do a core dump somehow
(how?)? Whatever it takes.
(In reply to comment #10)
> (In reply to comment #9)
> > Sure, NSPR wraps those functions and other equivalents on other platforms. 
> > Where do you see Mozilla calling into those wrappers?  My LXRing has not turned
> > it up, though I freely admit that I could be missing something.
> > 
> > Having the symbol referenced from nspr.so doesn't tell us anything; there are
> > lots of pieces of NSPR (such as the whole soft-threads infrastructure) that we
> > don't use in the client.
> > 
> > Have you been able to catch Mozilla "in the act" of creating one of these
> > segments or semaphores?  That stack would tell us a lot, and we haven't found a
> > developer so far who can reproduce it on their system.
> 
> Well, I execute ipcs (after using ipcrm to remove segements and semaphores) and
> there are none, then I start Mozilla, exit Mozilla, execute ipcs and there are
> shared memory segments and semaphores sitting there. So, I guess that Mozilla
> just might be the culprit. Could be wrong, of course, but there you are.
> 
> So, my ISP, http://dsl.sbc.yahoo.com, has all this Flash stuff on the default
> home page -- maybe that's it. I don't think there's any Java, but who knows with
> SBC and Yahoo. Hey, come to think of it, who knows with much of anything nowadays.
> 
> Give me a hint, here -- if there is something I can dump and send off, I'll be
> happy to. Tell me what to do and I'll do 'er. If this is something peculiar to
> SBC Yahoo, I'll set up a temporary account and somebody can see if that's the
> problem (you need Flash for that). If I need to build Mozilla and Firefox from
> scratch, I'll be happy to do that, too (just send me the "standard
> configuration" arguments so I don't have to fool around with configure for two
> hours -- tell me what do you build the standard distributions with and I'll do
> that on this box (which does not have anything out of the ordinary on it; stock
> kernel, all that).
> 
> Right now, Mozilla has been stopped once and is (obviously) running now and this
> is what ipcs looks like:
> 
> fubar-trona-/home/trona: ipcs
> 
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 0x00000000 124485633  trona     777        393216     2          dest
> 0x73657469 124387330  trona     666        131224     0
> 0x000071b8 123338755  trona     660        64528      0
> 0x0000727f 124059652  trona     660        64528      0
> 0x00000000 124616709  trona     666        134976     1          dest
> 0x000076ea 124649478  trona     660        64528      0
> 
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 0x000071b8 1867776    trona     660        1
> 0x0000727f 1900545    trona     660        1
> 0x73657469 1933314    trona     666        1
> 0x000076ea 1966083    trona     660        1
> 
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
> 
> That's odd, shouldn't be, and whatever I can do to help I'll be happy to -- just
> let me know what to do. Start it with debug? Make it do a core dump somehow
> (how?)? Whatever it takes.

I tried an experiment -- I changed the home page to
http://www.mozilla.org/start/1.7. Started Mozilla:

fubar-trona-/home/trona: ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000000 125599745  trona     777        393216     2          dest

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

Stoped Mozilla:

fubar-trona-/home/trona: ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

Ah-hah! It looks -- looks -- like http://dsl.sbc.yahoo is causing the problem;
it has Flash stuff on it (for sure), and perhaps a bunch of other nonsense, but
could it be that Flash with Mozilla is leaving corpses behind?

There is a "today" crawl on http://dsl.sbc.yahoo.com, it's a news display. I
have noticed, with Mozilla (which uses GTK-1) that that crawl displays properly
but Firefox (which uses GTK-2) does not (there are two boxes in the display,
with Firefox the right-side rectangle is grayed).

Wonder if there's some weird thing with Flash?

Again, if you can tell me what to do to make Mozilla core dump or otherwise
create a trace, let me know how and I'll be happy to give it a shot. Or if
somebody wants a temporary ID, I'll be happy to set one up (or you can just use
mine, let me know).
Unix shared memory segments and semaphores
behave like files in that they remain in the
system after all open descriptors referencing
them are closed.  You need to delete (or
"unlink") them to remove them from the system.

It's likely that whoever wrote the code that
creates these shared memory segments and
semaphores didn't realize it's necessary to
delete/unlink them after closing their descriptors.
So wait.  Comment 5 said that you tried starting the browser with no plugins
(including no flash) and that this still increased the number of
semaphores/shmem-segments we did not release.  When you did that, did the flash
animation on the SBC homepage render?
(In reply to comment #13)
> So wait.  Comment 5 said that you tried starting the browser with no plugins
> (including no flash) and that this still increased the number of
> semaphores/shmem-segments we did not release.  When you did that, did the flash
> animation on the SBC homepage render?

A message to download and install Flashplayer (that's what it does if it doesn't
see Flash).

Just for grins, I tried the same thing with Konqueror (pointing it to
/usr/local/mozilla/plugins). Guess what? Same thing from
http://dsl.sbc.yahoo.com. Corpses left over after the fact but none prior to
pointing Konqueror to the Flash plugin.

Looks to me like there is some oddball thing with Flashplayer or with the
"Mozilla" Flashplayer 7 plugin (so, who wrote that one?). Or, more likely, some
odball thing with http://dsl.sbc.yahoo.com in combination with the Flashplayer
plugin written for Mozilla (this Yahoo thing is not particularly yahooish when
all is said and done -- busy, annoying, and generally for the Great Unwashed to,
uh, enjoy). They, SBC and Yahoo, of course, never have a problem and there's a
large crew in Bangalore (Sam and Bill and Susan, among others) that will happily
tell you about that.

So, other than never accessing http://dsl.sbc.yahoo.com, that's the way it seems
to be. And where would one go from here? I can't imagine that I'm the only Linux
user of SBC Yahoo, and I'll bet that there are at least one or two others
racking up unattached shared memory segments until the system grinds to a halt
someday. Hmm.
> A message to download and install Flashplayer (that's what it does if it
> doesn't see Flash).

But you said (comment 5) that this still caused leaked semaphores, no?

The Flash plugin is written by Macromedia.
(In reply to comment #15)
> > A message to download and install Flashplayer (that's what it does if it
> > doesn't see Flash).
> 
> But you said (comment 5) that this still caused leaked semaphores, no?
> 
> The Flash plugin is written by Macromedia.

Well, yeah -- just harder to type semaphores all the time and I forgot to
include semaphores in the text. Yes, both shared memory segments and semaphores
left over from Mozilla, Firefox and Konqueror using the Flashplayer 7 plugin at
http://dsl.sbc.yahoo.com. No problem with any of those browsers using
http://www.mozilla.org/start/1.7 as the default home page. Think I'll drop
Macromedia a note and let them know? Or would it be better if you guys did that.
ccing some macromedia folks, in hopes they'll know what's up here.
Version: unspecified → 1.7 Branch
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.