Closed Bug 459617 Opened 13 years ago Closed 13 years ago

color management reftest failing in Ubuntu


(Core :: GFX: Color Management, defect)

Not set





(Reporter: zadkiel.m, Unassigned)




(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b1pre) Gecko/20080929132416 Minefield/3.1b1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b1pre) Gecko/20080929132416 Minefield/3.1b1pre

Firefox rendered from images color profiles are not passing reftests in Ubuntu. 
Firefox renders comes from purposely failing a reftest to get at the URI data Firefox uses to do tests with. 

Reproducible: Always

Steps to Reproduce:
do steps 1-5 on mac/win (to isolate the Ubuntu)
step 6 is done on the Ubuntu and compares the 
firefox rendered reftests(on the mac/win)
and the image with the profile.

1. get an image
2. apply a .icc colour profile to it.
3. write and run a reftest that fails on purpose
	-the output of the failed test includes a URI of the image that
	 firefox renders(which is a forced sRGB during tests)
4. take the uri data and paste it in the address bar of firefox
5. save and crop the uri image 
6. write and run another reftest that compares the image 
   with the profile from step 2 and the saved and cropped image in step 5

Actual Results:  
Isolated 2 pixels with profiles and redid the test and they both failed 
Pixel with profile Adobe 1998
with Adobe Profile 8ca39b = firefox render 82a49c fails on the Ubuntu
with Adobe Profile 6f8753 = firefox render 63884f fails on the Ubuntu

Expected Results:  
The reftest should pass when done on any platform.
Blocks: 455056
What is the ubuntu rendering for the two problem pixels? ie - is it an off-by-one issue, or something else?
I managed to replicate it on Fedora 8 and Ubuntu. It's off-by-one on the red channel I think.
Component: General → GFX: Color Management
Product: Firefox → Core
QA Contact: general → color-management
Version: unspecified → Trunk
Update since most of this has been being discussed over email:

Zad managed to determine that the problem is that the linux machines he's using are using the fixed point path rather than the optimized sse2 floating point path, and these two paths occasionally differ (the second part is a known and unfixable issue).

Upon further inspection, it seems like a preprocessor issue. The two macros tested are __GNUC__ and __i386__, and it seems that on Zad's linux machines __i386__ is not defined.

Zad, what version of GCC are you using? Vlad, any idea if there's a more appropriate #ifdef to use?
gcc version 4.0.1 (Apple Inc. build 5490)

gcc version 4.3.1 (Ubuntu 4.3.2-1ubuntu11)
You're on x86-64, if the user agent in the initial comment is correct.  i386 != x86-64, so __i386__ won't be defined.  If the code really is compatible with x86_64 (that is, it's SSE2 etc and not MMX), then you can also check for __x86_64__ and __amd64__.
Zad - want to give vlad's suggestion a try?
You can also do a sanity check by building a 32-bit Firefox on your 64-bit system:
yah gonna giv'r.
changed line
it hangs up.

lookin' into the 32-bit on the 64-bit on the ubuntu 
not givn'r
you definitely want GNUC no matter what, and then within that you want an OR of all the possible architectures.

so you want
#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__) || defined(__amd64__))
it is crashing

gdb: bt ouput
Is there maybe another place where you also have to allow x86-64?  Could grep for __i386__ and see what's conditional on that.
can you post your "hg diff" to make sure that nothing else is being modified?
sure thing
Oh right, there's a bug for this. Marking it as blocking us. I'll ping that bug and see what the status is.
Depends on: 456028
tested it on the i686 linux and it passes.
tested the patch on an x86-64
and it passes
tested again with the nightly and it passed
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.