When I do 'about:config' on linux with 2001090608 build, it does not display the list of prefs. Instead an uncaught exception is thrown, which terminates the Error: uncaught exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]" nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" location: "JS frame :: chrome://global/content/config.js :: onConfigLoad :: line 95" data: no] It's trying to fetch the pref for 'plugin.soname.list' at this point in chrome://global/content/config.js: 93 case 32: 94 prefTypeName = "string"; 95 prefValue = prefBranch.getCharPref(prefArray[i]); //<-- barf! 96 prefValue = htmlEscape(prefValue); 97 break; Putting a try/catch, and setting prefValue = "" if it fails, allows the script to finish doing its work (but probably better to figure out why that call to getCharPref is failing. [I note that that pref is only ever referenced in C++ code and has no backstop value in all.js, etc.]

John - I'm unable to duplicate this so if I can get some information from you. is the pref plugin.soname.list listed in your prefs.js file? if so, what is the value? Do you have any other "plugin." prefs in your prefs.js file? (what are they?) Thanks

The patch adds a check for the existance of a default pref value (which doesn't have to exist) before attempting to use the default pref value. There is still a failure condition - if no default value and no user value - however, if there is neither of these we ought still fail. Brian - can you please review

I'm going to have to disagree with this one. First, your patch will cause Pref_CopyCharPref() to return a user value if default value was specifically requested but doesn't exist. This should cause an error condition. Second, the code in config.js is already requesting a user value. Unless there is no user value, it shouldn't be pulling the default value in the first place. If there was neither a user or a default value, it's still going to fail... as you've already noted the patch still won't handle this case. jrgm, is this "plugin.soname.list" preference defined in your preferences files (i.e. prefs.js, user.js) somewhere? If so, could you please post the file or the line referencing the preference.

Sorry, for not getting to this earlier. I don't have a build on that machine right now, so it would take a while before I could test that patch (and even then, I don't know if I would see this in a mozilla build, or if this is something specific to the commercial build in which I can reproduce this error (the build I see this error in is the commercial build for 2001-09-06-08-trunk, done with the 'Full Install' option)). As for where this pref is coming from, grepping through all the files in that installation the only reference to the string 'plugin.soname.list' is in the file "./components/libgkplugin.so". This string is not in my profile either. Hope that helps.

And, by the way, the only reference to that string in the mozilla tree is http://lxr.mozilla.org/seamonkey/search?string=plugin.soname.list /modules/plugin/base/src/nsPluginsDirUnix.cpp, line 187 -- #define PREF_PLUGINS_SONAME "plugin.soname.list" /modules/plugin/base/src/nsPluginsDirUnix.cpp, line 191 -- user_pref("plugin.soname.list", "/usr/X11R6/lib/libXt.so.6:libXiext.so"); There is no match for that string in the commercial lxr.mcom.com

Yes, the #define PREF_PLUGINS_SONAME is used at line 202 to check for the existance of the preference. Down at the bottom (around line 275) if there wasn't a valid list, it creates the preference. This should cause it to get written out to the prefs.js file in your profile. Commercial doesn't appear to reference this at all, so it should be reproducible in Mozilla. av, do you have any idea what this preference does?

That's what serge recently added. Cc'ing. Serge, did you file a bug on adding your new prefs to the docs?

Chip, maybe you can reproduce this on Serge's Linux build...

I was unable to reproduce this with 2001-09-07-09-trunk, John , could you try it again?

Okay, I installed (doing a 'Full Install' with Java and Shockwave) the commercial linux build 2001-09-07-12-trunk on my system (redhat 6.1) and started up with a new profile. I did 'about:config' and the same exception was thrown. Now, on startup, I get these errors messages in the console: LoadPlugin: failed to initialize shared library /home/mozilla-local/2001-09-07-12-trunk/plugins/java2 [/home/mozilla-local/2001-09-07-12-trunk/plugins/java2: cannot read file data: Is a directory] LoadPlugin: failed to initialize shared library /home/mozilla-local/2001-09-07-12-trunk/plugins/ShockwaveFlash.class [/home/mozilla-local/2001-09-07-12-trunk/plugins/ShockwaveFlash.class: invalid ELF header] which is a different bug (i.e., :-] no kidding that PR_LoadLibraryWithFlags fails when asked to load a directory, or a java classfile; we probably shouldn't bother passing those on for loading since it's just a waste of time). However, the fact that I get those messages tells me that I must have passed through one of these code paths (because these are the only places where DisplayPR_LoadLibraryErrorMessage() is called. in LoadExtraSharedLib(): 172 handle = PR_LoadLibraryWithFlags(tempSpec, PR_LD_NOW|PR_LD_GLOBAL); 173 if (!handle) { 174 ret = PR_FALSE; 175 DisplayPR_LoadLibraryErrorMessage(name); in nsPluginFile::LoadPlugin(): 374 if (!pLibrary) { 375 LoadExtraSharedLibs(); 376 // try reload plugin ones more 377 pLibrary = outLibrary = PR_LoadLibraryWithFlags(libSpec, 0); 378 if (!pLibrary) 379 DisplayPR_LoadLibraryErrorMessage(libSpec.value.pathname); 380 } And that means I must have called LoadExtraSharedLibs() at some point, where this pref is of interest to the program. However, when I look in my prefs.js, there is no "plugin.soname.list" pref that has been set by the call to LoadExtraSharedLibs(), so that is failing somehow. (And when I turn to do about:config, then it barfs). When you say you can't reproduce this, are you doing it with a prefs.js where this pref has not been set. You should try removing that pref if it's set, and then seeing if it is getting set by LoadExtraSharedLibs() in a current build. ---------- One nit, while we're discussing this. Maybe someone should fix the typo in the comment to say "libXext.so" without the additional "i". 191 user_pref("plugin.soname.list", "/usr/X11R6/lib/libXt.so.6:libXiext.so");

i think i encountered this on winnt, when i viewed about:config a second time in the same session [2001.09.04.00-comm build, tho']...

erm, i realize i my build is a bit old wrt this bug. i'll dblcheck on all platforms once the fix is checked in.

I'm running on build 2001091008 - FULL install - and get no such errors. I have the preference listed on the about:config page... but have no such pref in my prefs.js file. So I'm at a loss at how to reproduce this. John - if you get it to fail again - please drop me an email and we'll setup some time where I can see it on your machine.

I can not get this to fail on Mozilla, Netscape - recent trunk builds or the branch build. Unless there is some other information that I can get to reproduce this one.... I'm marking "works for me"

Oops, sorry for not getting back to this. I'm gonna reopen and take this bug, and when I've sorted out how to reproduce, I'll give it back to you Chip. I don't know why "only" my machine, but it's a fairly stock Redhat 6.1 system; probably some library version issue, or some such.

-> jrgm (although, I'm away for the next week, so I won't have anything soon, but this is not a pressing issue).

I suck -> 0.9.6

.

.

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

I can still reproduce this bug on a recent trunk build. See the duplicate bug for info. If you need help reproducing, contact me.

Shouldn't the Target Milestone being changed?

Some further info: It seems to fail on user created profiles. As I mentioned in bug 173595, about:config works on the default profile. This is because in my default profile, prefs.js contains a "plugin.soname.list" preference. Neither my working profile, nor a freshly created test profile contain the "plugin.soname.list" preference. Neither of these show the about:config page. Note: the default profile was created with SuSE 8.0's version of Mozilla. (A 0.9.X milestone release, possibly customised by SuSE)

Just tested this on Mozilla 1.2.1. It now works.

Update on my last comment: I forgot to copy my plugins from my old mozilla to my new mozilla. Now with the plugins back in place, about:config fails again. Sorry for the false alarm.

Seems to be fixed in the 2003012422 build: My working profile still attaches to the default for "plugin.soname.list". All the plugins I use are present. The value for the default "plugin.soname.list" is empty. If this is still failing for others, then could it be due to a particular permuation of plugins?

ok this code has changed _a lot_ since this bug was filed. relevant part seems to be here: http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/config.js#231 and it has a try..catch block, so an exception wouldn't stop about:config from working. Per that and comment 27, marking WORKSFORME, but please reopen if you are still seeing this.