Closed Bug 34834 Opened 24 years ago Closed 24 years ago

runaway psm

Categories

(Core :: Security: PSM, defect, P3)

Product:
Core
Component:
Security: PSM
Version:
1.0 Branch
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ben, Assigned: leaf)

References

Details

(Whiteboard: DO NOT REOPEN)

Attachments

(3 files)

Patch which fixes this bug.
17.03 KB, patch
Details | Diff | Splinter Review
Updated patch
18.26 KB, patch
Details | Diff | Splinter Review
Attaching the entire patched file per brendan's request
76.80 KB, text/plain
Details 
After browsing https documents for a while. PSM runs away and begins eating all
the CPU. The only way to fix it is to close the browser.
ben@valinux.com, when posting a bug please include build number and other 
details to help develpers.

I have seen a few checkin's to improve Mozilla with PSM.  Could be related.
Please follow up so we can direct approperly.  

reporter - are you stills seeing this?

yes

Here is something that I just discovered. This problem doesn't occur when I am

connected to a fast network. Normally, I am connected with a ricochet which is

26Kbs and it happens all the time. However, when I am in the office and

connected via ethernet it never occurs.


->Security
Assignee: asadotzler → norris
Component: Browser-General → Security: General
QA Contact: jelwell → junruh
psm
Assignee: norris → dougt
Component: Security: General → Security: Crypto
Change product to PSM
Component: Security: Crypto → Daemon
Product: Browser → PSM
Version: other → 1.01
ben@valinux.com - are you still seeing this problem with recent builds of 
Mozilla? If so, could you add a comment giving the Build ID of the version you 
tested with, and the version of the PSM, and we'll get this bug confirmed.

Gerv
tested on M16 2000-052408 Linux:
After having visited a site using SSL triggering the PSM module, and then having
left it, i realized things was going slower and slower and Moz barely reacting
anymore. Checked a ps -ef: There were 15 instances of ./psm running.
A quick "top" revealed this (excerpt):

1039 dark      17   0 34084  33M 12388 R       0 15.6 35.6   4:11 mozilla-bin
1064 dark      20   0  3204 3204  1540 R       0 14.3  3.3   1:00 psm
1115 dark      19   0  1044 1044   844 R       0 11.5  1.0   0:00 top
1061 dark      18   0  3204 3204  1540 R       0 10.9  3.3   1:17 psm
1062 dark      18   0  3204 3204  1540 R       0 10.9  3.3   1:00 psm
1063 dark      18   0  3204 3204  1540 R       0 10.9  3.3   1:00 psm
1066 dark      18   0  3204 3204  1540 R       0 10.9  3.3   1:00 psm
1069 dark      18   0  3204 3204  1540 R       0 10.2  3.3   1:00 psm
1067 dark      18   0  3204 3204  1540 R       0  8.8  3.3   1:00 psm
1068 dark      19   0  3204 3204  1540 R       0  5.4  3.3   0:45 psm

I am pretty sure that these are just threads in the PSM process.  
loaded the page again and left it - you're right.. it spawn 15 threads right
away. But it never terminates them. They keep hanging in using heaps of CPU.

The problem isn't with the fact that there are lots of threads. The problem is

that combined the 15 or so threads bring your machine to a crawl.


setting to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 32605 has been marked as a duplicate of this bug. ***
Reassigning all https/cartman/security bugs to valeski.  He will be finding new 
owner(s).  This shift is so that I can focus on embedding issues.  If the new 
owner has questions that can not be resovled, I may be able to lend a (quick) 
hand.

over to valeski....
Assignee: dougt → valeski
Target Milestone: --- → M17
Version: 1.01 → 1.2
*** Bug 35699 has been marked as a duplicate of this bug. ***
*** Bug 41205 has been marked as a duplicate of this bug. ***
be sure that you have the correct version of PSM.  search your disk for any 
other version of psm and delete them.

reassign this one to lord
Assignee: valeski → lord
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Worksforme. I've never seen this happen, or had a problem with the machine 
slowing down when psm is a process.
The last time I saw this was last week.  I should point out that this does not
happen all the time (even on the same site), so perhaps it is still present. 
Comments from anyone?
I remember seeing this happen before and I believe it was caused by psm leaving 
phantom processing when psm disappeared unexpectedly.  (That's a nice way of 
saying "psm crashed")
I am still seeing this on 2000072905 on Linux.  Whenever I go to
https://webbanking.tdaccess.com/, login, and then logout, I get PSM
threads/processes that takes up all my CPU time.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This definitely occurs in M17.
debian woody
kernel 2.2.17p15
It's so bad that I'll end up with 70+ psm processes and I can't do much
debugging as I can fork any more processes.
Changing milestone to future.
Assignee: lord → ddrinan
Severity: normal → enhancement
Status: REOPENED → NEW
Target Milestone: M17 → M20
I can reproduce this quite well now, and I have some additional info that may be
of some use.  I am definitely changing the severity of this bug from "enhancement".

1. Go to https://tdaccess.tdbank.ca/  Notice that there is a Javascript "bug"
(see bug 45099).
2. Now browse other non-secure sites.  Eventually, you will see a bunch of psm
threads taking up all the CPUs.  You may have to do quite a bit of surfing, but
it has always shown up eventually.

When I did "top", I see the following:

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND

14963 howard    15   0  4508 4508  2252 R       0 15.1  3.5   0:06 psm
14959 howard    15   0  4508 4508  2252 R       0 14.9  3.5   0:01 psm
14965 howard    15   0  4508 4508  2252 R       0 14.9  3.5   0:06 psm
14960 howard    15   0  4508 4508  2252 R       0 14.5  3.5   0:06 psm
14962 howard    15   0  4508 4508  2252 R       0 14.5  3.5   0:06 psm
14961 howard    15   0  4508 4508  2252 R       0 14.3  3.5   0:06 psm

I then attached gdb to some of these processes.  They all look like the following:

(gdb) where
#0  0x401535bb in __pthread_mutex_trylock (mutex=0x82d348c) at spinlock.h:24
#1  0x40037567 in PR_EnterMonitor ()
   from /home/howard/mozilla/nightly/package/psm/./libnspr4.so
#2  0x8083149 in SSL_DataPending ()
#3  0x8084f43 in ssl_Poll ()
#4  0x4003a3f5 in PR_Poll ()
   from /home/howard/mozilla/nightly/package/psm/./libnspr4.so
#5  0x805b163 in SSM_SSLDataServiceThread ()
#6  0x4003b66e in _pt_root ()
   from /home/howard/mozilla/nightly/package/psm/./libnspr4.so
#7  0x40152b85 in pthread_start_thread (arg=0xbe1ffe40) at manager.c:241
Severity: enhancement → major
This still happens (PSM 1.2, Linux nightly 2000090621). To me it happens
everytime when I go to a SSL site using proxy. When I go to SSL site on our
Intranet, it doesn't happen.

still happens; linux, build 2000090821, psm 1.2.  not using proxy, just internet
dial-up.  access my.sun.com and login to email.  18 psm threads running, the
last one ran (highest pid) is sucking all the cpu.
*** Bug 47130 has been marked as a duplicate of this bug. ***
*** Bug 55038 has been marked as a duplicate of this bug. ***
Changing QA contact to nitinp
QA Contact: junruh → nitinp
I think I'm seeing exactly this with BuildID 2000100621.

After getting cablemodem I've been able to get nightlies. Those of 30th Sept
2000 and 3rd October wouldn't install PSM at all. I was about to file this
when the 6th Oct nightly appeared to install it successfully. Except that as
soon as I tested it, I found www.fortify.net was adamant that I had no
encryption, and PSM started showing up in top just as it did in the top excerpt
from RK AA. Lots of psm processes (threads, whatever), each using about 10% of
CPU time. The only way to stop this is to kill off Mozilla. Waah.

What more information do you need? I wasn't sure. This is a K6 with 64Mb of RAM
running Linux.

Many people have mentioned this to me when using debian's M17 then installing
the official PSM. I still see this on recent builds on linux (both "official"
nightlyies and custom builds)

Well, here my tale of woe with PSM.  I have seen the problem with PSM taking up
100% of the CPU quite a few times now, but what I see even more is PSM creating
hundreds of threads none of which ever terminate.  On secure site I use is Green
Mountain Energy, http://www.greenmountain.com .  Their secure pages have
menu-like constructs which are image links with onMouseOver and onMouseOut
handlers to display a highlighted image and then replace with the standard image
again. Every time I move the mouse over one of these links and trigger the
handlers, PSM creates another one or two threads.  If I reload the page, PSM
creates another 52 (52!) threads.  I can get hundreds of PSM threads with only
loading a few of the secure pages and moving the mouse over links.  As I
continue causing PSM to create new threads, it will eventually start taking 100%
of the CPU though it seems that only 2 out of the hundreds of threads are
actually taking up the time.  Also, PSM seems to be spending most of its time in
system calls rather than in user code.  I get similar results viewing secure
pages on other sites.  It used to work ok but seems to have busted about the
time PSM 1.3 came out.

I hope this is fixed before rtm, otherwise it will not be possible to say that
NS6 supports SSL on Linux.

Tested with Mozilla 101008, trunk build, with PSM 1.3 on Linux.
I'm currently investigating this problem. Apart from the sites mentioned in the 
bug report already (https://webbanking.tdaccess.com/ and 
http://www.greenmountain.com) are there other SSL sites where this is a problem. 
I'm trying to see if there is some common link between these sites.
I have similar problems with http://www.netflix.com
I have psm 1.3 installed after compiling M18's source. 
If psm is launched from command line, without running Mozilla, it consumes >90% 
CPU immediately.

I've also seen this before. I don't log onto SSL sites often, however, so it's
been a while since I've seen it.
I think I've seen it mostly at http://www.amazon.com and at some internal
company sites where I work (inaccessible from offsite).
When it happens, switching virtual desktops under E will suddenly slow down
noticeably and looking at top will show psm taking up a lot of cpu resources
(usually between 60-90% on my PIII 500). Running `killall psm` usually fixes the
problem.

It's really bad bug. I think its source of my problem, that PSM 1.3 doesn't work
for me at all. When I open a site where the certificate is not signed by some
stored root certificate (for example: https://ca.ica.cz/) The PSM's window with
a message about it appears, but when I click to Next button, the buttons
disappear and nothing else happens (Linux 2000101521). There are at least 7 psm
threads/processes in background one of them consuming about 2% CPU. When I close
the window using close from windowmanager there appears a new window about
accepting the certificate, but again nothing happens when I click to Finish button.

So the PSM seems to be completely unusable to me.

*** Bug 56904 has been marked as a duplicate of this bug. ***
rtm. This happened to me, and I had to reboot the Linux server to get rid of 
dozens of psm processes.
Keywords: rtm
Re-assigning this bug to Javier. He is going to run psm in a debugger and see 
why these threads are not be cleaned up.
Assignee: ddrinan → javi
In order to make debugging this easier,I took a really long function and with 
the magic of cut and paste, made it into many smaller functions.  Should make 
debugging this much easier.
The thread that polls socket for data had a block that checked the number of 
sockets waiting for data only exited the thread when number of sockets ready was 
less than zero.

By modifying the following line:
http://lxr.mozilla.org/mozilla/source/security/psm/server/sslconn.c#1107

to read 

if (nReady <= 0) {

then the threads appear to properly clean up after themselves.  This may be the 
fix, but it needs some more testing before I can officially declare it the fix.
Checked in a fix to the tip of the PSM tree that appears to fix the problem.
For an RTM eval for Netscape 6, we need to understand what tag we're pulling for
PSM, and what set of tests have been run.

Can you comment on the pros and cons of advancing a tag to get this checkin (or
am I confused about how Netscape 6 is pulling PSM?).

Thanks,
Jim
Netscape6 bundles an xpi file that was generated off a tag.

This check-in is to help with embedding projects that see their systems slow to 
a crawl after extended use of psm.

For Netscape6 to pick this up, we'd have to re-spin the xpi and then have leaf 
incorporate that xpi into the daily builds.
status: [rtm need info]
Whiteboard: [rtm need info]
We made some more changes for this, and we now appear to have fixed the problem.  
The code is checked into PSM's tree.  If Netscape6 wants to pick this up, we'll 
need to do a new drop of PSM.
The following patch, when applied to the psm daemon, fixes this problem.  We 
have tested this patch with a 3rd party vendor implementing a set top box and 
they confirmed PSM no longer eats up system resources.

(The reason the diff is so big is because I took a very long function and create 
several smaller functions by cutting old sections and making them new functions.  
Makes the function much easier to read and debug in the future.)

PSM team believes this is a re-spin bug.
Fix is good. r=ddrinan.
Adding more description about the diff for super reviewer's sake:

There are 4 changes that went into the diff to fix this bug:

1) When polling the sockets from the client (mozilla) and the SSL server, we 
break out of the poll loop if the number of sockets waiting for data is equal to 
0.  That's the PR_Poll you see around the "@@ -1084,27 +1259,12 @@" block.

2)Break the function SSM_SSLDataServiceThread into smaller functions to improve 
readability and make debugging much easier.  This created the functions 
SSM_SSLThreadMakeConnectionSSL, SSM_SSLThreadReadFromServer, and 
SSM_SSLThreadReadFromClient.  These functions were created by cutting a piece of 
code out of SSM_SSLDataServiceThread and pasting it in.  There were minor 
modifications for adding '->' notation instead of array notation.

3) Instead of NULL'ing out the file descriptor in the PRPollDesc and 
decrementing the counter, I zero out the in_flags so that PR_Poll will ignore 
that file descriptor when polling. (This was recommended by larryh of the NSPR 
team.)  The old code would have something like this:

Array of Poll Descriptors
 [Client socket,ie socket talking to Mozilla][Socket talking to SSL server]
nSockets = 2

If the client socket was shutdown first, then the old code would NULL out the 
first index and decrement the counter.  Leaving you with this scenario:

Array of Poll Descriptors:
[NULL socket][Socket talking to SSL server]
nSockets = 1

In this case, when we went to Poll, PR_Poll would only look at the first index, 
see a NULL and exit right away.  This would also cause the thread to loop one 
more time and get stuck at a PR_Poll above which was testing for some condition 
in regards to Keep Alive to properly close down the connection.

Now the code keeps the File descriptors around and zero's out the in_flags when 
passing in the array to PR_Poll so that when PR_Poll returns, the socket we no 
longer care about won't get a bit set for reading or sending.

4)When we get an error from a socket, we close out the socket on the other end 
as well.  If we get an EOF from the SSL server, we send all the data to the 
client and then shut the socket down as well.  We do the same thing the other 
way around.  Before, the code let the other socket stick around until Mozilla or 
the SSL server closed the socket.  This also caused threads to stick around 
longer than needed.

Hope this helps when reading the diff.
Oh yeah, the reason the diff is between -r 1.5 and -r 1.8, is because 1.5 is the 
version we've put up on the iPlanet web site and included with N6 PR3 and 1.8 is 
what's on the tip which we got to work like we wanted to.
I asked for a blow-by-blow more for the PDT's sake than for mine.  If you guys 
had made a minimal change just for the Netscape 6 branch, we wouldn't be here 
typing into a tiny textarea.  I'll review the patch, but if you could come up 
with a minimal-change patch to the Netscape 6 branch, you'd grease the skids for 
sure.

/be
PR_SUCCESS should be SSM_SUCCESS (same value, but not same type):

@@ -107,7 +107,7 @@
                                      SSMResource** res)
 {
     SSMStatus rv = PR_SUCCESS;
-    SSMSSLDataConnection* conn;
+    SSMSSLDataConnection* conn=NULL;

Uh oh, the rest of that function (SSMSSLDataConnection_Create) seems to use rv 
to hold a PRStatus.  Consider changing the type of this variable, translating to 
SSMStatus only on return?

Both read (hmm, famous Unix syscall name) and sent are uselessly initialized:

+SSM_SSLThreadReadFromClient(SSMSSLDataConnection* conn, 
+                           PRIntn oBufSize, char *outbound, PRPollDesc *pds)
+{
+  PRIntn read = 0;
+  PRIntn sent = 0;

Same goes for the same-named variables in SSM_SSLThreadReadFromServer.  Also, 
this line from SSM_SSLThreadReadFromServer must be wrong:

+      /* remove the socket from the array */
+      pds->in_flags = NULL;

NULL should be 0.

How about consistently indenting (by four-space increments) the code here:

+SSM_WaitingOnData(PRPollDesc *pds, PRIntn numPDs)
+{
+    PRBool retVal = PR_FALSE;
+    int i;
+
+    for (i=0; i<numPDs;i++) {
+      if (pds[i].in_flags & PR_POLL_READ) {
+       retVal = PR_TRUE;
+       break;
+      }
+    }
+
+    return retVal;
+}

So long as in_flags can't be 0 until you're done with the polldesc (done 
including out_flags != 0 and there's something to do based on that condition), 
then I think the patch is good.  Set my mind at ease here, ok?

If you can fix the above nits, redo a diff, and also attach the entire new 
(patched) file, I'll give a quick sr=.

/be
Attached patch Updated patch — — Splinter Review 

    
    

    
  
I've updated the patch with the additions Brendan asked for.

I added one more bit of code to zero out the pds.out_flags parameter every time
after processing the poll descriptors.  PR_Poll doesn't modify the in_flags.  In
talking to Larry Hardiman of the NSPR team, he didn't think re-setting out_flag
to zero was necessary but said it wouldn't hurt.  (In testing, everything still
works.)

    
    

    
  
-> [rtm-]

Whiteboard: [rtm need info] → [rtm-]

    
    

    
  
doh!  This one is [rtm need info]

Whiteboard: [rtm-] → [rtm need info]

    
    

    
  
This has a r=, and a sr=, and should go to rtm+.

Whiteboard: [rtm need info] → [rtm need info] sr=brendan, r=ddrinan

    
    

    
  
Nominating for approval.  This only requires a new xpi drop to be sent to leaf.

The fix has been tested by a third party on an embedded system and the bug has
disappeared.
Whiteboard: [rtm need info] sr=brendan, r=ddrinan → [rtm+] sr=brendan, r=ddrinan

    
    

    
  
rtm++
Whiteboard: [rtm+] sr=brendan, r=ddrinan → [rtm++] sr=brendan, r=ddrinan

    
    

    
  
ok, I've received the drop for win32 and linux and am putting them in place.

    
    

    
  
The new linux PSM drop has been placed on lithium.  The new win32 PSM drop has
been checked into the shelf for both branch and trunk.  These should show up in
10/26 morning builds.

    
    

    
  
PDT marking this bug resolved fixed since the 26th build has come and gone. QA,
please verify.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
I sat down with QA and Netscape6 builds have not picked up the correct PSM.

We're still seeing this problem with the daily buids.  Did the xpi files get
bundled with both branch and trunk builds?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
yes, the new files I was given were put in place for win32 and linux for both
branch and trunk.

    
    

    
  
Then we need to sit down and figure out what happened.  When I sit down and run
N6 with my build, the threads go away.  When I sat down and ran N6 that nitinp
downloaded on Friday, the threads did not go away.

    
    

    
  
re-assigning to leaf since what's left to do is bundle the PSM xpi's.

According to ddrinan, he's doing that today.

    
    

    
  
re-assigning for real....
Assignee: javi → leaf
Status: REOPENED → NEW

    
    

    
  
new drop is imported to shelf, will get into the branch presently.
Status: NEW → ASSIGNED

    
  
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED

    
    

    
  
ok, branch for shelf is updated, candidates away. Should be able to verify tomorrow.

    
    

    
  
*** Bug 57970 has been marked as a duplicate of this bug. ***

    
    

    
  
I just tried testing this with linux trunk build 2000110108 using the psm that
came in the build.  I still see psm creating more and more threads with every
secure page I visit (81 threads at the moment after about ten minutes browsing).

This fix should appear in the 11/01 daily build, right?

    
    

    
  
It seems that we passed the wrong bits over the wall.  ddrinan has contacted
leaf and asked him to bundle the correct bits.  (Our QA guy tested the bits
we've asked leaf to bundle to make sure this goes away for real.)

    
    

    
  
verified fixed in the 2000-11-02-09-MN6 build.
Status: RESOLVED → VERIFIED

    
    

    
  
Where is the new psm.xpi for linux? Is it available to all mozilla users or it's
only for Netscape's internal engineers?


    
    

    
  
debug>install psm

    
    

    
  
the new psm.xpi is not public yet , so I don't think mozilla people can get it.
The new psm is in the daily builds of internal commercial netscape6 builds.


    
    

    
  
testing with todays linux build (installed) and psm 1.4, i have 39 psm threads
hanging forever after one login in my bank.
In addition, the lock-icon never triggered, and the processes did not go away
after i had logged out and left the site.
They don't suck CPU a lot, but are way too many.
Still problems, in other words. (I was directed to PSM 1.4 by a developer, to
test a PSM hang. Not sure whether that is the latest however.)

Tested this first as an ordinary user. Then quit mozilla and tested it again as
root. Same result.


    
    

    
  
RKA: please file a new bug on that, thanks.

    
    

    
  
*** Bug 59806 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 60617 has been marked as a duplicate of this bug. ***

    
    

    
  
I submitted the bug 60617, which was just marked as a duplicate of this one.
Here's some more info that might help?

I just went to a secure page (which unfortunately I can't give you the URL of;
it's a billing statement...).  As I started, I had this "ps" list:


  PID TTY      STAT   TIME COMMAND
 3058 pts/2    S      0:00 sh /usr/local/src/mozilla/nightly-builds/001116/packa
 3070 pts/2    S     14:55 /usr/local/src/mozilla/nightly-builds/001116/package/
 3072 pts/2    S      0:00 /usr/local/src/mozilla/nightly-builds/001116/package/
 3073 pts/2    S      0:01 /usr/local/src/mozilla/nightly-builds/001116/package/
    ...
26828 pts/2    Z      0:00 [mozilla-bin <defunct>]
26996 pts/2    S      0:00 ./psm
26999 pts/2    S      0:00 ./psm
27000 pts/2    S      0:00 ./psm
27003 pts/2    S      0:00 ./psm

A minute or so later, after opening a *single* secure web page, I had this list
(different "ps" formatting option):

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
jpeek     3058  0.0  0.3  1696  832 pts/2    S    Nov21   0:00 sh /usr/local/src
jpeek     3070  0.9 20.3 59148 52524 pts/2   S    Nov21  14:59 /usr/local/src/mo
jpeek     3072  0.0 20.3 59148 52524 pts/2   S    Nov21   0:00 /usr/local/src/mo
jpeek     3073  0.0 20.3 59148 52524 pts/2   S    Nov21   0:02 /usr/local/src/mo
jpeek    26996  0.8  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    26999  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27000  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27003  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27004  0.0 20.3 59148 52524 pts/2   S    21:28   0:00 /usr/local/src/mo
jpeek    27008  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27009  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27010  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27011  0.0 20.3 59148 52524 pts/2   S    21:28   0:00 /usr/local/src/mo
jpeek    27012  0.1  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27013  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27014  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27015  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27016  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27017  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27018  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27019  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27020  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27021  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27022  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27023  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27024  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27025  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm
jpeek    27026  0.0  1.8  7268 4896 pts/2    S    21:28   0:00 ./psm

That's not news, I bet.  What might help is that this line appeared in
/var/log/messages at about the same time:

Nov 22 21:28:01 jpeek modprobe: modprobe: Can't locate module net-pf-10

I see that once in a while.  I'm afraid I don't know much about how the Linux
kernel usees modules, what net-pf-10 is, etc.  But that message is familiar, and
I think it might be related to the psm problem??

If I can do some testing or etc., let me know.  I'm using build 2000111521 now, BTW.

    
    

    
  
When you open Tasks->Privacy And Security->Security Manager, click on About 

Security tab, which version of PSM does that say you're running?



    
    

    
  
I'm using PSM 1.3 and I see this behavior

    
    

    
  
net-pf-10 is irrelevant and was mentioned in another bug.

Leaf, was this fixed for 1.2, 1.3 or 1.4?

    
    

    
  
This was fixed in PSM 1.4

We're working on integrating PSM into mozilla builds.  That's why you haven't
seen an XPI for PSM 1.4

    
    

    
  
*** Bug 62222 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 63450 has been marked as a duplicate of this bug. ***

    
    

    
  
I don't know about other people, but on the 2001010504 Windows build, the
security info page reports PSM to be 1.4 already.  However, I'm still seeing the
problems with PSM hogging CPU time and using up to 300(!) threads at times.
Does this mean the problem isn't fixed, or does it mean the wrong PSM is
actually included with the daily builds?

    
    

    
  
I just saw this problem with 2001011208/Mtrunk/Linux.

Logged into sourceforge (http://sourceforge.net), changed my email address in
prefs and then, not seeing a "log out" link, I closed the browser window (I had
two open). Within a minute or so, my cpu usage epplet shows almost all resources
used and running top shows a psm thread using over 80% cpu.

`killall psm` fixed the problem.

    
    

    
  
It seems to me like this bug should be reopened.

    
    

    
  
please file a new bug. I promise to shoot anyone who resolves your new bug as a 
dupe.  Please comment here w/ the name and number of the new bug.  Be sure to 
include build id, platform, steps to reproduce, and ideally a call stack or 
core or something interesting [ps -aux output or something similar might also 
be a good idea].
Keywords: rtm
Whiteboard: [rtm++] sr=brendan, r=ddrinan → DO NOT REOPEN

    
    

    
  
Timeless, I've entered this bug again as bug 65703.

    
  
Target Milestone: M20 → M18

    
  
Product: PSM → Core

    
  
Version: psm1.2 → 1.0 Branch

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: