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.
Your are using a version that is no longer maintained. Please update and report back.
Severity: normal → critical
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
Scoobidiver, this is a bug filed against XULRunner version 11.
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
It still happens with Aurora 13.0a2 (2012-03-17-04-20-20-mozilla-aurora).
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
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).
(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.
(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.
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 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+
Created attachment 607147 [details] [diff] [review] Restore GetProcAddress check for t2embed library. r=jtd
Target Milestone: --- → mozilla14
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Version: 11 Branch → Trunk
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.