Opened 8 years ago
Closed 7 years ago
#152 closed defect (invalid)
Official nspr 4.12.0-3 release breaks FF38.8
| Reported by: | darcio | Owned by: | |
|---|---|---|---|
| Priority: | Feedback pending | Milestone: | |
| Component: | nspr | Version: | |
| Severity: | medium | Keywords: | nspr firefox lockup |
| Cc: |
Description
I have been runing nspr RPM package 4.12.0-1 (oc00) i686 for some time now. Recently the 4.12.0-3 drop became available. I installed it, almost immediately started running into problems with FF.
The application would "freeze"...meaning, it would become non-responsive, the CPU monitor would show a complete drop of processing, almost like nothing was actually running...the ESC-CTRL hit would actually bring up Window List viewer where occasionally I managed to kill Firefox sessions, most often however I could not, nor could I do it in TOP, or CAD-popup. This was rarely an issue with FF in the past.
I went back to the 4.12.0-1 release, things are back to "normal"...so definitely something's off with the 4.12.0-3, at least as applicable to FF 38.8 release.
Change History (9)
comment:1 by , 8 years ago
comment:2 by , 8 years ago
OK, thanks, I will take a look at the clean profile.
In the meantime, each time this happened I had the Exception Handler trp file as well as the standard OS/2 Process Dump created...would it help to see either one???
comment:3 by , 8 years ago
Yes, sure, please provide both files. But please install Firefox debug symbols first (see the download page) and reproduce this problem again to get a new TRP file.
follow-up: 5 comment:4 by , 8 years ago
| Priority: | major → Feedack pending |
|---|
seems like reporter lost interest. We will let the ticket for 1 more week open.
comment:5 by , 8 years ago
Replying to diver:
seems like reporter lost interest. We will let the ticket for 1 more week open.
Sorry...no loss of interest at all...but I ran into a major RPM problem that prevented me from doing any updates. Turned out to be a PYTHON.EXE issue and it took some time to work through the ticket I logged with the RPM folks on this.
Anyways...now that I have that behind me I can actualy go back to re-installing the NSPR update and execute the testing you had requested.
Again, appologies, in hind-sight I should have updated this ticket to let you know what was going on.
comment:7 by , 8 years ago
I've been meaning to get to this...but now with the 45 release out I'm going to give that a try first. That of course will require me to update to the latest module releases...so let's see where that gets us.
It makese no sense to work the 38.x issue if 45 is working fine...so let me that get checked-out first.
comment:8 by , 7 years ago
any feedback on this? If not we might close it as invalid, as we didn't get any other such reports so far.
comment:9 by , 7 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
no more feedback --> closing it
This sounds strange as 4.12.0-3 has been in rotation for 2 months already among our test team and no problems whatsoever, including FF. I'm currently under FF with this version of NSPR and all works great. The only significant change between -1 and -3 is that NSPR will load other DLLs using kLIBC rather than OS/2 directly which fixes crashes in fork() for some applications (see the commit message in http://trac.netlabs.org/ports/changeset/2034 for technical details).
The only thing coming into my mind is that your FF uses some plugin that uses NSPR and this somehow fails now or there is some other NSPR app that you run in parallel that screws things up somehow. Please try to use a clean profile for FF with all plugins/extensions disabled and start only FF after a clean reboot to avoid influence of other programs. Then report back if you still have this problem.