1) Open file picker by using File->Open, Save, or attaching files to webpages. 2) Select a jpeg file 3) Firefox crashed. The stack is like this, current thread: t@1 =>[1] jpeg_save_markers(0x80424d0, 0xe1, 0xffff), at 0xc2ce0e4f [2] gdk_pixbuf__jpeg_image_load(0xd1dbbe30, 0x0), at 0xc3a31f27 [3] _gdk_pixbuf_generic_image_load(0xcbd5b060, 0xd1dbbe30, 0x0), at 0xcd3c8501 [4] gdk_pixbuf_new_from_file(0xc3c18da0, 0x0, 0x8043e04, 0xd0eb167e), at 0xcd3c876a [5] UpdateFilePreviewWidget(0xca81f8d8, 0xc3e57298), at 0xd0eb16b6 I think the root cause is the extern functions of jpeg lib in our libxul.so get messed up with system /usr/lib/libjpeg.so Compile Firefox with system libjpeg or rename/hide these functions should fix it. This bug is critical to Firefox 3 Solaris build. With this bug, the user will not be able to submit/open a jpeg file.

Building firefox with --with-system-jpeg can fix it. I'll add this option to Solaris builds. But should we do something like bug 328082 for jpeg?

what's the status here? there are any benchmarks: firefox-jpeg vs system-jpeg ? here b3.3 it's extremly slow to open an big (~4megs) jpeg

It is fixed by bug 440714. It is safe to build firefox without --with-system-jpeg now. I didn't do any performance comparison between firefox-jpeg vs system-jpeg. I guess it is not a problem, since the codes are almost same. Linux distro also uses system-jpeg.