57.68 KB, text/plain
48.27 KB, image/png
1.71 KB, patch
Andrew Schultz: review+
Robert Kaiser: approval-seamonkey1.1.6-
Robert Kaiser: approval-seamonkey1.1.8+
|Details | Diff | Splinter Review|
2.14 KB, patch
Robert Kaiser: approval-seamonkey1.1.8+
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:22.214.171.124) Gecko/20070509 SeaMonkey/1.1.2 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:126.96.36.199) Gecko/20070509 SeaMonkey/1.1.3 After upgrading to SeaMonkey 1.1.3 this message is display and SeaMonkey does not prompt for the profile: XML Parsing Error: undefined entity Location: chrome://communicator/content/profile/profileSelection.xul Line Number 53, Column 1: <dialog ^ Reproducible: Always Steps to Reproduce: 1. Upgrade to SeamOnkey 1.1.3 from 1.1.2 2. Use multiple SeaMonkey Profiles 3. Note that SeaMonkey does not prompt for a profile 4. SeaMonkey display the error window and does not start 5. SeaMonkey 1.1.2 still works fine Actual Results: SewMonkey 1.1.3 does not start Expected Results: SeaMonbkey 1.1.3 should prompt for one of the two available profiles
Seamonkey, thus no "-safe-mode"... "seamonkey.exe -p"(-p but does't specify profile name) will kick profile manager even when single profile. Did you try it? What is the result when "-p"? Read following MozillaZine Knowledge Base article, and execute several steps in "step 5" first (deletion of "XUL FastLoad File" and "localstore.rdf"). http://kb.mozillazine.org/Standard_diagnostic_-_Mozilla_Suite
I tried these steps in step 5: a) Looked for "XUL FastLoad File" in both of my profiles, but it does not exist. b) Deleted "localstore.rdf" in each of my two profiles, but that did not fix the problem. c) Deleted the "chrome" folder in each of the profiles, but that did not fix the problem. The "extensions" folder does not exist. d) I cannot try creating a new profile because SeaMonkey 1.1.3 will not start.
In addition to the steps I tried above, I also tried starting SeaMonkey 1.1.3 from a Mac OS X terminal window. I can start SeaMonkey 1.1.3 with either of my profiles using these commands and I can switch between them using Tools->Switch Profile. ./seamonkey-bin -P A_DSL ./seamonkey-bin -P B_VPN But these commands failed with the same error message as originally reported: ./seamonkey-bin -P ./seamonkey-bin -ProfileManager
Location of "XUL FastLoad File" and Cache directory is changed to outside of profile directory. See Bug 216204 Comment #14.
(In reply to comment #0) > XML Parsing Error: undefined entity > Location: chrome://communicator/content/profile/profileSelection.xul > Line Number 53, Column 1: This error of Seamonkey is being processed by Bug 376173, but Bug 376173 has keyword of "fixed-seamonkey1.1.3" (still open though). Setting 376173 in "Depends on:". Please DUP to 376173 and remove dependency if it'll be found to be DUP.
I deleted the XUL.mfasl file from both of the profiles in ~/Library/Caches/Mozilla/Profiles/, but that did not fix the problem.
Dick, this is supposed to be fixed in bug 376173 - can you please give a detailed description of how you installed 1.1.3?
I installed SeaMonkey 1.1.3 by downloading it from the Version Tracker site. The disk image mounts and I copy the SeaMonkey application to a new folder in my system Applications folder. You should note that I have migrated from Netscape to Mozilla and then to SewMonkey allowing each version to copy and upgrade my preferences and profiles. And SeaMonkey 1.1.3 works fine with my other user accounts that have only one profile. Ang going back to 1.1.2 works fine with my two profiles.
Something is wrong with this one installation then... Are you sure you are not launching SeaMonkey from the disk image itself but did drag the SeaMonkey app out of the image before launching it?
(In reply to comment #3) > In addition to the steps I tried above, I also tried starting SeaMonkey 1.1.3 > from a Mac OS X terminal window. I can start SeaMonkey 1.1.3 with either of my > profiles using these commands and I can switch between them using Tools->Switch > Profile. > > ./seamonkey-bin -P A_DSL > ./seamonkey-bin -P B_VPN Hmm, so in this case you can bring up the profile manager from "Tools-->Switch profile..."? This is odd.
Yes, I am launching SeaMonkey from a folder in the system Application folder. The installation disk image is no longer mounted, and as I recall, the installation disk image file has been deleted from my download folder. So yes, it is being launched from the Applications folder. Since this problem is easily reproducible, let me know if you want me to run some debug version of SeaMonkey to further track down the cause of this problem.
I tried to work-around this problem by moving these files out of my ~/Library folder, and SeaMonkey 1.1.3 then starts. But the browser window displays what looks like some kind of XML text along the bottom of its window and the Mac OS menu bar shows only SeaMonkey. So at this point I must have missed something and I cannot even start from scratch. Here is what I moved out: ~/Library/Caches/Mozilla ~/Library/Mozilla ~/Library/Preferences/org.mozilla.seamonkey.plist If this problem cannot be fixed soon, could someone help me start from scratch and then copy back my original two profiles? Thanks.
OK, I think I know what is happening. It looks like SeaMonkey 1.1.3 is updating a global file or resource when it is executed on an administrator account on Mac OS X. When I install a fresh copy of SeaMonkey it works fine on my normal user account with two profiles. But as soon as I execute the same copy of SeaMonkey on my administrator account, the normal user account with two profiles starts getting the error and will not start. By refreshing the SeaMonkey application, the problem goes away until I again run that copy of SeaMonkey on an administrator account. Note that running SeaMonkey on another normal user account does not cause the error, probably because a normal user account does not have permission to update the SeaMonkey application. Let me know if I can help track down exactly what file or resource is involved.
Does the administrator account use the same profiles or different ones? If it's the same, then we have the problem, as SeaMonkey always needs write access to the profiles. If not, I'd suspect that chrome/chrome.rdf in the .app is heavily involved in the problem.
No, the administrator account has its own profiles in ~/Library/Mozilla/Profiles, as do all users on Mac OS X. As a work-around, I changed the administrator account's owner permission on the SeaMonkey application to read-only. This corrected the problem with the normal user account with two profiles without having to refresh the SeaMonkey application. But it does not show which global file is being updated that probably should be read-only.
When Win version of Seamonkey, following files are found in write-permitted program directory only(all other files have same timestamp and same file size.) A. Seamonkey 1.1.4 (ZIP build) chrome\chrome.rdf (also in chrome in profile) components\compreg.dat (not found in profile) components\xpti.dat (not found in profile) B. Seamonkey trunk 2007/9/17 build chrome\app-chrome.manifest (not found in profile) components\compreg.dat (found in profile) components\xpti.dat (found in profile) Trunk still writes compreg.dat & xpti.dat in program directory if write-permitted, and trunk writes them in profile too.
The .dat files are usually not the problem, they only cache data and get even only created in memory if no possibility to write is there. You could try to delete them as an admin and try if it changes anything, but I'd suppose not. chrome.rdf is probably something that plays into this, as I said in comment #14 already. This is a bug about branch, so the statement about trunk is useless, I'd suspect that trunk behaves completely differently due to different chrome and profile management.
Problem is re-produced on Win too. (1) Environment Program library for Seamonkey 1.1.4 : Newly unzip'ed from Seamonkey 1.1.4 ZIP build(no files of comment #16) Admin user=full control, non-Admin user=read-only Profile of Seamonkey : Admin="default" only, non-Admin=two profiles (2) seamonkey.exe at Admin => files in comment #16 are created (3) seamonkey.exe at non-Admin => Following error after Seamonkey Logo > XML Parsing Error: undefined entity > Location: chrome://communicator/content/profile/profileSelection.xul > Line Number 53, Column 1: > <dialog (4) Change permission for non-Admin (4-A) \...\chrome directory : non-Admin is modifiable/writable and readable (don't propagate this change to already existing files) (4-B) \...\chrome\chrome.rdf : non-admin is writable/modifiable/readable (5) seamonkey.exe at non-admin => Profile manager starts up normally (If (4-A) is not executed, problem remains. So I guess access to this ) (chrome.rdf is not read/write only, rename/create/write/delete instead) Looks to be OS independent problem. It seems that "no problem when MS Win" is simply because directory of "Program Files" is usually not read-only when MS Win. To Robert Kaiser: Will trace such as Process Monitor log(file access sequence/status can be tracked) on MS Win be helpful/required for deeper problem analysis?
What if you delete chrome.rdf, does it run then? This is just for double-checking.
Neil: Does comment #18 here help us to solve the issues surrounding writing of RDFs on branch?
(In reply to comment #20) > What if you delete chrome.rdf, does it run then? Yes it runs. Seamonkey starts up normally when the chrome.rdf is deleted from read-only program directory (delete \...\chrome\chrome.rdf after step (3) of comment #18)
Thanks, I think that helps a lot. So, from what I see if we detect a chrome.rdf not being present, we just do everything in-memory and are happy. If chrome.rdf is present though, we try to write a new version of it, apparently by trying to write a new file and deleting the old one or such, that fails and makes chrome registry as a whole fail, resulting in those XML errors.
Sorry, I couldn't reproduce this. I tested using a user with only Read (Deny Write) permissions to dist/bin. I tested without a chrome.rdf, with an out-of-date chrome.rdf and with a current chrome.rdf, and I did get 4 assertions about being unable to write xpti.dat, but I was always able to open the profile manager.
Same problem occuring on Windows XP platform, SeaMonkey 1.1.4, using a restricted account with two profiles. I did notice the same behaviour regarding chrome.rds through Filemon. 1375 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\en-win.jar SUCCESS Attributes: A 1376 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome.rdf SUCCESS Attributes: A 1377 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome.rdf SUCCESS Attributes: A 1378 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome.rdf SUCCESS Attributes: A 1379 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files NAME COLLISION Options: Create Directory Access: 00100001 1380 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey NAME COLLISION Options: Create Directory Access: 00100001 1381 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome NAME COLLISION Options: Create Directory Access: 00100001 1382 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome\chrome.rdf NAME COLLISION Options: Create Access: Read 1383 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome-1.rdf NOT FOUND Attributes: Error 1384 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files NAME COLLISION Options: Create Directory Access: 00100001 1385 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey NAME COLLISION Options: Create Directory Access: 00100001 1386 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome NAME COLLISION Options: Create Directory Access: 00100001 1387 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome\chrome-1.rdf ACCESS DENIED WASHU\EDS-User 1388 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome-2.rdf NOT FOUND Attributes: Error 1389 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files NAME COLLISION Options: Create Directory Access: 00100001 1390 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey NAME COLLISION Options: Create Directory Access: 00100001 1391 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome NAME COLLISION Options: Create Directory Access: 00100001 1392 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome\chrome-2.rdf ACCESS DENIED WASHU\EDS-User 1393 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome-3.rdf NOT FOUND Attributes: Error 1394 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files NAME COLLISION Options: Create Directory Access: 00100001 1395 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey NAME COLLISION Options: Create Directory Access: 00100001 1396 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome NAME COLLISION Options: Create Directory Access: 00100001 1397 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome\chrome-3.rdf ACCESS DENIED WASHU\EDS-User 1398 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome-4.rdf NOT FOUND Attributes: Error 1399 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files NAME COLLISION Options: Create Directory Access: 00100001 1400 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey NAME COLLISION Options: Create Directory Access: 00100001 1401 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome NAME COLLISION Options: Create Directory Access: 00100001 1402 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files\SeaMonkey\chrome\chrome-4.rdf ACCESS DENIED WASHU\EDS-User 1403 10:06:40 seamonkey.exe:2924 QUERY INFORMATION C:\Program Files\SeaMonkey\chrome\chrome-5.rdf NOT FOUND Attributes: Error 1404 10:06:40 seamonkey.exe:2924 CREATE C:\Program Files NAME COLLISION Options: Create Directory Access: 00100001 So as you can see it first tries to create chrome.rds over the existing one, fails since the install dir is read-only for restricted users, then tries to create chrome-1.rds, fails, and so on. It does bail out around chrome-1700.rds. I've got a second restricted account and the local admin account for which SeaMonkey is running fine, but they only use the default profile (and I can't see them trying to overwrite chrome.rds at start up either)
Created attachment 282643 [details] Process Monitor log(CSV), write-permited pgm-dir, chrome.rdf exists, replaced by new one (Case-1) Write-permitted Program Directory, chrome.rdf exists (chrome.rdf was generated by other user with different theme) Attached process monitor log is for next flow. 1. Read chrome\chrome.rdf 2. Create chrome\chrome-1.rdf (try to replace new one, because not-usable or mismatch or error in it) 3. Erase chrome\chrome.rdf, then rename chrome-1.rdf to chrome.rdf 4. Profile manager starts normally (Case-2) Read-only Program Directory, chrome.rdf exists (chrome.rdf was generated by other user with different theme) Same as Comment #25, except chrome-1.rdf to chrome-9999.rdf. 1. Read chrome\chrome.rdf 2. Try to create chrome\chrome-X.rdf => ACCESS DENIED (X=1 to 9999) (try to replace new one, because not-usable or mismatch or error in it) 3. XML Parse error (Case-3) Write-permitted Program Directory, chrome.rdf exists (chrome.rdf was generated by myself, then no need to replace) 1. Read chrome\chrome.rdf only, no trying of chrome.rdf update 2. Profile manager starts normally
Changing summary and several fields so that this can be used correctly as a followup to bug 376173 for addressing the remaining issues.
See: http://forums.mozillazine.org/viewtopic.php?t=588442 I've seem this bug in a different context. On XP the presence of a preexisting profile in the Administrator account causes new normal accounts to be unable to start Seamonkey. Normal users with preexisting profiles were still able to use SeaMonkey. Eliminating the Administrator's profile and then creating a new one, allowed a new regular user to start SeaMonkey. Is this because the protections were changed somehow on the C:\Program files\Mozilla.org\SeaMonekey....\chrome.rdf, or because of changes to the Administrator's profile? Seems like it might be the latter, since simply deleting the problematic Administrator's profile (in C:\Documents and Settings\) let the normal user start Seamonkey. Deleting that profile should in no way affect file protections in C:\Program Files\Mozzilla.org\SeaMonkey. So why should a normal user's SeaMonkey ever look in the Administrator's profile? Default User's maybe, but not Administrator's.
Is this problem fixed in SeaMonkey 1.1.5? If not, any idea when if will be fixed?
Created attachment 285553 [details] Failure starting 1.1.5 from a virgin OS X standard user acct. which did not install SM.
(In reply to comment #29) > Is this problem fixed in SeaMonkey 1.1.5? If not, any idea when if will be > fixed? > Don't think so. I pulled 1.1.5 when KaiRo announced the candidate and it ran fine, simply replacing 1.1.4. But I attempted to test it from a brand new standard account and it fails to launch, displaying <key id="key_savePage" key="&savePageCmd.commandkey;" command="Browser:SavePage" modifiers="[edge of screen] Also, the OS X menu bar was not populated with File, Edit, etc. (See attached image.) If it would help, I'd be willing to run a series of installs to try to detail what combinations of one user installing and another running work and don't work. Check perms and ownership, etc. But is further investigation necessary? Isn't the problem understood - that in a multi-user environment, users can't write to chrome.rdf or any other file in the app directories? I honestly don't know enough about the innards of SM to understand what is trying to happen around chrome.rdf, but is there no way to hack branch to get through to SM2 where the problem is properly fixed? Can the file be "renamed" such that it is located in the user's profile somewhere, hence can always be created? Some other hack? I'll be happy to do more digging on OS X if that's what's needed.
Created attachment 287307 [details] [diff] [review] Proposed patch [(1.8 branch) Checkin: Comment 35] OK, so bug 376173 covers the case where Flush() returns NS_ERROR_ACCESS_DENIED but unfortunately when we try to overwrite an existing but stale chrome.rdf in a read-only directory the error code turns out to be NS_ERROR_FILE_TOO_BIG instead. This is because nsLocalFile::Create sucks, and never returns useful error codes to nsLocalFile::CreateUnique. Note that this patch doesn't affect bug 394713.
Comment on attachment 287307 [details] [diff] [review] Proposed patch [(1.8 branch) Checkin: Comment 35] A bit close for 1.1.6 I guess...
Comment on attachment 287307 [details] [diff] [review] Proposed patch [(1.8 branch) Checkin: Comment 35] 1.1.6 is only missing the announcement, everything else is done, I don't think we really want to go back to the start and respin from here. We very much want this in normal 1.8 branch for 1.1.7, though. Thanks for working on that!
Fix checked in.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:188.8.131.52) Gecko/20071119 SeaMonkey/1.1.7 Mozilla/5.0 (Macintosh; U; Intel Mac OS X Mach-O; en-US; rv:184.108.40.206) Gecko/20071119 SeaMonkey/1.1.7 Same result on both platforms (10.4.11): - I installed the 1.1.7 RC as an administrator user, but did not run it. - Successfully started the new version from a standard (non-administrator) account where 1.1.6 had been used. - Successfully started the new verson in a newly created standard account. These were previously OS X failure cases (see comment #31.) So I think as far as practical usage, this fix is verified, but.... To humor KaiRo, I tried execution out of a dmg from virgin standard user accounts and it FAILED on both platforms, with the XML error noted in comment #31. I am completely baffled by this. It makes me wonder if the above fix is really good, or if there is yet something not understood which can bite under certain circumstances. Read-only should be read-only... KaiRo: I said I'd take a shot at relnote text, but I want to mull this over a little first. (Note BTW that my e-mail is screwed up, haven't seen bugmail this month. I'll try to check back on this bug.)
I did some digging and could be wrong, but it seems that Flush() performed against write protected media will eventually produce an EROFS errno on the open which gets translated to PR_READ_ONLY_FILESYSTEM_ERROR in the pthread io routines and then translated to NS_ERROR_FILE_READ_ONLY for eventual return by Flush(). Perhaps this is why execution from dmgs doesn't work, it is a different error. Suggested relnote text: The problem on [some | Unix-like] systems, which erroneously required users to have write access to the installation directory has been fixed. This caused SeaMonkey to start incorrectly, showing XML errors. The problem with executing from write-protected filesystems, such as Mac .dmg images, remains. (Bug 389136).
VERIFIED with same test scenario as comment #18 (1)/(2)/(3), using Sm 1.8 branch latest nightly on MS Win XP. - seamonkey-1.1.7pre (2007/11/19 build) - seamonkey-1.1.8pre (2007/11/24 build) When chrome.rdf existed(generated by write permitted user), seamonkey.exe on read-only user tried to write chrome-1.rdf only once(ACCESS DENIED was returned for it), and further access to chrome-N.rdf(N>=2) was not observed(checked by Process Monitor).
> The problem on [some | Unix-like] systems, which erroneously required users to Hmm... AFAICT, the bug that got fixed here affected Windows and Mac (not linux). Mac is Unix-like, but Windows isn't (and Linux is :)). So, I'd suggest either "some" or "Mac and Windows".
Created attachment 290090 [details] [diff] [review] Mac patch [(1.8 branch) Checkin: Comment 50 & 51] Can someone with a Mac try this patch out please?
Bug 394713 covers #18, #25 etc.
As the original poster of this bug, I will be happy to test a fix. Can someone provide me with a fully built binary of SeaMonkey? I don't have a SeaMonkey build environment. Thanks.
Reworded the 1.1.7 relnotes to leave the .dmg problem intact, using parts of the proposal in comment #38
(In reply to comment #41) > Created an attachment (id=290090) [details] > Mac patch > > Can someone with a Mac try this patch out please? > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:220.127.116.11pre) Gecko/20071127 SeaMonkey/1.1.8pre Executed straight out of .dmg in account that had previously run an earlier 1.1.x. WFM :) It did seem to take a long time to start, perhaps doing that 1000 tries thing, but subsequent startup was fine.
(In reply to comment #45) > Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:18.104.22.168pre) > Gecko/20071127 SeaMonkey/1.1.8pre To clear up the comment of Rich, I added Neil's patch to the 1.8 branch tinderboxen to get build he can test - those are not nightlies, just tinderbox-builds, so inofficial builds from the official tinderbox or such ;-)
Comment on attachment 290090 [details] [diff] [review] Mac patch [(1.8 branch) Checkin: Comment 50 & 51] Thoroughly tested once...
I can confirm the build with the attachment 290090 [details] [diff] [review] patch working directly from the DMG directly on phlox. This has a-1.1.7 from me is it gets granted approval for the relbranch.
Comment on attachment 290090 [details] [diff] [review] Mac patch [(1.8 branch) Checkin: Comment 50 & 51] a1.1.8=me for normal 1.8 branch
Fix checked in to the branch for SeaMonkey 1.1.8, leaving it up to KaiRo to work out if and how to include the fix in SeaMonkey 1.1.7.
I also checked in attachment 290090 [details] [diff] [review] to the release branch for Gecko 22.214.171.124 and included it in the 1.1.7 release tag, so I got to reword the relnotes again but we should fully have fixed this bug there now. Current 1.1.8pre nightlies should also be fixed already.
Ran a successful smoketest from dmg using the 1.1.7 20071128 RC in an OS X 10.5.1 Leopard guest account. (Handy way to get a virgin test environment.)
I am the original poster of this bug. I just upgraded to SeaMonkey 1.1.7 and it has the exact same problem as I originally reported against SeaMonkey 1.1.3. So this problem has not been fixed for me. The error reported is: XML Parsing Error: undefined entity Location: chrome://communicator/content/profile/profileSelection.xul Line Number 53, Column 1: <dialog ^
I've experienced the failure as in comment 30 a couple times since the 1.1.7 RCs were announced. It seems to involve installation and running by one user and then running by another, but despite several days of trying on and off to nail down an absolutely repeatable case, I can't do so. I also had a case of SM silently hanging on startup this afternoon. Ktrace showed it doing this loop: 623 seamonkey-bin CALL select(0x7,0xf0080840,0xf00808c0,0xf0080940,0) 623 seamonkey-bin CALL write(0x7,0x20031e08,0x1) 623 seamonkey-bin GIO fd 7 wrote 1 byte "8" 623 seamonkey-bin RET write 1 623 seamonkey-bin RET select 1 623 seamonkey-bin CALL read(0x6,0xf00808d0,0x400) 623 seamonkey-bin GIO fd 6 read 1 byte "8" 623 seamonkey-bin RET read 1 back to select... It would sit in the select for about 15 seconds, then blast around the loop and back to the select. I'm beginning to wonder if Dick's case, my #30 case, the DMG case and the loop are all different bad things that can happen to SM at startup. I have only a single profile currently. The loop may be something entirely different.
Just to be clear, this problem is still totally reproducible for me, just as I first reported it. The installed SeaMonkey package is corrupted when SeaMonkey is launched by the administrator account that installed it.
Is this bug still being worked on?
Is this bug, or a duplicate of it, fixed in SeaMonkey 1.1.8?
Parts of this have been fixed for 1.1.6 and 1.1.7, not sure if we had any more work going into 1.1.8 specifically, as we are out of ideas what code is causing any remaining problems or what those remaining problems are specifically.
Robert, Thanks for the update. This problem still exists for me. And the problem did not exist in 1.1.5. I use two profiles on a machine with 5 accounts, so this is a real problem for me. Are you still trying to fix the problem or is SeaMonkey dead wrt multiple profiles and accounts on the same machine?
Dick, if you can give us debug information like we got for the last problems, and give us info about what exactly is the failing scenario on what platform and what permission settings, etc. we might be able to find a fix and get it into a future 1.1.x release. Most important and helpful probably is the debug information. SeaMonkey 2 should work without problem when it's released, for 1.1.x we will only care about finding such fixes if we get very specific and detailed information on what the exact problem is.
Robert, I can provide any debug information you need. I summarized the problem in comment 13, but I don't have any details about which global resource is being corrupted. Let me know how I can help diagnose this problem. Thanks.
(In reply to comment #62) >I can provide any debug information you need. Well, there's debug information, and there's debug information... ideally, you would compile SeaMonkey 1.1.8 yourself with symbolic debugging information, so that you could trace to see which function was failing. Wile you might be able to use FileMon or Process Monitor to trace which files SeaMonkey is trying to create or write when it starts up, that won't necessarily translate into usable internal error codes - for example, bug 394713 was caused by an internal XPCOM function returning the wrong error code.
Short of doing SeaMonkey development, is there something I can do as a user to help isolate this problem and get if fixed? Thanks.
Well, let's start with some basics. Make two fresh installs of SeaMonkey. Test them both using the user account to verify that they both work. Come back tomorrow and run one using the administrative account. Then do a search by date to find the files that were created or changed by running SeaMonkey. I'd like to know the list of new or newer files (compare with the other install to see which files are new). I'd also quite like to know the permissions on all the files although the procedure for this differs somewhat on Windows XP Home versus Professional.
(In reply to comment #0) > (snip) (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:126.96.36.199) "Permission Denied" is not handled well, if big endian? Or affected by Bug 385221(landed on trunk at 2007/7/17)? (see Bug 409849)
I installed a fresh copy of SeaMonkey 1.1.8 under the "admin1" account. After launching SeaMonkey under that account, these files were modified: Riegner-iMac2:seamonkey 1.1.8 admin1$ ls -l total 0 drwxr-xr-x@ 3 admin1 admin 102 Feb 2 07:37 SeaMonkey.app -rw-r--r-- 1 admin1 admin 0 Feb 13 21:34 now Riegner-iMac2:seamonkey 1.1.8 admin1$ ls -ld $(find . -newer now) drwxr-xr-x@ 29 admin1 admin 986 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome -rw-r--r-- 1 admin1 admin 48646 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome/chrome.rdf -rw-r--r-- 1 admin1 admin 6920 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome/overlays.rdf -rw-r--r-- 1 admin1 admin 490 Feb 13 21:36 ./SeaMonkey.app/Contents/MacOS/chrome/stylesheets.rdf drwxr-xr-x@ 247 admin1 admin 8398 Feb 13 21:35 ./SeaMonkey.app/Contents/MacOS/components -rw-r--r-- 1 admin1 admin 160040 Feb 13 21:35 ./SeaMonkey.app/Contents/MacOS/components/compreg.dat -rw-r--r-- 1 admin1 admin 120771 Feb 13 21:35 ./SeaMonkey.app/Contents/MacOS/components/xpti.dat
The new chrome.rdf is newer than the existing installed-chrome.txt I hope! If (as admin) you rename installed-chrome.txt can you then start as a user?
I renamed "installed-chrome.txt" to "dickie_installed-chrome.txt" and started SeaMonkey under the "admin1" account. It did not completely start-up: it only displayed its application name "SeaMonkey" in the menu bar; there was nothing else in the menu bar. I then renamed the file back and SeaMonkey started-up normally. And here are the files in the "chrome" directory after the successful start-up using "installed-chrome.txt" under the "admin1" account: Riegner-iMac2:chrome admin1$ pwd /applications/SeaMonkey 1.1.8/SeamOnkey.app/Contents/MacOS/chrome Riegner-iMac2:chrome admin1$ ls -lt total 27792 -rw-r--r-- 1 admin1 admin 48646 Feb 14 11:56 chrome.rdf -rw-r--r-- 1 admin1 admin 6920 Feb 14 11:56 overlays.rdf -rw-r--r-- 1 admin1 admin 490 Feb 14 11:56 stylesheets.rdf -rw-r--r--@ 1 admin1 admin 2670 Feb 2 07:55 inspector.manifest -rw-r--r--@ 1 admin1 admin 63 Feb 2 07:55 reporter.manifest -rw-r--r--@ 1 admin1 admin 1009809 Feb 2 07:37 toolkit.jar -rw-r--r--@ 1 admin1 admin 845658 Feb 2 07:37 venkman.jar -rw-r--r--@ 1 admin1 admin 2289207 Feb 2 07:37 messenger.jar -rw-r--r--@ 1 admin1 admin 890380 Feb 2 07:37 modern.jar -rw-r--r--@ 1 admin1 admin 721 Feb 2 07:37 pipnss.jar -rw-r--r--@ 1 admin1 admin 303138 Feb 2 07:37 pippki.jar -rw-r--r--@ 1 admin1 admin 53874 Feb 2 07:37 reporter.jar -rw-r--r--@ 1 admin1 admin 222465 Feb 2 07:37 sroaming.jar -rw-r--r--@ 1 admin1 admin 3353369 Feb 2 07:37 comm.jar -rw-r--r--@ 1 admin1 admin 14463 Feb 2 07:37 content-packs.jar -rw-r--r--@ 1 admin1 admin 26293 Feb 2 07:37 embed-sample.jar -rw-r--r--@ 1 admin1 admin 2103312 Feb 2 07:37 en-US.jar -rw-r--r--@ 1 admin1 admin 8629 Feb 2 07:37 en-mac.jar -rw-r--r--@ 1 admin1 admin 8870 Feb 2 07:37 en-unix.jar -rw-r--r--@ 1 admin1 admin 8935 Feb 2 07:37 en-win.jar -rw-r--r--@ 1 admin1 admin 49517 Feb 2 07:37 help.jar -rw-r--r--@ 1 admin1 admin 770081 Feb 2 07:37 inspector.jar -rw-r--r--@ 1 admin1 admin 7698 Feb 2 07:37 installed-chrome.txt -rw-r--r--@ 1 admin1 admin 1148612 Feb 2 07:37 chatzilla.jar -rw-r--r--@ 1 admin1 admin 263593 Feb 2 07:37 chromelist.txt -rw-r--r--@ 1 admin1 admin 635082 Feb 2 07:37 classic.jar -rw-r--r--@ 1 admin1 admin 86180 Feb 2 07:37 US.jar
Do you need any more debugging information from me? Is there anything else I can do to help resolve this problem?
Does anyone know if Firefox 188.8.131.52 and Thunderbird 184.108.40.206 have this same problem? Is converting from SeaMonkey to Firefox and Thunderbird a way to permanently fix this problem? Thanks.
(In reply to comment #69) > -rw-r--r--@ 1 admin1 admin 7698 Feb 2 07:37 installed-chrome.txt To Dick Riegner(bug opener): Do you use lang-pack? If yes, see Bug 412549.
No, I don't use lang-pack. This problem occurs with SeaMonkey 1.1.3 and later and does not occur with SeaMonkey 1.1.2 and earlier. It clearly looks like a regression to me.
(Without having read the whole bug) I would suggest to resolved this bug, and open a new/separate bug for the remaining issue...
In a mozilla.support.seamonkey thread "No 2nd machine Users for SM? Mac" started on Fri, 06 Feb 2009 19:23:00 -1000, Geoff Welsh posted: >User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:220.127.116.11) Gecko/20081204 not Firefox/18.104.22.168 SeaMonkey/1.1.14 >on both my Macs (G4, and G5 PPC OSX 10.4)... >When you create a second (machine) User account, the new user can launch >any App loaded on the machine and it starts up in a virgin state, and >they can customize it as they please. This works for FF, Camino, >iTunes, Safari... >But SM doesn't work! >It brings up a funny old style looking window with a bottom pane saying >"parsing error...." and there are no functions across the menu bar. >It's totally blank. When pointed at this bug, he wrote: >> That sounds exactly like the problem! I am always running from my admin account which obviously ruins the second user SM. I'll dig into that permissions modification later and report my result. >It seems I have fixed the problem, although not by modifying read/write privileges. >Trashing the chrome.rdf in the chrome folder of the Application "package contents" (NOT the chrome.rdf in the chrome folder of the User's profile folder) causes SM to function normally in the second (machine's) User acct.. Launching SM in the main user acct, creates a new chrome.rdf but the SM in the second user acct still works.
From what I see, as much as we can fix has been fixed here, and on trunk this is obsolete anyways, so let's mark it FIXED for good.
I still get it from time to time on updates. Haven't quite figured it out. Shouldn't 1.x branch bugs get marked WONTFIX if they are fixed in 2.0?
Rich, there are cases in here which we actually fixed, even though some edge cases might be left. Therefore, FIXED is correct here.