Closed Bug 709383 Opened 13 years ago Closed 13 years ago

Nightly (x64) won't start after update on 09.Dec.2011

Categories

(Release Engineering :: General, defect)

Product:
Release Engineering
Component:
General
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: minno, Assigned: catlee)

References

Details

(Keywords: crash, regression)

Attachments

(1 file)

disable win64 signing on m-c
1.48 KB, patch
rail
: review+
catlee
: checked-in+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Build ID: 20111120135848

Steps to reproduce:

Reinstalled it


Actual results:

After the Update on 09.Dec.2011 Nightly 11.0a1 (x64) won't start. (Windows 7, SP1)

Before that Update, everything was okay, and Nightly was for me the best Browser


Expected results:

Nightly 11.0a1 x64 should start normally after that update
Severity: normal → critical
windbg stack trace (on the 11.Dec version) shows:

...
MSVCR90!invoke_watson+0x11c
MSVCR90!invalid_parameter+0x70
MSVCR90!vsnwprintf_l+0x38
MSVCR90!vsnwprintf+0x11
firefox+0x2bba
firefox+0x263d
firefox+0x1bfa
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

I can't find the debug symbols so I'm not sure what the three Firefox calls are; but based on searching the source -- I'm guessing that an error occurred in "browser/app/nsBrowserApp.cpp" that then called "Output()" which is defined as _vsnwprintf.   If I had a guess it was one of the errors that didn't have a second parameter and the vsnwprintf with a bad call to NS_ConvertUTF8toUTF16 caused it to abort in 64 bit mode.  (Sorry I'm not finding instructions on how to build the source in VS 2008/2010 in 64 bit mode, otherwise I could trace it down, link anyone?)

Please note this first started in build 4360, 4359 starts fine.
Just as a data point I tried invoking profilemanager, and also safe-mode and others have tried deleting their profiles.  Does not make a difference; this issue occurs during startup initialization.  It crashes right after Process Monitor shows it loads the "xul.dll" and closed the "dependentlibs.list" files.
So it seems like this m-i -> m-c merge broke m-c: https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=98db2311a44c

However those crashes do not happen on m-i, I can use the latest rev (https://hg.mozilla.org/integration/mozilla-inbound/rev/f5578fdc50ef) just fine, even though m-c has been merged into m-i since then.

So what exactly is different in the m-c builds (build-process) that can trigger those crashes?

Bug 481815 seems to change something in the windows builds, could that be the culprit?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Arpad Borsos (Swatinem) from comment #3)
> However those crashes do not happen on m-i, I can use the latest rev
> (https://hg.mozilla.org/integration/mozilla-inbound/rev/f5578fdc50ef) just
> fine, even though m-c has been merged into m-i since then.

Are you comparing m-c nightlies to inbound nightlies, or m-c nightlies to inbound non-pgo tinderbox builds?
I'm comparing non-pgo buildbot builds on both.
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win64/1323357235/ <- This is the build that starts failing.
I have same problem here.

In my computer Nightly 64 bit edition crashes right after opening, actually it doesn't even open up, and it is not caught by Mozilla's Crash Reporter. 

Windows Error Reporting comes up and asks me to send additional information to Microsoft.

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-11.0a1.en-US.win64-x86_64.installer.exe

My CPU is AMD Athlon X3 450 running Windows 7, 64 bit.

I think this was caused by Friday's Dec 9th update.

Description
Faulting Application Path:	C:\Program Files\Nightly\firefox.exe

Problem signature
Problem Event Name:	BEX64
Application Name:	firefox.exe
Application Version:	11.0.0.4363
Application Timestamp:	4ee607fd
Fault Module Name:	MSVCR90.dll
Fault Module Version:	9.0.30729.6161
Fault Module Timestamp:	4dace4e7
Exception Offset:	00000000000552d4
Exception Code:	c0000417
Exception Data:	0000000000000000
OS Version:	6.1.7601.2.1.0.256.48
Locale ID:	1033
Additional Information 1:	c1d6
Additional Information 2:	c1d6a06768cf1a572f48bcdb45db11e8
Additional Information 3:	c477
Additional Information 4:	c477381a33995ac9846309a1652d377f

Extra information about the problem
Bucket ID:	2631310786
This is Dec 9th crash:

Source
Nightly

Summary
Stopped working

Date
‎12/‎9/‎2011 8:14 AM

Status
Report sent

Description
Faulting Application Path:	C:\Program Files\Nightly\firefox.exe

Problem signature
Problem Event Name:	BEX64
Application Name:	firefox.exe
Application Version:	11.0.0.4360
Application Timestamp:	4ee21310
Fault Module Name:	MSVCR90.dll
Fault Module Version:	9.0.30729.6161
Fault Module Timestamp:	4dace4e7
Exception Offset:	00000000000552d4
Exception Code:	c0000417
Exception Data:	0000000000000000
OS Version:	6.1.7601.2.1.0.256.48
Locale ID:	1033
Additional Information 1:	c1d6
Additional Information 2:	c1d6a06768cf1a572f48bcdb45db11e8
Additional Information 3:	c477
Additional Information 4:	c477381a33995ac9846309a1652d377f

Extra information about the problem
Bucket ID:	2625178952
Does it happens with the latest nighlty http://nightly.mozilla.org/?
(In reply to Scoobidiver from comment #8)
> Does it happens with the latest nighlty http://nightly.mozilla.org/?

Yes.
We've started signing win64 nightlies lately. Do any unsigned nightlies fail?
(In reply to Chris AtLee [:catlee] from comment #10)
> We've started signing win64 nightlies lately. Do any unsigned nightlies fail?

Since which checkin does that happen? I mentioned earlier that this bug started happening with the following push: https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=98db2311a44c

Are only m-c nightlies signed or also other branches? And are normal non-nightly build signed as well?
inbound nightlies are signed as are depend (non-nightly) builds on both central and inbound.

The patch that enabled that is part of that merge from inbound to central, https://hg.mozilla.org/mozilla-central/rev/6b60ebe2cae4 in particular.

I'm having this problem too, It started after Friday mornings update.
Nightly x64 is crashing while opening and I get the Windows Error Reporting

Please add me to this bugs updates, Thanks

Windows 7 x64
Intel Core 2 Duo E8400
If 12/(In reply to Chris AtLee [:catlee] from comment #12)
> inbound nightlies are signed as are depend (non-nightly) builds on both
> central and inbound.
> 
> The patch that enabled that is part of that merge from inbound to central,
> https://hg.mozilla.org/mozilla-central/rev/6b60ebe2cae4 in particular.

If I understand that https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=98db2311a44c has what went into 4360 then yes, that changeset (6b60ebe2cae4) does show in the change log that went into the build 4360 which is the first broken build.
But inbound is not affected by this bug. I'm running inbound tip http://hg.mozilla.org/integration/mozilla-inbound/rev/f5578fdc50ef which includes the said changeset but does not crash at startup.

Any other idea what might be the difference between the branches that can cause this?
Looks like we're not signing win64 on inbound....
With the Dec 9 update, Firefox 11.0a1 64-bit is still crashed. It has something to do with MS C Runtime library. Revert back to Dec 8 update and it works again.

Faulting application name: firefox.exe, version: 11.0.0.4363, time stamp: 0x4ee607fd
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace4e7
Exception code: 0xc0000417
Fault offset: 0x00000000000552d4
Faulting process id: 0x448
Faulting application start time: 0x01ccb921f76a1e40
(In reply to wisspur from comment #17)
> With the Dec 9 update, Firefox 11.0a1 64-bit is still crashed. It has
> something to do with MS C Runtime library. Revert back to Dec 8 update and
> it works again.
> 
> Faulting application name: firefox.exe, version: 11.0.0.4363, time stamp:
> 0x4ee607fd
> Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp:
> 0x4dace4e7
> Exception code: 0xc0000417
> Fault offset: 0x00000000000552d4
> Faulting process id: 0x448
> Faulting application start time: 0x01ccb921f76a1e40

Sorry I meant "With the Dec 12 update (not Dec 9) ..
Here's my .02:

Problem signature
Problem Event Name:	BEX64
Application Name:	firefox.exe
Application Version:	11.0.0.4361
Application Timestamp:	4ee3646e
Fault Module Name:	MSVCR90.dll
Fault Module Version:	9.0.30729.6161
Fault Module Timestamp:	4dace4e7
Exception Offset:	00000000000552d4
Exception Code:	c0000417
Exception Data:	0000000000000000
OS Version:	6.1.7601.2.1.0.768.3
Locale ID:	1033
Additional Information 1:	c1d6
Additional Information 2:	c1d6a06768cf1a572f48bcdb45db11e8
Additional Information 3:	c477
Additional Information 4:	c477381a33995ac9846309a1652d377f
Log Name:      Application
Source:        Application Error
Date:          12/13/2011 6:17:08 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic

Description:
Faulting application name: firefox.exe, version: 11.0.0.4363, time stamp: 0x4ee607fd
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace4e7
Exception code: 0xc0000417
Fault offset: 0x00000000000552d4
Faulting process id: 0x1790
Faulting application start time: 0x01ccb988c0630106
Faulting application path: C:\Program Files\Nightly\firefox.exe
Faulting module path: C:\Windows\WinSxS\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251\MSVCR90.dll
Report Id: fe173ccb-257b-11e1-b9c7-90e6baeec564

I have tried repairing MSVC and complete firefox wipe and reinstall with no luck in fixing the crash.
Crashed immediately
But if I install Nightly over existing installation
It works for the FIRST launch, any subsequent launches will crash though
UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111212 Firefox/11.0a1
I cannot reproduce.

Did you try with a new profile (see https://support.mozilla.com/en-US/kb/Managing-profiles)?
(In reply to Scoobidiver from comment #23)
> UA: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111212
> Firefox/11.0a1
> I cannot reproduce.
> 
> Did you try with a new profile (see
> https://support.mozilla.com/en-US/kb/Managing-profiles)?

I assume my comment #2 wasn't clear enough. :)   Profiles don't make a difference.  This bug also does NOT appear for everyone -- according to others who are not seeing this on the Mozillazine forums; so there is some environmental factor (but based on watching it startup with ProcessMonitor it dies long before profiles are even attempted to be loaded). 

   My personal opinion as another developer is that there are two different issues; the first issue (something while initializing/loading xul.dll) causes an error; and when FireFox startup routine goes to report the failure it dies because it passes a bad paramater to vsnwprintf according to the stack trace I got out of WinDbg...  The error we are seeing is a not the root issue...
(Add me to watch this thread)

I have the same identical problem.... I did find a reference to the BEX64 error on another app forum and they found it was a problem with DEP and signing.

I am specifically running FF x64 on Win7 (Nightly-Central).  It has been fantastic for several months.  Can't wait to get it back :-D
The same happened to me with Win XP x64, so it's probably not related to OS
Summary: Nightly (x64) won't start after update on 09.Dec.2011 (Windows 7 SP1) → Nightly (x64) won't start after update on 09.Dec.2011
even with Dec 13 update, it's still crashed.

Faulting application name: firefox.exe, version: 11.0.0.4364, time stamp: 0x4ee759a0
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace4e7
Exception code: 0xc0000417
Fault offset: 0x00000000000552d4
Faulting process id: 0x1218
Faulting application start time: 0x01ccb9cbbade1d00
Faulting application path: C:\FirefoxPortable\App\firefox\firefox.exe


ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/firefox-11.0a1.en-US.win64-x86_64.zip

        Attachment #581343 -
        Flags: review?(rail)

    
    

    
  
seems pretty likely that signing is breaking this somehow. We'll turn off signing of win64 builds on mozilla-central for now.

    
  

        Attachment #581343 -
        Flags: review?(rail) → review+

    
  
Assignee: nobody → catlee
Component: General → Release Engineering
Product: Firefox → mozilla.org
QA Contact: general → release
Version: 11 Branch → other

    
    

    
  
Comment on attachment 581343 [details] [diff] [review]
disable win64 signing on m-c

This should take effect tonight.

        Attachment #581343 -
        Flags: checked-in+

    
    

    
  
This may be irrelevant. If so, my apologies, I am kind of new here. I'm running the latest UX builds.  11.0a1 (2011-12-13)is the latest build. Windows Pro, x64, ATI 5800 chipset. 

How different from the Nightly build is the UX build? After the nightly build started crashing, I went to the UX build with no issues. 

Again - sorry for my ignorance. How different are they?

    
    

    
  
(In reply to Neural from comment #31)
> This may be irrelevant. If so, my apologies, I am kind of new here. I'm
> running the latest UX builds.  11.0a1 (2011-12-13)is the latest build.
> Windows Pro, x64, ATI 5800 chipset. 
> 
> How different from the Nightly build is the UX build? After the nightly
> build started crashing, I went to the UX build with no issues. 
> 
> Again - sorry for my ignorance. How different are they?

UX build is a variant of 32Bit Nightly. We're talking 64-Bit builds here.

    
    

    
  
Thanks for the info. Much appreciated. Looking forward to a 64bit build that runs.

    
    

    
  
Not to beat a dead horse but looking in Microsoft's Process Explorer, it's running as a 64 bit app.

    
    

    
  
(In reply to Neural from comment #34)
> Not to beat a dead horse but looking in Microsoft's Process Explorer, it's
> running as a 64 bit app.

Whoops, didn't notice that, but in short seems code signing was enabled for 64Bit Nightly only, which is why UX branch was not affected

    
    

    
  
Got it. Thanks!

    
    

    
  
(In reply to Chris AtLee [:catlee] from comment #30)
> Comment on attachment 581343 [details] [diff] [review]
> disable win64 signing on m-c
> 
> This should take effect tonight.

I just tried the latest m-c build: https://hg.mozilla.org/mozilla-central/rev/fd6ab19f312c and it still crashes.
How can I tell if it is signed or not?
(tbpl really needs to correlate code-pushes with infra-pushes)

    
    

    
  
Same Here.....
File info shows.... ooops - The file on nightly.mozilla.org is still from 12/13 and is signed.

Guess I'll wait a bit... or hunt it down from ftp.

    
    

    
  
the latest build stills crash to desktop... :(
and it is still signed...

    
    

    
  
Same Crash.....

As far as signing, I see digital cert info on the installer, but not on the .exe file.  I don't know if I'm supposed to or not.

<EventType>BEX64</EventType> 
<Parameter0>firefox.exe</Parameter0> 
<Parameter1>11.0.0.4365</Parameter1> 
<Parameter2>4ee8aa11</Parameter2> 
<Parameter3>MSVCR90.dll</Parameter3> 
<Parameter4>9.0.30729.6161</Parameter4> 
<Parameter5>4dace4e7</Parameter5> 
<Parameter6>00000000000552d4</Parameter6> 
<Parameter7>c0000417</Parameter7> 
<Parameter8>0000000000000000</Parameter8>

    
    

    
  
Reinstalled 12/8 N-C.  File properties for firefox.exe look identical and there is no mention of digital certs on any of the versions (BTW, I am not really certain how signing actually works...)

But, The installer for all versions from 12/9 to current (including today 12/14) has a file info tab for digital cert.  The 12/8 version does not contain that tab.

    
    

    
  
I reconfig-ed with the landed changes from this bug today.

    
    

    
  
This ia all I can get from the log on Thunderbird v10 (Earlybird). I can't get any log for version 11 (Daily), since it hangs.

0[100f140]: nsLDAPOperation::SimpleBind(): called; bindName = 'name@yyy.com'; 
0[100f140]: pending operation added; total pending operations now = 1
0[100f140]: nsLDAPConnection::RemovePendingOperation(): operation removed
0[100f140]: nsLDAPConnection::RemovePendingOperation(): operation removed; total pending operations now = 0
0[100f140]: unbinding
0[100f140]: unbound

It's still not working after Dec 14 update.

and this is the log when it is working -- v9

0[100f140]: nsLDAPOperation::SimpleBind(): called; bindName = 'name@yyy.com'; 
0[100f140]: pending operation added; total pending operations now = 1
3652[647a140]: pending operation removed; total pending operations now = 0
0[100f140]: nsLDAPOperation::SearchExt(): called with aBaseDn = 'fn=ContactRoot'; aFilter = '(objectclass=*)'; aAttributes = ; aSizeLimit = 0
0[100f140]: pending operation added; total pending operations now = 1
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000084,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000020,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000f,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000073,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000033,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000010,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000013,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000014,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000c,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000074,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000082,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000069,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000016,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000017,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
3652[647a140]: pending operation removed; total pending operations now = 0
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000018,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000c,fn=Contacts,fn=Public Folders,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000002,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007e,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001c,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000080,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001e,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000001f,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000022,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000071,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000085,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000004,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000079,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000007,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000027,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007c,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000002a,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000083,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000003,fn=Contacts,fn=Public Folders,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000006,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006e,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000030,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000072,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000031,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000034,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000086,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000036,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000076,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000000e,fn=Contacts,fn=Public Folders,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000008,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000038,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007d,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006f,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000039,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007a,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000007b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=00000087,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: nsLDAPMessage::GetDn(): dn = 'cn=0000006b,fn=Contacts,cn=name@yyy.com,fn=ContactRoot'
0[100f140]: unbinding
0[100f140]: unbound

    
    

    
  
oopss.. wrong forum. How can I delete it?

    
    

    
  
So with a recent unsigned build (I checked via file properties) for revision http://hg.mozilla.org/mozilla-central/rev/472b4a4ebea7 everything is back to normal again.
Someone please verify once a nightly is available.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED

    
    

    
  
Nightly is now up and running on my computer :)

    
    

    
  
FIXED - yes, it works for me as well.

Thanks!

    
    

    
  
Per comment 46 and 47, I mark it as verified.
Status: RESOLVED → VERIFIED

    
    

    
  
So, will the future nightly get signed?

    
    

    
  
Yes, that is the plan. Getting it working is tracked in bug 711210 if you're interested.

Builds on the elm branch are still signed:
http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/latest-elm/firefox-11.0a1.en-US.win64-x86_64.installer.exe
Product: mozilla.org → Release Engineering
Keywords: regressionwindow-wanted
QA Contact: mshal

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: