488040 - crashes with colour management on and hardware calibrated monitor profiled using Spectraview II

Status: RESOLVED INVALID

(Core :: Graphics: Color Management, defect)

Description

[kz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)

Bought new LCD monitor Nec P221W with hardware calibration capability (meaning monitor LUT is updated rather than graphics card LUT) using Spectraview II software - I have been using Firefox with colour management turned on and once I started using new monitor, firefox started crashing (growing up in memory to 1.5-2 GB first) with just a few tabs open, usually containing some photos.

Just to be specific - previously I have been using monitor that I was calibrating using colorimeter, but unlike the Nec, profile it created was loaded at system startup and a piece of software was updating graphics adapter LUT (look up table).  Had to turn off colour management which solved the problem hovewer with wide gamut monitor makes viewing photos is a nightmare with no colour management. Pretty standard FF setup with few addons.


Reproducible: Always

Comment 1

[Matthias Versen [:Matti]]

Can you attach the profile ?
The crash should be an OOM crash. How long does it take until FF uses 2GB memory ?

Comment 2

[kz]

Attachment: Nec P221W profile causing FF to crash with cm turned on

Comment 3

[kz]

Profile attached - It can take as little as 2-3 minutes - apparently happens faster when I open a page with lots of photos (like a forum page with lots of photos embedded).

Comment 4

[Dave]

I can confirm that enabling color management with Firefox 3.0.8 causes instability issues.  I too am using a hardware calibrated monitor NEC 2690Wuxi2.  I'd like to help in identifying this issue so please let me know what type of information i can provide you with.

Comment 5

[Dave]

As stated above this is definitely some sort of memory leek.  When Color Management is enabled firefox memory usage will simply continue to grow until it crashes at 2GB.  As soon as this limit is hit the Firefox dumps.

Comment 6

[Dave]

Bug appears to be non applicable for Firefox build 3.1b3.

Comment 7

[kz]

How do I turn color management on in 3.1b3 ? It does not appear to have gfx.color_management.enabled setting in about:config...
Does not appear to be enabled by default either.

Comment 8

[Matthias Versen [:Matti]]

It's enabled by default for only tagged images.
see http://kb.mozillazine.org/Gfx.color_management.enabled

Comment 9

[Dave]

kz, set gfx.color_management.mode from 2 to 1.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

I'm unable to reproduce this problem on trunk. Perhaps it's been fixed with qcms?

Comment 11

[Dave]

This problem was fixed with Firefox 3.1 Beta 3.  Unfortunately color management doesn't even work anymore with Firefox Beta 3.5.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

What do you mean it doesn't work anymore? What doesn't work?

Comment 13

[Dave]

It doesn't work at all.  Colors don't display properly its as though color management is not even enabled.  Whatever happened between 3.1 Beta 3 and 3.5 is not good.

See: http://forums.mozillazine.org/viewtopic.php?f=23&t=1219685
https://bugzilla.mozilla.org/show_bug.cgi?id=492962

I tried on the May 8th Nightly and it was still broken.

Comment 14

[Jeff Muizelaar [:jrmuizel]]

Can you try again with a nightly from last night?

Comment 15

[Dave]

Hes probably using an ICC Version 4 profile.  Whoever decided to move over to a new CMS for firefox has **** off a lot of people.

Comment 16

[Dave]

Oops, thats me. LOL, sticking with 3.1 B3 for now, when I get a chance I'll test the nightly.

Comment 17

[Jeff Muizelaar [:jrmuizel]]

The attached profile appears to be corrupt and should be handled without crashing. If you can still cause a crash when using this profile please reopen the bug.