Closed Bug 34834 Opened 25 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: 25 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: 25 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: