453933 - Crash in [@ start_pass_fdctmgr]

Status: RESOLVED DUPLICATE of bug 410509

(Core :: Graphics: ImageLib, defect)

Description

[Brad Jackson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.3pre) Gecko/2008082721 Firefox/3.0.3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080905220507 Firefox/3.1b1pre

My local Firefox 3.1 builds from Mercurial randomly and intermittently crash when loading a page. Crash is unrelated to TraceMonkey being enabled.

Reproducible: Sometimes

Steps to Reproduce:
1. Load a few pages at random
2. Firefox seg faults and is not caught by Breakpad
3.
Actual Results:  
Unpredictable seg fault

Expected Results:  
Should not crash

Comment 1

[Brad Jackson]

Attachment: Stacktrace

Comment 2

[Matthias Versen [:Matti]]

What are your buildflags ?
(about:buildconfig)

Breakpad doesn't work if you compile yourself because the symbols must be on the breakpad server and that means that only binary builds from Mozilla.org are working with breakpad.

Comment 3

[Brad Jackson]

Attachment: My buildconfig

This probably makes no difference, but this is not quite what I normally used for 3.0 builds. After switching from CVS to Mercurial, I got compiler errors with jemalloc on and got linker errors with dbus on, so I temporarily disabled those options to get a working build. I am not sure if those are known problems. I haven't submitted bug reports or searched for bugs on those build errors.

If no one can reproduce this crash, I can try simpler GCC optimization flags to see if it's a GCC-related bug.

Comment 4

[Brad Jackson]

I've noticed that this crash either never or rarely happens if I keep only one tab open. Most of the time when I middle click a link to open a new tab in the background, it will crash.

Also, when prompted to restore the tabs I had open after launching Firefox again, it always crashes unless I tell it to start a new session.

Comment 5

[timeless]

fwiw, info locals or poking the variables listed on the crashing line are appreciated

79         fdct->divisors[qtblno] = (DCTELEM *)
80           (*cinfo->mem->alloc_small) ((j_common_ptr) cinfo, JPOOL_IMAGE,
81                                       DCTSIZE2 * SIZEOF(DCTELEM));

for this blob, the things to inspect are probably:
fdct
fdct->divisors
fdct->divisors[qtblno] 
cinfo
cinfo->mem
cinfo->mem->alloc_small
*cinfo->mem->alloc_small

Comment 6

[Brad Jackson]

If you need something better than this, you will have to give me specific gdb commands to run since I'm not an expert.

(gdb) info locals
fdct = (my_fdct_ptr) 0xbfd0e020
ci = 1
qtblno = 0
i = 3
compptr = (jpeg_component_info *) 0x2000
cinfo = (j_compress_ptr) 0xbfd0e020

(gdb) print fdct->divisors
$1 = {0xa2590e0, 0x0, 0x64, 0xbfd0dfc8}
(gdb) print fdct->divisors[qtblno]
$2 = (DCTELEM *) 0xa2590e0
(gdb) print cinfo
$3 = (j_compress_ptr) 0xbfd0e020
(gdb) print cinfo->mem
$4 = (struct jpeg_memory_mgr *) 0xa256680
(gdb) print cinfo->mem->alloc_small
$5 = (void *(*)()) 0x8a98c9c <alloc_small>
(gdb) print *cinfo->mem->alloc_small
$6 = {void *()} 0x8a98c9c <alloc_small>

Comment 7

[Brad Jackson]

Since I can't reproduce this bug on the nightly trunk builds, I decided to experiment with the GCC options I'm using. I narrowed it down to -ftree-vectorize that causes the crash. This is an option that is part of -O3 flags in the latest GCC versions. I normally run -O2 plus options from -O3 that don't inline functions or unroll loops.

I can't tell if this is a GCC bug, or a Firefox bug that is only visible with that compile option. Not sure what to do with the resolution of this bug.

Comment 8

[timeless]

i think this is the right bug. as far as i'm concerned, gcc is the buggy app here, we'll probably do something about it though...