Bug 607758 - [abrt] crash in ufraw-0.16-2.fc13: cmsEvalMatShaper: Process /usr/bin/ufraw was killed by signal 11 (SIGSEGV)
Summary: [abrt] crash in ufraw-0.16-2.fc13: cmsEvalMatShaper: Process /usr/bin/ufraw w...
Alias: None
Product: Fedora
Classification: Fedora
Component: lcms
Version: 15
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Andreas Bierfert
QA Contact: Fedora Extras Quality Assurance
Whiteboard: abrt_hash:b83c63bb1d51b234f70e29df630...
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-24 18:12 UTC by Paul Finnigan
Modified: 2012-01-17 09:24 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2012-01-17 09:24:25 UTC

Attachments (Terms of Use)
File: backtrace (74.00 KB, text/plain)
2010-06-24 18:12 UTC, Paul Finnigan
no flags Details
Backtrace of latest fail (40.58 KB, text/plain)
2010-06-26 20:38 UTC, Paul Finnigan
no flags Details
A failing profile (1.64 KB, application/vnd.iccprofile)
2011-04-04 22:45 UTC, Paul Finnigan
no flags Details

Description Paul Finnigan 2010-06-24 18:12:17 UTC
abrt 1.1.1 detected a crash.

architecture: x86_64
Attached file: backtrace
cmdline: ufraw '/home/paul/Pictures/D700/2010-06-19 Jedburgh/DSC_2009.NEF'
component: ufraw
crash_function: cmsEvalMatShaper
executable: /usr/bin/ufraw
global_uuid: b83c63bb1d51b234f70e29df6306d29cfa3189dd
package: ufraw-0.16-2.fc13
rating: 4
reason: Process /usr/bin/ufraw was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Goddard)

All I am doing is opening a Nikon RAW file. I have tried many and they all exhibit similar problems. In most cases the ufraw window opens followed by a message:

Bad tag signature '348' found

flashing and then everything crashes. SOmetimes this message stays up waiting for the OK button to be pressed, when this happens this message is repeated followed by one about a missing profile. I cannot get this to repeat (I have tired LOTS of RAW files to no avail).

How to reproduce
1. Open any Nikon Raw file (.NEF) with Ufraw

Comment 1 Paul Finnigan 2010-06-24 18:12:20 UTC
Created attachment 426667 [details]
File: backtrace

Comment 2 Nils Philippsen 2010-06-25 13:43:41 UTC
Please check whether this issue still persists with the current testing update:


Comment 3 Paul Finnigan 2010-06-26 20:38:01 UTC
Created attachment 427129 [details]
Backtrace of latest fail

Comment 4 Paul Finnigan 2010-06-26 20:40:59 UTC

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.

Comment 5 Paul Finnigan 2010-09-15 15:18:45 UTC
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.

Comment 6 Nils Philippsen 2010-09-16 15:33:44 UTC
Can you also attach such a bad profile? If I can reproduce the crash it's much easier to debug. Thanks.

Comment 7 Nils Philippsen 2010-09-16 15:53:18 UTC
Disregard the previous comment, I should learn to read to the end before I write ;-).

Comment 8 Nils Philippsen 2011-04-04 14:36:34 UTC
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:


Comment 9 Paul Finnigan 2011-04-04 22:45:00 UTC
Created attachment 489871 [details]
A failing profile

Comment 10 Paul Finnigan 2011-04-04 22:51:10 UTC

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.

Comment 11 Bug Zapper 2011-06-01 15:40:20 UTC
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: 

Comment 12 Bug Zapper 2011-06-27 18:53:18 UTC
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.

Comment 13 Nils Philippsen 2011-06-28 09:35:38 UTC
Just for the record, I couldn't reproduce crashes on F-15 with these versions and the profile attached above:


Comment 14 Paul Finnigan 2011-06-28 22:14:45 UTC
I still get the messages with the above attached profile on Fedora 15. 


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

Comment 15 Nils Philippsen 2011-06-29 12:04:49 UTC
What is the result of the following command on your machine?

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

Comment 16 Nils Philippsen 2011-06-29 12:11:35 UTC
Hmm, now I could reproduce it now with the attached profile. Anyway, ufraw uses lcms-1.x, not lcms2.

Comment 17 Nils Philippsen 2011-06-29 12:21:17 UTC
Crashes at line 1108 in cmsgmt.c:

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

The issue here is that OutputXForm is NULL.

Comment 18 Nils Philippsen 2011-06-29 13:24:36 UTC
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.

Comment 19 Paul Finnigan 2011-06-29 23:06:12 UTC

You asked for the lcms dependency:

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

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.

Comment 20 Nicolas Chauvet (kwizart) 2011-09-15 20:11:57 UTC
The report was forwarded to the lcms-users mailing list:

Comment 21 Nils Philippsen 2011-09-16 08:47:48 UTC

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
1105	    // Do nothing on all but Gray/RGB to Gray/RGB transforms
1107	    if (((InputXForm ->EntryColorSpace != icSigRgbData) && (InputXForm ->EntryColorSpace != icSigGrayData)) || 
1108	        ((OutputXForm->ExitColorSpace  != icSigRgbData) && (OutputXForm->ExitColorSpace  != icSigGrayData))) return;
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

Comment 22 Nicolas Chauvet (kwizart) 2011-09-19 19:21:56 UTC
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.
"The solution is to fix the error handler if you are using lcms1, or
-better- upgrade to lcms2 and check the return codes."

Comment 23 Nicolas Chauvet (kwizart) 2012-01-17 09:24:25 UTC
Application catching this bug should be moved to lcms2.
Workaround is described above.

Note You need to log in before you can comment on or make changes to this bug.