Closed Bug 363905 Opened 18 years ago Closed 18 years ago

svg Hilbert curve crashes Firefox

Categories

(Core :: SVG, defect)

1.8 Branch
x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 307254

People

(Reporter: db48x, Assigned: stanshebs)

References

()

Details

Attachments

(1 file)

shebs is paying a dollar to the first person to file a crasher involving an svg fractal, so here's my entry. It's a simple innocuous little Hilbert curve. Firefox ought to be able to handle it easily, it doesn't even involve any sub-pixel rendering or anything like that.

This is a trunk build from 20061208, I'll update to a newer one later on tonight.

I'll attach the actual file that causes the crash, the url points to a directory with a perl script for generating the fractal, and a number of pregenerated fractals of various depths.
Attached image testcase
Stacktrace, from a trunk build that just finished:

(gdb) bt
#0  0x00000037db7097e6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1  0x00002aaaab552ddf in PR_WaitCondVar (cvar=0x2aaab78da280, timeout=4294967295) at /home/db48x/moz/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:405
#2  0x00002aaaab552edf in PR_Wait (mon=0x2aaab78da2d0, timeout=4294967295) at /home/db48x/moz/mozilla/nsprpub/pr/src/pthreads/ptsynch.c:584
#3  0x00002aaaab174e3f in nsAutoMonitor::Wait (this=Variable "this" is not available.
) at /home/db48x/moz/mozilla/xpcom/threads/nsAutoLock.h:322
#4  0x00002aaaab197e5a in nsEventQueue::GetEvent (this=0x2aaab78da178, mayWait=1, result=0x45007020) at /home/db48x/moz/mozilla/xpcom/threads/nsEventQueue.cpp:76
#5  0x00002aaaab19a5fd in nsThread::nsChainedEventQueue::GetEvent (this=Variable "this" is not available.
) at /home/db48x/moz/mozilla/xpcom/threads/nsThread.h:109
#6  0x00002aaaab198fed in nsThread::ProcessNextEvent (this=0x2aaab78da130, mayWait=1, result=0x4500709c) at /home/db48x/moz/mozilla/xpcom/threads/nsThread.cpp:473
#7  0x00002aaaab147027 in NS_ProcessNextEvent_P (thread=Variable "thread" is not available.
) at nsThreadUtils.cpp:225
#8  0x00002aaaab1997ff in nsThread::ThreadFunc (arg=Variable "arg" is not available.
) at /home/db48x/moz/mozilla/xpcom/threads/nsThread.cpp:251
#9  0x00002aaaab5594e5 in _pt_root (arg=Variable "arg" is not available.
) at /home/db48x/moz/mozilla/nsprpub/pr/src/pthreads/ptthread.c:220
#10 0x00000037db706325 in start_thread () from /lib64/libpthread.so.0
#11 0x00000037da6cbbad in clone () from /lib64/libc.so.6
#12 0x0000000000000000 in ?? ()
Excellent! I want this one, call it part of my Mozducation. I note that FF2 on Mac copes with even the depth-10 set, albeit very slowly.
Assignee: general → stanshebs
Cool. I'm uploading rank 11 and 12 fractals, but that's as high as I'm going to bother for now. Rank 12 took well over a minute to generate (probably more like 3 minutes, but I didn't time it), and is 280 megs. Have fun :)
Oh, btw. I calculated that the svg file for a rank 24 Hilbert curve would be about 1536 TB, and would take 25 years to generate. I'd have to add another 500GB hard drive to my computer ever 2.75 days to cope. Yow!
oh, 10, 11 and 12 are now smaller than they were. I had typoed and they had lots of floating point numbers in them. Eww!
On linux this testcase will cause mozilla to abort with an X error because the number of trapezoids generated (117963) is too many for XRenderCompositeTrapezoids to deal with.  It is supposed to break it into batches for the server, but that doesn't seem to work.

#0  0x49156be4 in _exit () from /lib/libc.so.6
#1  0x490f4905 in exit () from /lib/libc.so.6
#2  0x464368d4 in gdk_pointer_grab () from /usr/lib/libgdk-x11-2.0.so.0
#3  0x49293f4d in _XIOError () from /usr/lib/libX11.so.6
#4  0x49294dbe in _XRead () from /usr/lib/libX11.so.6
#5  0x4929520b in _XEatData () from /usr/lib/libX11.so.6
#6  0x492955a3 in _XSend () from /usr/lib/libX11.so.6
#7  0x494b6fa6 in XRenderCompositeTrapezoids () from /usr/lib/libXrender.so.1
#8  0x4009be60 in _cairo_xlib_surface_composite_trapezoids (
    op=CAIRO_OPERATOR_OVER, pattern=0xbf88f7ac, abstract_dst=0xa2fa300, 
    antialias=CAIRO_ANTIALIAS_DEFAULT, src_x=1, src_y=25, dst_x=1, dst_y=25, 
    width=840, height=841, traps=0x47066008, num_traps=117963)
    at /home/tor/moz/trunk/mozilla/gfx/cairo/cairo/src/cairo-xlib-surface.c:1639
...
Trunk build on the Mac is slow (50 sec to render rank 10), but no crashing, so it's likely Linux/X11-specific. My new Linux machine is expected in a couple weeks (I don't think my old laptop from 1999 will cut it for Moz-building these days!), will come back to this bug then.
I think it was confirmed on windows as well, though if so I must have forgotten to mark it.
WFM on Windows.

*** This bug has been marked as a duplicate of 307254 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: