xulrunner-stub.exe crashes in gfxUserFontSet::OnLoadComplete when using CSS with @font-face

RESOLVED FIXED in mozilla14

Status

()

Core
Graphics
--
critical
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: poppertd, Assigned: emk)

Tracking

({crash})

Trunk
mozilla14
crash
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2
Build ID: 20110902133214

Steps to reproduce:

1. Create a XULRunner application that uses @font-face CSS declaration to load a font from a URL.
2. Launch the application using xulrunner-stub.exe


Actual results:

The application crashes on startup.


Expected results:

The application should have started normally and used the applied font.  Launching the same application using xulrunner.exe -app path/to/application.ini works as expected.

Comment 1

6 years ago
Your are using a version that is no longer maintained. Please update and report back.
Severity: normal → critical
Keywords: crash
Also you need to be specific: what is the stack trace of the crash? You can a combination of your local debugging symbols and the Mozilla symbol server to debug the process and get a stack trace. https://developer.mozilla.org/En/Using_the_Mozilla_symbol_server
(Reporter)

Comment 3

6 years ago
Created attachment 606790 [details]
WinDbg Stack Trace
(Reporter)

Comment 4

6 years ago
Scoobidiver, this is a bug filed against XULRunner version 11.

Comment 5

6 years ago
It seems a dupe of bug 730550 (same stack trace).
Does it happen with Aurora 13 or Nightly?
Crash Signature: [@ __delayLoadHelper2]
Component: XULRunner → Graphics
Product: Toolkit → Core
QA Contact: xulrunner → thebes
(Reporter)

Comment 6

6 years ago
It still happens with Aurora 13.0a2 (2012-03-17-04-20-20-mozilla-aurora).

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: xulrunner-stub.exe crashes when using CSS with @font-face → xulrunner-stub.exe crashes in gfxUserFontSet::OnLoadComplete when using CSS with @font-face

Comment 7

6 years ago
I'm guessing this is bug 730550.  The fix there checks for t2embed but it doesn't assure that the proc address of t2embed functions are non-null (if a dummy lib is used for example).

Comment 8

6 years ago
(In reply to John Daggett (:jtd) from comment #7)
> I'm guessing this is bug 730550.
Bug 730550 is fixed in Aurora 13 while this bug is not fixed in Aurora 13.

Comment 9

6 years ago
(In reply to Scoobidiver from comment #8)
> (In reply to John Daggett (:jtd) from comment #7)
> > I'm guessing this is bug 730550.
> Bug 730550 is fixed in Aurora 13 while this bug is not fixed in Aurora 13.

If you look carefully at the fix, it will prevent failure in the case that t2embed.dll is missing but not if it has been replaced by a dummy lib.  The list of dll's includes t2embed.dll and yet the crash occurs.

For anyone that can reproduce this, what is the size/date/version of the t2embed.dll?

I think we probably need to undo the changes that were originally made, such that if the proc pointers are null we fail gracefully.  The better fix would be to remove the dependence on t2embed.dll completely as it's no longer necessary since the sanitizer code rebuilds the font anyways.

Comment 10

6 years ago
i.e. undo the font loading code changes for both bug 730550 and bug 699247.
Blocks: 730550, 699247
(Assignee)

Comment 11

6 years ago
Created attachment 606977 [details] [diff] [review]
Restore GetProcAddress check for t2embed library

This patch is not a simple backout in two ways.
1. Try to load t2embed library only once. Before bug 699247, library load was tried everytime gfxGDIFontList is initialized.
2. Fallback to AddFontMemResourceEx path if t2embed library or functions are unavailable.
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED
Attachment #606977 - Flags: review?(jdaggett)

Comment 12

6 years ago
Comment on attachment 606977 [details] [diff] [review]
Restore GetProcAddress check for t2embed library

r+, with adjustments to line lengths please
Attachment #606977 - Flags: review?(jdaggett) → review+
(Assignee)

Comment 13

6 years ago
Created attachment 607147 [details] [diff] [review]
Restore GetProcAddress check for t2embed library. r=jtd
Attachment #606977 - Attachment is obsolete: true
Attachment #607147 - Flags: review+
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/d4fa7d697295
Flags: in-testsuite?
Keywords: checkin-needed
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/d4fa7d697295
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Version: 11 Branch → Trunk

Updated

6 years ago
Duplicate of this bug: 739083

Updated

6 years ago
Crash Signature: [@ __delayLoadHelper2] → [@ __delayLoadHelper2] [@ __delayLoadHelper2 | _tailMerge_gkmedias_dll]
Depends on: 731894
Is it possible to create an automated test for our testsuite?
You need to log in before you can comment on or make changes to this bug.