Last Comment Bug 322345 - strange crash in svg scale transform (int overflow?)
: strange crash in svg scale transform (int overflow?)
Status: VERIFIED FIXED
[sg:critical?]
: crash, verified1.8.0.9, verified1.8.1.1
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-04 06:10 PST by georgi - hopefully not receiving bugspam
Modified: 2008-12-26 13:13 PST (History)
5 users (show)
dveditz: blocking1.8.1.1+
dveditz: blocking1.8.0.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (269 bytes, text/xml)
2006-01-04 06:13 PST, georgi - hopefully not receiving bugspam
no flags Details
modified testcase, crashes trunk 2006-10-24 (721 bytes, text/xml)
2006-10-24 07:36 PDT, georgi - hopefully not receiving bugspam
no flags Details
cairo patch (1.02 KB, patch)
2006-11-23 15:09 PST, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
vladimir: review+
dveditz: approval1.8.0.9+
dveditz: approval1.8.1.1+
Details | Diff | Splinter Review

Description georgi - hopefully not receiving bugspam 2006-01-04 06:10:17 PST
strange crash in svg scale transform (int overflow?)

there is a strange svg crash, may be due to integer overflow.
the following crashes in memset on linux:

<text font-size="20" transform="scale(16385,16385)">
feck</text>

testcase to follow.

both 1.5 and trunk crash.
Comment 1 georgi - hopefully not receiving bugspam 2006-01-04 06:13:19 PST
Created attachment 207490 [details]
testcase
Comment 2 Daniel Veditz [:dveditz] 2006-02-03 13:47:21 PST
roc, can you look at this?
Comment 3 georgi - hopefully not receiving bugspam 2006-04-13 08:09:08 PDT
may be a duplicate of Bug 333861 which works from html on trunk only.
Comment 4 georgi - hopefully not receiving bugspam 2006-08-23 01:00:38 PDT
this seems fixed on trunk, but both branches crash badly in memset
Comment 5 Daniel Veditz [:dveditz] 2006-09-19 15:52:22 PDT
Restoring lost blocking flag
Comment 6 georgi - hopefully not receiving bugspam 2006-10-24 07:35:00 PDT
this still crashes 1.5-latest and 2.0-latest.

a modification of it crashes trunk-latest with a scary stack in memset(3).
macosx and wine seem unaffected.
Comment 7 georgi - hopefully not receiving bugspam 2006-10-24 07:36:06 PDT
Created attachment 243351 [details]
modified testcase, crashes trunk 2006-10-24
Comment 8 tor 2006-10-24 11:02:00 PDT
Doesn't crash either win32 or linux trunk here.
Comment 9 georgi - hopefully not receiving bugspam 2006-10-25 06:07:18 PDT
bclary may have linux boxen for testing.

bclary: do you crash on linux trunk with the second attachment and on linux branches with the first one?
Comment 10 Bob Clary [:bc:] 2006-10-25 09:21:06 PDT
ff1508 tb25023894 attachment 207490 [details]
ff2    tb25023736 attachment 207490 [details]
ff3    tb25024064 attachment 243351 [details]
Comment 11 Daniel Veditz [:dveditz] 2006-11-01 10:49:32 PST
Memory crashes scare us, can we investigate and get some kind of fix in? The fact that it's linux-only may hint that the bug is in the linux libraries that are out of our direct control. And maybe it doesn't happen to tor because he's using different libraries?

Can we track this down and file bugs against our upstreams if necessary?
Comment 12 georgi - hopefully not receiving bugspam 2006-11-02 01:17:34 PST
imho it may be a library outside mozilla, something linux specific in
mozilla or combination of both.

suggest spamming upstream cairo or libfreetype.

here is a valgrind log - seems to stop ealrlier than ff with gdb.

valgrind on debug trunk.

** nsSVGTextFrame::DidSetStyleContext
==26277== 
==26277== Invalid write of size 1
==26277==    at 0x4020173: memset (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==26277==    by 0x49C828D: (within /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x49C5F34: (within /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x49C7202: (within /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x4989D30: FT_Outline_Render (in /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x614ED8B: ???
==26277==    by 0x1D1C8: ???
==26277==  Address 0xBC21F27 is not stack'd, malloc'd or (recently) free'd
==26277== 
==26277== Invalid write of size 1
==26277==    at 0x4020179: memset (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==26277==    by 0x49C828D: (within /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x49C5F34: (within /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x49C7202: (within /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x4989D30: FT_Outline_Render (in /usr/lib/libfreetype.so.6.3.10)
==26277==    by 0x614ED8B: ???
==26277==    by 0x1D1C8: ???
==26277==  Address 0xBC21F29 is not stack'd, malloc'd or (recently) free'd

valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 624497, hi = 2728567458.
Probably caused by overrunning/underrunning a heap block's bounds.

==26277==    at 0x380133A2: (within /usr/lib/valgrind/x86-linux/memcheck)
==26277==    by 0x380135DE: (within /usr/lib/valgrind/x86-linux/memcheck)
==26277==    by 0x3801AF3F: (within /usr/lib/valgrind/x86-linux/memcheck)
==26277==    by 0x3802DA19: (within /usr/lib/valgrind/x86-linux/memcheck)
==26277==    by 0x38001D0A: (within /usr/lib/valgrind/x86-linux/memcheck)
==26277==    by 0x3802E01B: (within /usr/lib/valgrind/x86-linux/memcheck)
==26277==    by 0x3802F498: (within /usr/lib/valgrind/x86-linux/memcheck)
==26277==    by 0x38043D79: (within /usr/lib/valgrind/x86-linux/memcheck)

sched status:
  running_tid=1
Thread 1: status = VgTs_Runnable
==26277==    at 0x401E65C: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==26277==    by 0x40E98FA: _get_bitmap_surface (cairo-ft-font.c:812)
==26277==    by 0x40E9E8E: _render_glyph_outline (cairo-ft-font.c:1017)
==26277==    by 0x40EB8CE: _cairo_ft_scaled_glyph_init (cairo-ft-font.c:1906)
==26277==    by 0x40CBE4D: _cairo_scaled_glyph_lookup (cairo-scaled-font.c:1381)
==26277==    by 0x40E7DD2: _cairo_xlib_surface_show_glyphs (cairo-xlib-surface.c:2810)
==26277==    by 0x40CF6D7: _cairo_surface_show_glyphs (cairo-surface.c:1830)
==26277==    by 0x40BC160: _cairo_gstate_show_glyphs (cairo-gstate.c:1504)
==26277==    by 0x40B5E26: _moz_cairo_show_text (cairo.c:2662)
==26277==    by 0x7D02E06: nsSVGGlyphFrame::LoopCharacters(_cairo*, nsAString_internal const&, nsSVGGlyphFrame::nsSVGCharacterPosition const*, void (*)(_cairo*, char const*)) (nsSVGGlyphFrame.cpp:203)
==26277==    by 0x7D0610B: nsSVGGlyphFrame::PaintSVG(nsISVGRendererCanvas*, nsRect*) (nsSVGGlyphFrame.cpp:286)
==26277==    by 0x7D25338: nsSVGUtils::PaintChildWithEffects(nsISVGRendererCanvas*, nsRect*, nsIFrame*) (nsSVGUtils.cpp:697)
==26277==    by 0x7CFA336: nsSVGDisplayContainerFrame::PaintSVG(nsISVGRendererCanvas*, nsRect*) (nsSVGContainerFrame.cpp:199)
==26277==    by 0x7D25338: nsSVGUtils::PaintChildWithEffects(nsISVGRendererCanvas*, nsRect*, nsIFrame*) (nsSVGUtils.cpp:697)
==26277==    by 0x7D138FE: nsSVGOuterSVGFrame::Paint(nsIRenderingContext&, nsRect const&, nsPoint) (nsSVGOuterSVGFrame.cpp:519)
==26277==    by 0x7D139E1: nsDisplaySVG::Paint(nsDisplayListBuilder*, nsIRenderingContext*, nsRect const&) (nsSVGOuterSVGFrame.cpp:419)
==26277==    by 0x76C8482: nsDisplayList::Paint(nsDisplayListBuilder*, nsIRenderingContext*, nsRect const&) const (nsDisplayList.cpp:298)
==26277==    by 0x76C8720: nsDisplayWrapList::Paint(nsDisplayListBuilder*, nsIRenderingContext*, nsRect const&) (nsDisplayList.cpp:706)
==26277==    by 0x76C9653: nsDisplayClip::Paint(nsDisplayListBuilder*, nsIRenderingContext*, nsRect const&) (nsDisplayList.cpp:938)
==26277==    by 0x76C8482: nsDisplayList::Paint(nsDisplayListBuilder*, nsIRenderingContext*, nsRect const&) const (nsDisplayList.cpp:298)
==26277==    by 0x76F1FA2: nsLayoutUtils::PaintFrame(nsIRenderingContext*, nsIFrame*, nsRegion const&, unsigned) (nsLayoutUtils.cpp:719)
==26277==    by 0x770348A: PresShell::Paint(nsIView*, nsIRenderingContext*, nsRegion const&) (nsPresShell.cpp:5652)
==26277==    by 0x7BA6F88: nsViewManager::RenderViews(nsView*, nsIRenderingContext&, nsRegion const&, nsIDrawingSurface*) (nsViewManager.cpp:815)
==26277==    by 0x7BA7CF9: nsViewManager::Refresh(nsView*, nsIRenderingContext*, nsIRegion*, unsigned) (nsViewManager.cpp:578)
==26277==    by 0x7BA83BC: nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) (nsViewManager.cpp:1423)
==26277==    by 0x7B9D524: HandleEvent(nsGUIEvent*) (nsView.cpp:171)
==26277==    by 0x661400A: nsCommonWidget::DispatchEvent(nsGUIEvent*, nsEventStatus&) (nsCommonWidget.cpp:216)
==26277==    by 0x660749F: nsWindow::OnExposeEvent(_GtkWidget*, _GdkEventExpose*) (nsWindow.cpp:1635)
==26277==    by 0x66078F9: expose_event_cb(_GtkWidget*, _GdkEventExpose*) (nsWindow.cpp:4118)
==26277==    by 0x44C918B: (within /usr/lib/libgtk-x11-2.0.so.0.1000.3)
==26277==    by 0x48A42BA: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.3)
==26277==    by 0x48B58ED: (within /usr/lib/libgobject-2.0.so.0.1200.3)
==26277==    by 0x48B6BC3: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.3)
==26277==    by 0x48B6F9A: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1200.3)
==26277==    by 0x45E0610: (within /usr/lib/libgtk-x11-2.0.so.0.1000.3)
==26277==    by 0x44C3627: gtk_main_do_event (in /usr/lib/libgtk-x11-2.0.so.0.1000.3)
==26277==    by 0x4769884: (within /usr/lib/libgdk-x11-2.0.so.0.1000.3)
==26277==    by 0x4769ABB: gdk_window_process_all_updates (in /usr/lib/libgdk-x11-2.0.so.0.1000.3)
==26277==    by 0x4769B31: (within /usr/lib/libgdk-x11-2.0.so.0.1000.3)
==26277==    by 0x49033DF: (within /usr/lib/libglib-2.0.so.0.1200.3)
==26277==    by 0x49051B4: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1200.3)
==26277==    by 0x49081D1: (within /usr/lib/libglib-2.0.so.0.1200.3)
==26277==    by 0x490870B: g_main_context_iteration (in /usr/lib/libglib-2.0.so.0.1200.3)
==26277==    by 0x6611340: nsAppShell::ProcessNextNativeEvent(int) (nsAppShell.cpp:144)
...snip other threads seem sane...


valgrind on 2.0-latest:
** nsSVGTextFrame::DidSetStyleContext
SVG Viewport=(0?,0?,994,000061,846,000061)
SVG Viewbox=(1,000000,1,000000,48746356,000000,3,000000)
SVG Viewbox->Viewport xform [a c e] = [0,000020,   0, -0,000020]
                            [b d f] = [   0,  0,000020, 422,999969]
==2866== 
==2866== Invalid write of size 1
==2866==    at 0x4020173: memset (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==2866==    by 0x4CB728D: (within /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x4CB4F34: (within /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x4CB6202: (within /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x4C78D30: FT_Outline_Render (in /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x9420543: ???
==2866==    by 0x1D1C8: ???
==2866==  Address 0xC8F0F27 is not stack'd, malloc'd or (recently) free'd
==2866== 
==2866== Invalid write of size 1
==2866==    at 0x4020179: memset (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==2866==    by 0x4CB728D: (within /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x4CB4F34: (within /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x4CB6202: (within /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x4C78D30: FT_Outline_Render (in /usr/lib/libfreetype.so.6.3.10)
==2866==    by 0x9420543: ???
==2866==    by 0x1D1C8: ???
==2866==  Address 0xC8F0F29 is not stack'd, malloc'd or (recently) free'd

valgrind: m_mallocfree.c:194 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 760177, hi = 2728567458.
Probably caused by overrunning/underrunning a heap block's bounds.

==2866==    at 0x380133A2: (within /usr/lib/valgrind/x86-linux/memcheck)
==2866==    by 0x380135DE: (within /usr/lib/valgrind/x86-linux/memcheck)
==2866==    by 0x3801AF3F: (within /usr/lib/valgrind/x86-linux/memcheck)
==2866==    by 0x3802DA19: (within /usr/lib/valgrind/x86-linux/memcheck)
==2866==    by 0x38001D0A: (within /usr/lib/valgrind/x86-linux/memcheck)
==2866==    by 0x3802E01B: (within /usr/lib/valgrind/x86-linux/memcheck)
==2866==    by 0x3802F498: (within /usr/lib/valgrind/x86-linux/memcheck)
==2866==    by 0x38043D79: (within /usr/lib/valgrind/x86-linux/memcheck)
sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==2866==    at 0x401E65C: calloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==2866==    by 0x4770329: (within /usr/lib/libcairo.so.2.9.2)
==2866==    by 0x4772B44: (within /usr/lib/libcairo.so.2.9.2)
==2866==    by 0x4762D9B: (within /usr/lib/libcairo.so.2.9.2)
==2866==    by 0x4781F12: (within /usr/lib/libcairo.so.2.9.2)
==2866==    by 0x47665B9: (within /usr/lib/libcairo.so.2.9.2)
==2866==    by 0x475A39C: (within /usr/lib/libcairo.so.2.9.2)
==2866==    by 0x4755B2E: cairo_show_text (in /usr/lib/libcairo.so.2.9.2)
==2866==    by 0x74F5515: nsSVGGlyphFrame::PaintSVG(nsISVGRendererCanvas*, nsRect const&) (nsSVGGlyphFrame.cpp:462)
==2866==    by 0x751FFDF: nsSVGTextFrame::PaintSVG(nsISVGRendererCanvas*, nsRect const&) (nsSVGTextFrame.cpp:543)
==2866==    by 0x750D018: nsSVGOuterSVGFrame::Paint(nsPresContext*, nsIRenderingContext&, nsRect const&, nsFramePaintLayer, unsigned) (nsSVGOuterSVGFrame.cpp:849)
==2866==    by 0x6FFCB0A: nsContainerFrame::PaintChild(nsPresContext*, nsIRenderingContext&, nsRect const&, nsIFrame*, nsFramePaintLayer, unsigned) (nsContainerFrame.cpp:282)
==2866==    by 0x6FFA40A: nsContainerFrame::PaintChildren(nsPresContext*, nsIRenderingContext&, nsRect const&, nsFramePaintLayer, unsigned) (nsContainerFrame.cpp:227)
==2866==    by 0x7026D8E: nsHTMLContainerFrame::Paint(nsPresContext*, nsIRenderingContext&, nsRect const&, nsFramePaintLayer, unsigned) (nsHTMLContainerFrame.cpp:83)
==2866==    by 0x7027913: CanvasFrame::Paint(nsPresContext*, nsIRenderingContext&, nsRect const&, nsFramePaintLayer, unsigned) (nsHTMLFrame.cpp:383)
==2866==    by 0x6FBDB1D: PresShell::Paint(nsIView*, nsIRenderingContext&, nsRect const&) (nsPresShell.cpp:5866)
==2866==    by 0x73CB843: nsView::Paint(nsIRenderingContext&, nsRect const&, unsigned, int&) (nsView.cpp:314)
==2866==    by 0x73CFE43: nsViewManager::RenderDisplayListElement(DisplayListElement2*, nsIRenderingContext*) (nsViewManager.cpp:1458)
==2866==    by 0x73D7AA6: nsViewManager::RenderViews(nsView*, nsIRenderingContext&, nsRegion const&, nsIDrawingSurface*, nsVoidArray const&) (nsViewManager.cpp:1373)
==2866==    by 0x73D8DD0: nsViewManager::Refresh(nsView*, nsIRenderingContext*, nsIRegion*, unsigned) (nsViewManager.cpp:929)
==2866==    by 0x73D95A9: nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus*) (nsViewManager.cpp:2045)
==2866==    by 0x73CB56C: HandleEvent(nsGUIEvent*) (nsView.cpp:171)
==2866==    by 0x5DEB870: nsCommonWidget::DispatchEvent(nsGUIEvent*, nsEventStatus&) (nsCommonWidget.cpp:219)
==2866==    by 0x5DE14D7: nsWindow::OnExposeEvent(_GtkWidget*, _GdkEventExpose*) (nsWindow.cpp:1433)
==2866==    by 0x5DE154D: expose_event_cb(_GtkWidget*, _GdkEventExpose*) (nsWindow.cpp:3729)
==2866==    by 0x43EC18B: (within /usr/lib/libgtk-x11-2.0.so.0.1000.3)
==2866==    by 0x47C42BA: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1200.3)
==2866==    by 0x47D58ED: (within /usr/lib/libgobject-2.0.so.0.1200.3)
==2866==    by 0x47D6BC3: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1200.3)
==2866==    by 0x47D6F9A: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1200.3)
==2866==    by 0x4503610: (within /usr/lib/libgtk-x11-2.0.so.0.1000.3)
==2866==    by 0x43E6627: gtk_main_do_event (in /usr/lib/libgtk-x11-2.0.so.0.1000.3)
==2866==    by 0x4671884: (within /usr/lib/libgdk-x11-2.0.so.0.1000.3)
==2866==    by 0x4671ABB: gdk_window_process_all_updates (in /usr/lib/libgdk-x11-2.0.so.0.1000.3)
==2866==    by 0x4671B31: (within /usr/lib/libgdk-x11-2.0.so.0.1000.3)
==2866==    by 0x48273DF: (within /usr/lib/libglib-2.0.so.0.1200.3)
==2866==    by 0x48291B4: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1200.3)
==2866==    by 0x482C1D1: (within /usr/lib/libglib-2.0.so.0.1200.3)
==2866==    by 0x482C543: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1200.3)
==2866==    by 0x43E699E: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1000.3)
==2866==    by 0x5DE8E5F: nsAppShell::Run() (nsAppShell.cpp:139)
==2866==    by 0x5FB5531: nsAppStartup::Run() (nsAppStartup.cpp:151)
==2866==    by 0x8052483: XRE_main (nsAppRunner.cpp:2438)
==2866==    by 0x804B42B: main (nsBrowserApp.cpp:61)

Comment 13 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-22 19:08:32 PST
My FF2 branch build does not crash. It dies in a cairo assert.

However, my build seems to be using the system cairo (1.2.4), not the Mozilla-tree cairo.
Comment 14 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-22 20:01:38 PST
I suspect this is something specific to particular freetype/cairo versions and how they deal with oversized characters.
Comment 15 georgi - hopefully not receiving bugspam 2006-11-23 02:57:53 PST
according to tests:

mandriva 2007 - both trunk and ff2: crash
kubuntu 6.10 - no crash, but X or KDE are quite lagged (not big memory usage)

suggest spamming upstream cairo/libfreetype.

doubt that the testcases may be minimized more.
Comment 16 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-23 14:09:00 PST
I'm pretty sure this is a freetype bug where it crashes instead of returning an error. I would guess that this is an integer overflow that got fixed in the 2.2.1 release in May:
https://sourceforge.net/project/shownotes.php?release_id=416463&group_id=3157

Georgi, is that consistent with the freetype versions in your tests?
Comment 17 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-23 15:09:46 PST
Created attachment 246437 [details] [diff] [review]
cairo patch

I've this patch upstream to work around the cairo abort when Freetype returns an error --- it just caps the font size at 1000 pixels in each direction. I think we should probably take this on our branch to protect against bad Freetype packages. (Although it won't help if our tree-cairo gets overridden by a system cairo, as I seem to be seeing.)
Comment 18 georgi - hopefully not receiving bugspam 2006-11-24 00:34:38 PST
(In reply to comment #16)
> I'm pretty sure this is a freetype bug where it crashes instead of returning an
> error. I would guess that this is an integer overflow that got fixed in the
> 2.2.1 release in May:
> https://sourceforge.net/project/shownotes.php?release_id=416463&group_id=3157
> 
> Georgi, is that consistent with the freetype versions in your tests?
> 

i am not sure 2.2.1 is safe:
mandriva 2007 (crashing)   : libfreetype6-2.2.1-4
ubuntu 6.0.6 (crashing)    : libfreetype6-2.1.10
ubuntu 6.10 (non crashing) : libfreetype6-2.2.1-5

fuzzing the testcase when non crashing doesn't crash, but enter *very big* loops (about 10 minutes and still running).




Comment 19 georgi - hopefully not receiving bugspam 2006-11-24 01:56:29 PST
mac ppc is safe from this.

about the cairo patch:
+#define MAX_FONT_SIZE 1000

+        double x_scale = sf.x_scale;
+        double y_scale = sf.y_scale;
+        if (x_scale > MAX_FONT_SIZE) {
+            x_scale = MAX_FONT_SIZE;

not sure if this is effective for *negative* x_scale.
Comment 20 Vladimir Vukicevic [:vlad] [:vladv] 2006-11-27 16:20:54 PST
Comment on attachment 246437 [details] [diff] [review]
cairo patch

The way sf.[xy]_scale is computed (through _cairo_matrix_compute_scale_factors), they can't be negative as far as I can see.
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-29 12:19:57 PST
Checked into trunk.
Comment 22 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-29 12:21:00 PST
Comment on attachment 246437 [details] [diff] [review]
cairo patch

okay, this can go on branches now. I think it's pretty darn safe!
Comment 23 Daniel Veditz [:dveditz] 2006-11-29 12:35:40 PST
Comment on attachment 246437 [details] [diff] [review]
cairo patch

approved for 1.8/1.8.0 branches, a=dveditz for drivers
Comment 24 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2006-11-29 18:11:40 PST
fixed on branches
Comment 25 Bob Clary [:bc:] 2006-12-06 12:01:43 PST
verified fixed 1.8.0.9, 1.8.1.1, 1.9 windows/linux/macppc
no crashes on either attached testcase.

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