Bug 691521 - Indeterminism in lcms
Summary: Indeterminism in lcms
Status: RESOLVED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Color (show other bugs)
Version: master
Hardware: PC All
: P1 normal
Assignee: Marcos H. Woehrmann
URL:
Keywords:
: 692145 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-08-03 06:07 UTC by Marcos H. Woehrmann
Modified: 2011-12-09 00:01 UTC (History)
4 users (show)

See Also:
Customer:
Word Size: ---


Attachments
log (17.72 KB, text/plain)
2010-08-03 06:07 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2010-08-03 06:07:52 UTC
Created attachment 6596 [details]
log

I've tracked on of the PDF_1.7_FTS indeterminisms to the lcms code:

==24260== Conditional jump or move depends on uninitialised value(s)
==24260==    at 0x61EE13: CachedXFORM (cmsxform.c:410)
==24260==    by 0x6216C7: cmsDoTransform (cmsxform.c:1670)
==24260==    by 0x5FC700: gscms_transform_color (gsicc_littlecms.c:250)
==24260==    by 0x5F61DE: gx_remap_ICC (gsicc.c:354)
==24260==    by 0x9C3AE5: gx_remap_color (gxcmap.c:552)
==24260==    by 0x9AE8A3: gs_text_begin (gstext.c:262)
==24260==    by 0x9AEA6C: gs_show_begin (gstext.c:311)
==24260==    by 0x54F54A: zshow (zchar.c:58)
==24260==    by 0x51E5D8: call_operator (interp.c:94)
==24260==    by 0x521933: interp (interp.c:1526)
==24260==    by 0x51ED1D: gs_call_interp (interp.c:484)
==24260==    by 0x51EB39: gs_interpret (interp.c:442)
==24260==

(see the attached file for the complete log).

The command line I'm using:

  bin/gs -sDEVICE=pgmraw -r300 -o test.pgm./fts_25_2525.pdf
Comment 1 Marcos H. Woehrmann 2010-10-02 23:48:40 UTC
Created attachment 6776 [details]
screenshot.png

Further information:

The indeterminism occurs on page 3, the text at the top of the screen is a slightly different shade of gray.

If you run only pages 2 and 3 the indeterminism never occurs; the valgrind log fragment in comment #0 represents the difference in valgrind output when pages 1 through 3 are run vs page 2 through 3.
Comment 2 Michael Vrhel 2010-10-03 05:06:54 UTC
Thanks for the analysis. My suspicion is that the data coming into lcms is probably the issue, causing the cache or not the cache value to be used.
Comment 3 Alex Cherepanov 2011-04-19 14:43:08 UTC
*** Bug 692145 has been marked as a duplicate of this bug. ***
Comment 4 Alex Cherepanov 2011-05-03 17:12:18 UTC
Change to P1 following Henry's request on IRC on 2011-05-03.
Comment 5 Henry Stiles 2011-05-03 17:32:34 UTC
temporary reassigning for investigation.
Comment 6 Henry Stiles 2011-05-04 17:17:31 UTC
Looks like a restore is blowing away the device parameter that 
held the filename of the profile.



valgrind --track-origins=yes --db-attach=yes ./gs -dPDFDEBUG -r72 -sDEVICE=pgmraw -o /dev/null ~/tests_private/pdf/PDF_1.7_FTS/fts_25_2525.pdf
==17255== Memcheck, a memory error detector
==17255== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==17255== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==17255== Command: ./gs -dPDFDEBUG -r72 -sDEVICE=pgmraw -o /dev/null /home/henrys/tests_private/pdf/PDF_1.7_FTS/fts_25_2525.pdf
==17255== 
GPL Ghostscript GIT PRERELEASE 9.03 (2011-03-30)
Copyright (C) 2010 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
<<
/Info 1 0 R
/Root 2 0 R
/Size 41 >>
%Resolving: [2 0]
<<
/Pages 3 0 R
/Type /Catalog /Version /1.6 >>
endobj
%Resolving: [3 0]
<<
/Count 3 /Kids [
4 0 R
17 0 R
29 0 R
]
/Type /Pages >>
endobj
%Resolving: [4 0]
<<
/Contents 16 0 R
/Group 7 0 R
/MediaBox [
0 0 612 792 ]
/Parent 3 0 R
/Resources <<
/ExtGState 15 0 R
/Font 6 0 R
/ProcSet [
/PDF /Text /ImageB /ImageC /ImageI ]
/XObject 12 0 R
>>
/Type /Page >>
endobj
%Resolving: [17 0]
<<
/Contents 28 0 R
/Group 19 0 R
/MediaBox [
0 0 612 792 ]
/Parent 3 0 R
/Resources <<
/ExtGState 27 0 R
/Font 18 0 R
/ProcSet [
/PDF /Text /ImageB /ImageC /ImageI ]
/XObject 24 0 R
>>
/Type /Page >>
endobj
%Resolving: [29 0]
<<
/Contents 40 0 R
/Group 31 0 R
/MediaBox [
0 0 612 792 ]
/Parent 3 0 R
/Resources <<
/ExtGState 39 0 R
/Font 30 0 R
/ProcSet [
/PDF /Text /ImageB /ImageC /ImageI ]
/XObject 36 0 R
>>
/Type /Page >>
endobj
%Resolving: [2 0]
%Resolving: [3 0]
%Resolving: [2 0]
%Resolving: [2 0]
%Resolving: [2 0]
%Resolving: [2 0]
%Resolving: [3 0]
Processing pages 1 through 3.
Page 1
%Resolving: [2 0]
%Resolving: [3 0]
%Resolving: [4 0]
%Resolving: [4 0]
%Resolving: [4 0]
%Resolving: [4 0]
%Resolving: [4 0]
%Resolving: [3 0]
%Resolving: [2 0]
%Resolving: [12 0]
<<
/Im1 11 0 R
/Im3 13 0 R
>>
endobj
%Resolving: [11 0]
<<
/BitsPerComponent 16 /ColorSpace 10 0 R
/Height 800 /ImageName /~ps89C7.tmp /Length 3840000 /Name /~ps89C7.tmp /Subtype /Image /Type /XObject /Width 800 >>
stream
%FilePosition: 973
endobj
%Resolving: [13 0]
<<
/Filter /JPXDecode /Height 3200 /Length 8442002 /Name /X /Subtype /Image /Type /XObject /Width 2000 >>
stream
%FilePosition: 3841148
endobj
%Resolving: [15 0]
<<
/G2 14 0 R
>>
endobj
%Resolving: [14 0]
<<
/BM /Luminosity >>
endobj


...


[
/Lab <<
/BlackPoint [
0 0 0 ]
/Range [
-128 127 -128 127 ]
/WhitePoint [
0.964203 1 0.824905 ]
>>
]
endobj
==17255== Invalid read of size 1
==17255==    at 0x4C2AB1E: bcmp (mc_replace_strmem.c:679)
==17255==    by 0x574776: names_ref (iname.c:178)
==17255==    by 0x5209D2: ref_param_write_name_value (iparam.c:325)
==17255==    by 0x520680: ref_param_write_typed (iparam.c:236)
==17255==    by 0x9C43B1: param_write_name (gsparam.c:396)
==17255==    by 0x9A252C: gx_default_get_params (gsdparam.c:128)
==17255==    by 0x9A2228: gs_get_device_or_hw_params (gsdparam.c:59)
==17255==    by 0x5641C8: zget_device_params (zdevice.c:243)
==17255==    by 0x5642AE: zgetdeviceparams (zdevice.c:262)
==17255==    by 0x51BAF4: call_operator (interp.c:94)
==17255==    by 0x51EE4F: interp (interp.c:1526)
==17255==    by 0x51C239: gs_call_interp (interp.c:484)
==17255==  Address 0xb618be4 is 900 bytes inside a block of size 5,504 free'd
==17255==    at 0x4C28101: free (vg_replace_malloc.c:366)
==17255==    by 0x9BBB95: gs_heap_free_object (gsmalloc.c:357)
==17255==    by 0x990ABC: alloc_free_chunk (gsalloc.c:1843)
==17255==    by 0x98CDB5: i_free_all (gsalloc.c:411)
==17255==    by 0x577852: restore_free (isave.c:970)
==17255==    by 0x57736F: restore_space (isave.c:834)
==17255==    by 0x5771A0: alloc_restore_step_in (isave.c:771)
==17255==    by 0x549C17: zrestore (zvmem.c:155)
==17255==    by 0x4FABAB: z2restore (zdevice2.c:319)
==17255==    by 0x51BAF4: call_operator (interp.c:94)
==17255==    by 0x51EE4F: interp (interp.c:1526)
==17255==    by 0x51C239: gs_call_interp (interp.c:484)
==17255== 
==17255== 
==17255== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==17255== starting debugger with cmd: /usr/bin/gdb -nw /proc/1840/fd/1014 1840
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.

...

0x0000000004c2ab1e in _vgrZU_libcZdsoZa_bcmp (s1V=0xa3ea4a4, s2V=0xb618be4, 
    n=33) at mc_replace_strmem.c:679
679	MEMCMP(VG_Z_LIBC_SONAME, bcmp)
(gdb) up
#1  0x0000000000574777 in names_ref (nt=0xa37a3f8, 
    ptr=0xa3ea4a4 "%rom%iccprofiles/default_gray.icc", size=33, 
    pref=0x7feffe7d0, enterflag=0) at ./psi/iname.c:178
178	            !memcmp_inline(ptr, pnstr->string_bytes, size)
(gdb) p pnstr->string_bytes
$1 = (const byte *) 0xb618be4 "%rom%iccprofiles/default_gray.icc"
(gdb)
Comment 7 Henry Stiles 2011-05-10 18:46:11 UTC
The parameter itself is being stored in the device without a copy anywhere, so when the device is freed - the parameter no longer exists.  A copy of the string should be made or another mechanism to implement this should be used.  Last I heard from Michael the latter was in the works so putting this bug on hold.
Comment 8 Henry Stiles 2011-09-01 21:07:42 UTC
I believe this was fixed but I'm assigning back to the reporter as it is possible I'm simply not reproducing it anymore.  Assign it back if it is still broken.
Comment 9 Marcos H. Woehrmann 2011-12-09 00:01:49 UTC
Issue appears to be fixed in current master.