GNOME Bugzilla – Bug 312892
ENOMEM when loading SVG files containing points far off the screen
Last modified: 2008-08-17 17:02:27 UTC
Steps to reproduce: 1. Look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=298225 2. Download attached file http://bugs.debian.org/cgi-bin/bugreport.cgi/d10.svg.gz?bug=298225&msg=5&att=1 3. Try to display it (f.e. with nautilus or rsvg-view) Stack trace: [...] open("d10.svg", O_RDONLY) = 4 fstat64(4, {st_mode=S_IFREG|0644, st_size=6123, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7efe000 read(4, "<?xml version=\"1.0\" encoding=\"UT"..., 8192) = 6123 read(4, "", 4096) = 0 close(4) = 0 munmap(0xb7efe000, 4096) = 0 [...pango + font-config stuff stripped out...] mmap2(NULL, 1635753984, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) brk(0x69912000) = 0x8119000 mmap2(NULL, 1635885056, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) mmap2(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x5579d000 munmap(0x5579d000, 405504) = 0 munmap(0x55900000, 643072) = 0 mprotect(0x55800000, 135168, PROT_READ|PROT_WRITE) = 0 mmap2(NULL, 1635753984, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Other information:
Created attachment 50393 [details] Full strace
Backtrace from GDB: Program received signal SIGSEGV, Segmentation fault.
+ Trace 62290
Thread NaN (LWP 22168)
No duplicates found I was able to reproduce on Gnome jhbuild 2005/08/17 with rsvg-view The process eat up all memory before crashing in a slightly different way (i think it doesn't matter as the problem seems the same). Here's my stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1223920992 (LWP 7820)] art_vpath_add_point (p_vpath=0xbfffd1fc, pn_points=0x28000000, pn_points_max=0x1, code=ART_MOVETO_OPEN, x=201.66959903935759, y=-144954777.65538234) at art_vpath.c:58 58 (*p_vpath)[i].x = x; (gdb) thread apply all bt
+ Trace 62525
Thread 1 (Thread -1223920992 (LWP 7820))
I can't reproduce this with libart 2.3.19, can somebody else confirm?
I can't reproduce it with Nautilus 2.22.3.
Let's close this as OBSOLETE then.