Bug 607758

Created attachment 426667 [details]
File: backtrace

Please check whether this issue still persists with the current testing update:

https://admin.fedoraproject.org/updates/ufraw-0.17-1.fc13,lensfun-0.2.5-1.fc13

Created attachment 427129 [details]
Backtrace of latest fail

Nils

Sorry this has taken some time. Ufraw is now working better, fails are much more infrequent. I have not had a NEF RAW file that cannot be opened on the second go. I always get three error messages that require responses, not a major issue.

I have attached a backtrace of the latest fail.

I have found the problem! I use gnome color manager and a colour profile that is not capable of whole screen colour correction! This is because my monitor blew up and I got a new one ASAP, it came without an icc profile. 

I have since acquired a better profile and now I get no messages. 

The problem is of course not resolved. The messages should not appear, or at least they should warn of the incompatibility of the profile. The problem can be reproduced by selecting one of the standard sRGB profiles available.

Can you also attach such a bad profile? If I can reproduce the crash it's much easier to debug. Thanks.

Disregard the previous comment, I should learn to read to the end before I write ;-).

Can you reproduce this with the update, that's in the queue currently? It's in updates-testing currently, but waiting to be pushed to stable:

https://admin.fedoraproject.org/updates/ufraw-0.18-2.fc13

Created attachment 489871 [details]
A failing profile

Nils,

I am using Fedora 14 now so I have used ufraw-0.18-2.fc14, I guess this makes little difference.

Most profiles appear to work. The problem is much reduced. I found one that still fails, it is a manufacturers profile I used on a machine once but not my own. But it could be passed upstream to help eradicate the problem. I have attached it to this problem.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Just for the record, I couldn't reproduce crashes on F-15 with these versions and the profile attached above:

ufraw-0.18-2.fc15.x86_64
lcms-1.19-4.fc15.x86_64

I still get the messages with the above attached profile on Fedora 15. 

ufraw-0.18-2.fc15.x86_64
lcms2-2.2-1.fc15.x86_64
gnome-color-manager-3.0.0-3.fc15.x86_64

Note the different lcms setup. I don't know if this makes too much difference but I still get the messages.

What is the result of the following command on your machine?

rpm -q --whatprovides $(rpm -q --requires ufraw | grep lcms)

Hmm, now I could reproduce it now with the attached profile. Anyway, ufraw uses lcms-1.x, not lcms2.

Crashes at line 1108 in cmsgmt.c:

1103	              
1104	
1105	    // Do nothing on all but Gray/RGB to Gray/RGB transforms
1106	
1107	    if (((InputXForm ->EntryColorSpace != icSigRgbData) && (InputXForm ->EntryColorSpace != icSigGrayData)) || 
1108	        ((OutputXForm->ExitColorSpace  != icSigRgbData) && (OutputXForm->ExitColorSpace  != icSigGrayData))) return;
1109	    
1110	
1111	    for (t = 0; t < Grid -> InputChan; t++) 
1112	            Trans[t] = cmsAllocGamma(PRELINEARIZATION_POINTS);

The issue here is that OutputXForm is NULL.

The submitted transforms array which contains the NULL transform is created a stack frame above, in cmsCreateMultiprofileTransform(). The function cmsCreateTransform() is called in some places without checking its result (i.e. that it doesn't return NULL) which is then put in the array.

This might be related to the "Bad tag signature '348' found." error messages that one gets when loading this profile. This message could come from one of 8 different places in cmsio1.c, I've taken a look at the first instance of these and found some instances where error conditions aren't checked: ReadCurve() <- ReadSetOfCurves() <- ReadLUT_A2B() or ReadLUT_B2A() <- cmsReadICCLut() -- The missing error checks in this one case are in ReadLUT_A2B() and ReadLUT_B2A() which call ReadSetOfCurves() without checking the result for success or error.

Changing component to lcms for further examination.

Nils

You asked for the lcms dependency:

#rpm -q --whatprovides $(rpm -q --requires ufraw | grep lcms)
lcms-libs-1.19-4.fc15.x86_64

Just in case it helps. In F15 I get several messages when using this bad profile:

Bad tag signature '348' found.

Tag '62545243' not found

unable to smelt shaper-matrix, required tags missing


When I alter to another simple profile (that I do not use) I get just the last message. When I use a correct profile, generated by GnomeColor I get no messages at all.

The report was forwarded to the lcms-users mailing list:
http://sourceforge.net/mailarchive/forum.php?forum_name=lcms-user&max_rows=25&style=nested&viewmonth=201109

kwizart,

lcms upstream seems to assume that the issue is related to ufraw's use of threading. I don't think that's the case here, because I can reproduce the same crash every time I do the following:

- Start ufraw
- Load raw image file
- Switch to attached (damaged) profile 917.icm

This is the backtrace I get, it crashes (again, every time) at line 1108 in cmsgmt.c (with OutputXForm being NULL):

(gdb) bt
#0  _cmsComputePrelinearizationTablesFromXFORM (h=0x7ffffff9ae90, nTransforms=
    3, Grid=0xd32cb0) at cmsgmt.c:1108
#1  0x00000039acc1f9d3 in cmsCreateMultiprofileTransform (
    hProfiles=<optimized out>, nProfiles=<optimized out>, 
    dwInput=<optimized out>, dwOutput=<optimized out>, Intent=0, dwFlags=0)
    at cmsxform.c:1964
#2  0x0000000000418af2 in developer_create_transform (d=0x7fffea9b6010, mode=
    display_developer) at ufraw_developer.c:367
#3  0x0000000000419b2a in developer_create_transform (mode=<optimized out>, 
    d=<optimized out>) at ufraw_developer.c:325
#4  developer_prepare (d=0x7fffea9b6010, conf=0xb34050, 
    rgbMax=<optimized out>, rgb_cam=<optimized out>, colors=<optimized out>, 
    useMatrix=<optimized out>, mode=display_developer) at ufraw_developer.c:613
#5  0x0000000000413323 in ufraw_developer_prepare (uf=0x9aac30, mode=
    display_developer) at ufraw_ufraw.c:764
#6  0x000000000044b703 in render_preview_now (data=<optimized out>)
    at ufraw_preview.c:941
#7  render_preview_now (data=0x7ffffffdbba0) at ufraw_preview.c:886
#8  0x0000003c7a01eac6 in gdk_threads_dispatch (data=0xe0ca80) at gdk.c:512
#9  0x00000039a14427ed in g_main_dispatch (context=0x931400) at gmain.c:2441
#10 g_main_context_dispatch (context=0x931400) at gmain.c:3014
#11 0x00000039a1442fc8 in g_main_context_iterate (context=0x931400, 
    block=<optimized out>, dispatch=1, self=<optimized out>) at gmain.c:3092
---Type <return> to continue, or q <return> to quit---
#12 0x00000039a144360d in g_main_loop_run (loop=0xd12040) at gmain.c:3300
#13 0x0000003c7994c007 in IA__gtk_main () at gtkmain.c:1256
#14 0x000000000044f41f in ufraw_preview (uf=0x9aac30, rc=<optimized out>, 
    plugin=0, save_func=<optimized out>) at ufraw_preview.c:5838
#15 0x000000000045166f in ufraw_chooser (rc=0x7ffffffdd5a0, conf=
    0x7fffffff3260, cmd=0x7ffffffe8400, defPath=<optimized out>)
    at ufraw_chooser.c:156
#16 0x000000000040e9bc in main (argc=1, argv=0x7fffffffe1d8) at ufraw.c:93
(gdb) l
1103	              
1104	
1105	    // Do nothing on all but Gray/RGB to Gray/RGB transforms
1106	
1107	    if (((InputXForm ->EntryColorSpace != icSigRgbData) && (InputXForm ->EntryColorSpace != icSigGrayData)) || 
1108	        ((OutputXForm->ExitColorSpace  != icSigRgbData) && (OutputXForm->ExitColorSpace  != icSigGrayData))) return;
1109	    
1110	
1111	    for (t = 0; t < Grid -> InputChan; t++) 
1112	            Trans[t] = cmsAllocGamma(PRELINEARIZATION_POINTS);
(gdb) display InputXForm
1: InputXForm = (_LPcmsTRANSFORM) 0xd34b00
(gdb) display OutputXForm
2: OutputXForm = (struct _cmstransform_struct *) 0x0
(gdb)

My understanding is that lcms1 is legacy and despite they agree that it's not as fault tolerant as lcms2, they will not fix it. Instead, they expect every lcms1 applications to catch the error.
Quoting:
"The solution is to fix the error handler if you are using lcms1, or
-better- upgrade to lcms2 and check the return codes."

Application catching this bug should be moved to lcms2.
Workaround is described above.