User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082602 SeaMonkey/2.0a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082903 SeaMonkey/2.0a1pre after starting seamonkey, i can not find it in the taskmanager and the crashreporter is not running. Reproducible: Always Steps to Reproduce: 1. start seamonkey Actual Results: no traces of a running seamonkey. Expected Results: seamonkey shows up in the taskmanager or the crashreporter starts

Tbird crashes in current trunk nightly also. But does produce a crash report. http://crash-stats.mozilla.com/report/index/da927478-567d-11dc-accb-001a4bd46e84?date=2007-08-29-22 Looks like layout, but I can't see a pertinent checkin. No Tbird trunk available yesterday. Previous day was OK

I can confirm that the latest trunk from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/ Fails to load with no error indications.

Worksforme on Linux with 2007-08-29-01 build.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007082903 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4) (WorksForMe)

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007082903 Mnenhy/0.7.5.20003 SeaMonkey/2.0a1pre WorksForMe too, using the *.zip-Builds, have not tried Installer-Builds. Florian, did you use the Installer- or *.zip-Builds?

(In reply to comment #0) > after starting seamonkey, i can not find it in the taskmanager and the > crashreporter is not running. > > Reproducible: Always Same here. SM do not start. No taskmanager, no crash - nothing! Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007082806 SeaMonkey/2.0a1pre First build with this symptoms on my System was 2007082903. Last good was 2007082806 Using Tinderbox zip-builds from: ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/sea-win32-tbox-trunk/

As I just remember fixed Bug 389523, I would like to ask someone with a non starting Build to use Sysinternals Process-Monitor at failing SM-Startup to get a closer look.

(In reply to comment #5) Zip Build Will try the Process-Monitor

Ted, return of the bug 350616 startup crash? Your report from bug 350616 comment 53 seems to be gone, but you said then "in nsFrame" which is where Joe is crashing Tbird, and I don't see other obvious "that could cause a Windows-only startup crash" things between the 28th and 29th.

Phil, definitely looks like it, but I haven't seen reports of it affecting Firefox, so this must be a SeaMonkey-specific issue. If I had to hazard a guess, I'd say that you're not statically linking the CRT into the stuff in components/. You need to do that.

A SeaMonkey/Thunderbird-specific issue, apparently. *They'll* need to do that, to fix SeaMonkey; then I'll learn how from that, and imitate it for Thunderbird :)

Also, fwiw, old reports are still around: http://crash-reports.stage.mozilla.com/reports/report/index/27a59de6-1758-11dc-a54e-001a4bd43ed6

Right, so, it's not going to be quite that easy, since as bsmedberg points out, things like gklayout would need to have that ifdef'ed into every Makefile. The easier way out is just going to be to ifdef out the rules.mk logic from bug 350616 based on whether libxul is enabled. We'll also want to restore some of the EMBED_MANIFEST_AT logic (ifndef libxul), since some of that was for Thunderbird. I don't have time to get to this right now, I may get to it over the weekend. If someone else wants to put together a patch, feel free.

Oh, as an aside, you can work around this by installing the VC8 CRT redist: http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en

(In reply to comment #15) > Oh, as an aside, you can work around this by installing the VC8 CRT redist: > http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en > That worked quite nicely for Tbird trunk, they run fine after the update. Seamonkey is another story, no change after the CRT upgrade..they still don't start.

As far as performance goes, I keep my own benchmarks for Tbird. I don't know about Tp and extra parsing but I can say one thing for sure. Downloading and installing the new VC8 Crt certainly had a positive impact here. This is like getting a whole new rendering engine, about as good as when nsiThreadmanager landed on trunk. My personal evaluation: at least 5% better performance, especially on DHTL

Well it seems those perf improvements must have been some fleeting condition of the swap file, or some other condition in winxp. They don't seem to be real. But I do see an observable improvement in startup time. Just subjective observation, no real stats.

Hmm, may bug 392526 play into that?

Seems like more than a few TB trunk testers/users affected. http://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/3.0a1pre

This is a long shot, but you never know. I just checked in bug 395527 - it should ensure that release builds will re-register their components (i.e. update compreg.dat) when you install the new build. Given I've heard that it seems to be a little inconsistent who's affected and who isn't, I've been pondering if this is a result of outdated (to different extents) versions of compreg.dat. Like I say, its a long shot, but if folks could test the next nightly, that would be good to verify.

(In reply to comment #22) > Like I say, its a long shot, but if folks could test the next nightly, that > would be good to verify. I tested SM 2007090813 and 14. Both do not start :-(

(In reply to comment #22) > ...if folks could test the next nightly, that would be good to verify. SM2007-09-08-02-trunk do not work for me either, WinXPHomeSP2. When calling 'seamonkey -p' not even the profile manager shows up. The files seamonkey\components\compreg.dat and seamonkey\components\xpti.dat are created, but compreg.dat has only a size of 330 byte (compared to SM2007082803, where this file has a size of about 108k).

I copied Microsoft.VC80.CRT.manifest and the three msvc?80.dll files down a level into the components subdirectory and managed to get SM20070829 and 20070907 to run. WinXP Home SP2.

That pretty well confirms my theory, thanks.

(In reply to comment #26) > I copied Microsoft.VC80.CRT.manifest and the three msvc?80.dll files down a > level into the components subdirectory and managed to get SM20070829 and > 20070907 to run. That don't work for me. > WinXP Home SP2. Vista Ultimate and SM-Trunk

Results seem to be mixed for Thunderbird trunk. For some installing vcredist_86 does not work, for others copying the dll's into the components folder *does* work. See: http://forums.mozillazine.org/viewtopic.php?p=3052653#3052653

As the installation of the VC8 CRT redist didn't help I checked the MS website and there is already a VC8 CRT redist SP1: http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en After the installation of this package SeaMonkey starts up again for me.

(In reply to comment #30) > As the installation of the VC8 CRT redist didn't help I checked the MS website > and there is already a VC8 CRT redist SP1: Sven, thank you very much. That was the right clue! SM is working again.

nothing i've tried for Tb: 1. install sp1 version of msvcrt (already had the older version) 2. copying the msvcrt files into \components has worked. Tb will not start, gets up to 11M or so in task manager, no profile dialog. winxp sp1.

(In reply to comment #34) > 1. install sp1 version of msvcrt (already had the older version) > 2. copying the msvcrt files into \components > > has worked. Tb will not start, gets up to 11M or so in task manager, no > profile dialog. winxp sp1. Reinstall Tb now. After installing the msvcrt-sp1 I had to install SM new. Then it works. The copying to \components was not necessary.

yes, once Tb is reinstalled, it will start. thanks ruediger.

(In reply to comment #35) > After installing the msvcrt-sp1 I had to install SM new. Then it works. > The copying to \components was not necessary. I also experienced similar issue with ZIP builds of both Seamonkey & Thunderbird. But when I deleted program directory and unzip'ed again(msvcrt-sp1 is already installed), problem disappeared without copying dll's. So I unzip Seamonkey/Thunderbird into read-only(no write permission) directory, and comared program directory content. Following files are found in write-permitted directory only. Thunderbird trunk 9/17 ZIP build : components\compreg.dat (found in profile directory too) components\xpti.dat (found in profile directory too) Seamonkey trunk 9/17 ZIP build : chrome\app-chrome.manifest components\compreg.dat (found in profile directory too) components\xpti.dat (found in profile directory too) It seems to be similar issue to Bug 376173(Linux) or Bug 389136(Mac). Big problem doesn't seem to usually occur on MS Win when program directory is write permitted.

WADA: The problem here is completely different from bug 376173 and bug 389136 and has nothing in common with them. The issue here is that we don't load the CRT correctly, installing the CRT package from Microsoft is only a workaround in the first place and no real fix. Deleting the .dat files in components might fix the problem of still not starting when the SP1 CRT is already installed, but those files are not the cause of this bug. The builds still not working in that case might just be another symptom of the real bug here. We know what the bug is, it's just that Ted, who needs to work on the fix, is very busy, so he needs some time to come around to do the actual fix.

(In reply to comment #38) > WADA: The problem here is completely different from bug 376173 and bug 389136 > and has nothing in common with them. Kiser, please don't worry about. My comment is for comment #34, comment #35, comment #36, for problem while try to work around, and objective is to avoid confusion while try to work around. It's not for original problem itself. - After install of msvcrt-sp1, re-install or re-unzip is required in some cases, and three is no need to copy modules to components when re-installed/unzip'ed.

Off-Topic. About issue of comment #34, comment #35, comment #36, comment #37 only. (In reply to comment #38) > Deleting the .dat files in components might fix the problem of still not > starting when the SP1 CRT is already installed, Culprit was components\compreg.dat in write-permitted program directory. To Robert Kaiser: Should I open bug for garbage of compreg.dat&xpti.dat? (What common with bug 376173/bug 389136 is: Mozilla family writes garbage in ) ( program directory, and existence of the garbage interferes Mozilla itself. )

Those files are not garbage, they are useful. They just might need to be rewritten sometimes when the environment around them changes in some way (e.g. when you install a different CRT).

Why is this bug not a blocker?

blocker seems appropriate for its affect on thunderbird. or critical if it doesn't fully meet the qualifications for blocker.

(About workaround, not about original issue of this bug) Before install of msvcrtsp1, workaround of Comment #26 (copy manifest file & msvc?80.dll to components directory) didn't work in my environment. It found that the failure was caused by existence of old compreg.dat in components. (tested with 9/17 build) 1. Install msvcrtsp1, and delete components\compreg.dat => Thunderbird starts normally msvc*80.dll's are read from C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_... <Program Directory>\components\compreg.dat is written 2. Uninstall msvcrtsp1, and copy manifest & msvc?80.dll to components => Thunderbird's profile manager window won't appear 3. Delete <Program Directory>\components\compreg.dat => Thunderbird's profile manager starts normally Thanks to Robert Kaiser for your explanations. Summary of currently available workaround: (A) Workaround of Comment #26. Without msvcrtsp1. Copy Microsoft.VC80.CRT.manifest and three msvc?80.dll (files placed at same level as thunderbird.exe) to components directory. (B) Workaround of Comment #30. With msvcrtsp1. Install msvcrtsp1. Note: In both cases, components\compreg.dat should be deleted manually, if the program directory is write permitted and is previously used. (This is mentioned by Comment #22 and Comment #41)

Trunk testers are not necessarily developers, and I think we need them. I can understand a short period of leaving a core crasher like this for purposes of gathering data, but this seems to be just plain disresectful to testers. I don't know if there is a policy on this, but I think it's time to backout changes applied in bug 350616 on 2007-08-28 10:38 Crashers in http://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/3.0a1pre would probably agree.

(In reply to comment #44) None of this seems to work for Seamonkey trunk 2007-09-20, plus I don't really understand the instructions all the way. What's the use of installing the ms*.dll 's from MS if you're using files that are already in the tb/sm directory? And what's the use in copying them down from the program dir to the components dir? (In reply to comment #45) I'm a trunk _user_. That is, I more-or-less-stable recent trunk version for all of my browsing, email and news. I do it both to help test the trunk and since it is often the case that Hebrew support and other issues (e.g. toolkit transition) improve on the trunk long before they do on the release branches. But every now and then somebody checks something in which busts the trunk completely, like with this bug, or busts it for a certain kind of users, like bug 387564. Now, even after the bug is reported and acknowledged as major, or even critical or blocker, I would expect the patch author to be in the situation of having to come up with a patch to avoid the crash within X days, or back his own patch out. But nobody seems to share this view. Now, ok, if it's a monumental patch like turning on MOZ_XUL_APP, then ok (even though that could be done on a branch first, then landed back on the trunk with minimal harm) - but otherwise, why is backing out not the norm?

(In reply to comment #46) > I don't really understand the instructions all the way. To Eyal Rozenberg: Following documents may help you. http://msdn2.microsoft.com/en-us/library/ms235624(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ms235531(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ms235299(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ms235316(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ms235291(VS.80).aspx http://msdn2.microsoft.com/en-us/library/ms235342(VS.80).aspx http://msdn2.microsoft.com/en-us/library/aa374219.aspx http://msdn2.microsoft.com/en-us/library/aa374224.aspx

I need to do some builds to test this, but this should handle both cases properly. I apologize to the nightly testing community for the delay, it was unfair for me to leave you in this situation for this long.

Here's a Thunderbird build with this patch applied. It works fine for me in my test VM: http://people.mozilla.com/~tmielczarek/thunderbird-3.0a1pre.en-US.win32.zip

And a SeaMonkey build, which also WFM: http://people.mozilla.com/~tmielczarek/seamonkey-2.0a1pre.en-US.win32.zip

Comment on attachment 281937 [details] [diff] [review] embed manifests in everything only in libxul configuration, restore specific EMBED_MANIFEST_AT rules in some places Pretty simple patch, it reverts to the previous behavior unless we're building libxul.

Can't totally confirm the fis for TB since I intalled the VC8 redist however, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092209 Thunderbird/3.0a1pre ID:2007092209 loads and runs with a clean intall and existing profile. For the seamonkey build, previously I had to copy the VC8 files into /components That's not necessary now. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092210 SeaMonkey/2.0a1pre Thanks Ted

(In reply to comment #50) WFM too.

(In reply to comment #51) > Pretty simple patch, it reverts to the previous behavior unless we're building libxul. To Ted Mielczarek: What will happen when libxul will be re-built? libxul only issue? Or this bug's issue can occur on other than libxul in future? If latter, is there any plan to completely resolve issue found by this bug when all modules have embeded manifest(it seems to be recommend by MS)? What is root cause of the issue when all modules have embedded manifest?

These problems don't occur in a libxul build, as evidenced by the fact that Firefox has not been affected. I'm not really sure what the root cause is, there were suspicions it might be mismatched CRT allocators or something like that. Given that it doesn't affect the libxul case, and that's what we'd like to have everything built on, I'm content with this patch.

(In reply to comment #56) Being able to avoid this problem rather than resolving does not seem like a good idea, because it is not at all improbable that sometime in the near future somebody else will tweak the build config somehow and stumble upon this problem again. I'm not knowledgeable enough about this issue to do anything meaningful, but I would at least ask you to try and locate the actual cause of the problem.

good idea, but perhaps in a follow up patch given the current trunk pain? Unless for some reason bs' approval on the current patch will be delayed.

Ok, I did some poking around, and there's nothing mysterious about this. jar50.dll lives in components, and with a manifest embedded it fails to load. The crash is just a manifestation of failing to load the jar protocol handler. We could fix this for Thunderbird by statically linking jar50, jsd3250, and xpinstal with the CRT, but we'd still need this patch to fix SeaMonkey anyway, so it's not worth the effort. Once Thunderbird and SeaMonkey can switch to libxul, they'll just have to ensure that they statically link to the CRT in any binary components they have left, just like Firefox does.

Ted, this sounds good! Now let's hope Benjamin will review this soon and we're all happy ;-) Thunderbird and SeaMonkey both target to move to libxul some time, but as we all know, we still have a bit of our way to that still in front of us...

(In reply to comment #59) > We could fix this for Thunderbird by statically linking jar50, jsd3250, > and xpinstal with the CRT According to Comment #26, "manifest file and msvc?80.dll in components directory" resolves this bug's issue. This indicates that components directory is also an application directory from point of "Assembly Seacrhing" view, when current Thunderbird and Seamonkey. I think packaging change to "manifest&msvc?80 in components too" is simpler solution. Is it wrong way? Will it cause other problems?

Uh, the CRT is pretty large. We're not going to ship a whole extra copy of it just to fix this, when we have a workable solution in this patch.

Comment on attachment 281937 [details] [diff] [review] embed manifests in everything only in libxul configuration, restore specific EMBED_MANIFEST_AT rules in some places >Index: config/rules.mk >+ifeq ($(MOZ_ENABLE_LIBXUL),1) >+EMBED_MANIFEST_AT=2 >+endif Make this ifdef MOZ_ENABLE_LIBXUL, with that r=me

Comment on attachment 281937 [details] [diff] [review] embed manifests in everything only in libxul configuration, restore specific EMBED_MANIFEST_AT rules in some places This will fix SeaMonkey and Thunderbird on trunk Win32...

Comment on attachment 281937 [details] [diff] [review] embed manifests in everything only in libxul configuration, restore specific EMBED_MANIFEST_AT rules in some places a=bzbarsky

Checked in.

Just downloaded and INSTALLED SUCCESSFULLY a "tinderbox" "installer" build from: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/sea-win32-tbox-trunk/ It works! Nightly trunk builds seem back in action finally after almost a month.