328669 - Firefox trunk hangs on start on win2k3 and winXP

Status: VERIFIED DUPLICATE of bug 328676

(Core :: Graphics, defect)

Description

[Bob Clary [:bc] (inactive)]

Today's nightly trunk zip builds fail to start on Windows Server 2003. The build pegs the cpu and just sits there. Not sure how to diagnose.

This is not the case on winxp.

Comment 1

[Bob Clary [:bc] (inactive)]

Still an issue with 20060301 builds. This blocks me testing nightly builds on the trunk for windows.

Comment 2

[Bob Clary [:bc] (inactive)]

Attachment: nspr log

zipped nspr log for the first 18 cpu seconds.

Comment 3

[Bob Clary [:bc] (inactive)]

Trying to test the installer version I get a Microsoft Visual C++ Runtime Library error dialog:

Program: C:\....\setup.exe

R6034
An application has made an attempt to load the C runtime library incorrectly. 
...

methinks this is vc8 related.

Comment 4

[Bob Clary [:bc] (inactive)]

finally got my debug builds working. The hang appeared right after these assertions.

###!!! ASSERTION: No DC: 'aDC', file c:/work/mozilla/builds/ff/trunk/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp, line 459
cairo_win32_scaled_font_select_font:SelectObject: The handle is invalid.
###!!! ASSERTION: No DC: 'aDC', file c:/work/mozilla/builds/ff/trunk/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp, line 555
cairo_win32_scaled_font_select_font:SelectObject: The handle is invalid.

over to core gfx win

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Also saw this on XP Pro with the exact same assertions in comment #4. Updating summary.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Are you using 16 bit color depth? There have been reported issues with the cairo backend in those cases.

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to comment #6)
> Are you using 16 bit color depth? There have been reported issues with the
> cairo backend in those cases.
> 

32bit here.

Comment 8

[Gabriel Sjoberg]

Are you running this over a TS/RDP connection?  There have been reports of that not working.

Comment 9

[Bob Clary [:bc] (inactive)]

I don't see issues on my local winxp boxes which are at 32bit normally, but do access the win2k3 boxes via windows rdp which is 16bit. I can reproduce with my local machine when switching to 16bit however.

Comment 10

[Gabriel Sjoberg]

Ahhh...so this is a duplicate of 328432.  Marking as such.

*** This bug has been marked as a duplicate of 328432 ***

Comment 11

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Ah, I was running over rdp. For some reason my color depth gets reduced to 16bit despite my connection settings... Running locally works as expected.

However, I don't think this is necessarily a dup of 328432. Those folks are seeing an invisible frame and not making any mention of the above assertions...

Comment 12

[Gabriel Sjoberg]

You've certainly added information to the bug.  That's why a notification is placed on the other bug as well.  Your logs will be much appreciated, I'm sure.  However, the bug 328432 report predates yours by 2 days, so I marked this one as the duplicate.  If you feel your work might be overlooked, feel free to attach it to the other bug or include a additional message pointing to this bug.

Personally, I've experienced this very bug daily since moving to Cairo, so I have great motivation to see it resolved quickly.  I'd be shooting myself in the foot if I was hiding something that might be important to fixing this issue.

Comment 13

[Stuart Parmenter]

it gets in to an infinite loop if aDC is null in that code.  aDC is only null in that code if it is 16bpp.  i'm pretty sure this is a dup.. I'm hoping to fix it this week.

Comment 14

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Yeah, looks more like bug 328676 to me, although the two may be closely related.

Comment 15

[Ben Turner (not reading bugmail, use the needinfo flag!)]

*** This bug has been marked as a duplicate of 328676 ***