Closed
Bug 41005
Opened 24 years ago
Closed 24 years ago
PSM needs help converting to client's I18N libraries.
Categories
(Core :: Internationalization, defect, P3)
Core
Internationalization
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: javi, Assigned: tao)
Details
From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (WinNT; U) BuildID: 200004278 PSM is going through the process of converting its libraries to that of Mozilla and running into problems with the nsStringBundle class. Reproducible: Always Steps to Reproduce: 1.Download the zip file at http://cindercone/h/iridium/mccrel/nsm/nsm12/server/ships/20000529.1/smithers_So laris2.5.1/security/nsm/server/20000529/domestic/SunOS5.5.1_OPT.OBJ/mdbinary.jar (It says mdbinary.jar, but it's really just a zip file.) 2.Get a version of Solaris Mozilla and try to do any PSM created UI, like clicking on the lock icon in the lower right hand corner. Actual Results: PSM will crash because it can't load any of the strings from the properties files. Expected Results: A dialog for the Personal Security Manager should show up. We have taken absnapshot of M14 to do our initial conversion to avoid the problems associated with trying to sync up with the moving target that is Mozilla.bbI'm encountering the followin problem. When I run the libraries in debug mode, everything works great. But when I use the optimized components of the libraries, I cannot read any of the properties files. After extensive printf debugging, I've narrowed it down to this: When reading in the properties files through the resource:// handler, at some point in time an event gets posted to the nsThreadPoolRunnable event queue which goes off and reads the properties file from disk. (At least this is what happens in the debugged version.) In the optimized version, the event to read from the disk never gets processed. I'm not sure if it's because the message never gets sent or if it's because the event happens way before the event thread happens. Must resolve this soon so that we can deliver a version of PSM for PR2 allowing enough time for stabilization.
Comment 1•24 years ago
|
||
*SPAM* - moving this bug to 'new' status to get it off the unconfirmed status radar. Sorry for the spam
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi, Javier: Would you mind downloading the newest Seamonkey build to see if the problem persists? StrinBundle code had undergone a few changes to make it thread safe. Please also test if the problem exists on other platforms such as Linux, Mac, and Win32. Thanks
Reporter | ||
Comment 3•24 years ago
|
||
We had to choose a version of the libraries to do our work against. Mozilla code base was moving far too much for us to stabilize against specailly since our deadlines were approaching. The engineer who did this work chose to stabilize against the M14 branch. So PSM runs with a binary drop of M14 libraries. It's those libraries that we are shipping against and it's those libraries we are seeing the problems with. Downloading the latest Mozilla will not help us because it is not binary compatible with M14 libraries which PSM is trying to use right now. You didn't see this problem with M14 of Mozilla, so we should be able to use the same code. Is there something we didn't do correclty? View http://lxr.mozilla.org/mozilla/source/security/psm/lib/nlslayer/nlslayer.cpp to see how we've implemented our NLS layer. If you see any glaring wrong-doings let us know.
Hi, Javier: Couple of points: 1. One thing you can try is to grab recent code changes in mozilla/intl/strres and see if the problem exists with new code. You can rip out those added code that is not related to your needs. Note that the threadsafe code is checked into by Alec F. You can also grab his change (through CVS) and apply it to the M14 branch you are working on. 2. When StringBundle is not available, the caller should not just crash. It shall deal with it gracefully, instead. 3. At last, I notice that you marked platform and OS fields of this bug to "ALL". Does this mean you are able to reproduce the problem on ALL OS and platforms, at least for Mac, Linux, and Win32? Reason for asking is that there are some platform parity with threading related implementation which might be what you are seeing now. Thanks
BTW, it's rather an i18n bug than l10ns's.
Component: Localization → Internationalization
Reporter | ||
Comment 6•24 years ago
|
||
In hindisght, I should have marked only Solaris as a platform. I'm trying to build a Win95 version of psm to see if it has the same problem, but I'm running into different problems. Are the relevant changes all in strres?
Yes, all the changes make stringBundle threadsafe is in intl/strres.
Hi, Javier: How are you guys doing? Have you got any progress so far? Are yo still seeing the problem after incorporating the new code change?
Reporter | ||
Comment 9•24 years ago
|
||
We got side-tracked somewhat from this. The current plan is to move our code to the tip/M16 branch and see if that eliminates the problem. Once we do that, I'll update this bug accordingly.
Assignee | ||
Comment 10•24 years ago
|
||
mark it "REMIND " until Javier resume is work on this.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → REMIND
Reporter | ||
Comment 11•24 years ago
|
||
This is actually fixed. We moved to M16 libraries and the problems went away. Sorry for not letting you know.
Assignee | ||
Comment 12•24 years ago
|
||
I will reopen it and mark it WORKFORME
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Assignee | ||
Comment 13•24 years ago
|
||
Per Javier's statement, mark it work for me.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•