Bug 607758 - [abrt] crash in ufraw-0.16-2.fc13: cmsEvalMatShaper: Process /usr/bin/ufraw was killed by signal 11 (SIGSEGV)
[abrt] crash in ufraw-0.16-2.fc13: cmsEvalMatShaper: Process /usr/bin/ufraw w...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: lcms (Show other bugs)
15
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Andreas Bierfert
Fedora Extras Quality Assurance
abrt_hash:b83c63bb1d51b234f70e29df630...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-24 14:12 EDT by Paul Finnigan
Modified: 2012-01-17 04:24 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-17 04:24:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Paul Finnigan 2010-06-24 14:12:17 EDT
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
kernel: 2.6.33.5-124.fc13.x86_64
package: ufraw-0.16-2.fc13
rating: 4
reason: Process /usr/bin/ufraw was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Goddard)

comment
-----
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
2.
3.
Comment 1 Paul Finnigan 2010-06-24 14:12:20 EDT
Created attachment 426667 [details]
File: backtrace
Comment 2 Nils Philippsen 2010-06-25 09:43:41 EDT
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
Comment 3 Paul Finnigan 2010-06-26 16:38:01 EDT
Created attachment 427129 [details]
Backtrace of latest fail
Comment 4 Paul Finnigan 2010-06-26 16:40:59 EDT
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.
Comment 5 Paul Finnigan 2010-09-15 11:18:45 EDT
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 11:33:44 EDT
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 11:53:18 EDT
Disregard the previous comment, I should learn to read to the end before I write ;-).
Comment 8 Nils Philippsen 2011-04-04 10:36:34 EDT
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
Comment 9 Paul Finnigan 2011-04-04 18:45:00 EDT
Created attachment 489871 [details]
A failing profile
Comment 10 Paul Finnigan 2011-04-04 18:51:10 EDT
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.
Comment 11 Bug Zapper 2011-06-01 11:40:20 EDT
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
Comment 12 Bug Zapper 2011-06-27 14:53:18 EDT
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 05:35:38 EDT
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
Comment 14 Paul Finnigan 2011-06-28 18:14:45 EDT
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.
Comment 15 Nils Philippsen 2011-06-29 08:04:49 EDT
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 08:11:35 EDT
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 08:21:17 EDT
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.
Comment 18 Nils Philippsen 2011-06-29 09:24:36 EDT
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 19:06:12 EDT
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.
Comment 20 Nicolas Chauvet (kwizart) 2011-09-15 16:11:57 EDT
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
Comment 21 Nils Philippsen 2011-09-16 04:47:48 EDT
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)
Comment 22 Nicolas Chauvet (kwizart) 2011-09-19 15:21:56 EDT
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."
Comment 23 Nicolas Chauvet (kwizart) 2012-01-17 04:24:25 EST
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.