It crashes the other way round too. ie. if you open a PDF followed by a PS.

The upstream bug has a C reproducer that mimics the way gnome-documents uses the relevant Evince API.

Reassigning to evince after talking to KaL in #gnome-hackers on GIMPNet:

10:34 <rishi> KaL: Hey! Evince question.
10:34 <rishi> KaL: Are we doing this wrong:                                     
      https://bugzilla.gnome.org/show_bug.cgi?id=726687 ?
10:37 <KaL> rishi: I don't see anything wrong at a first glance, the trace      
      looks like a threading issue
10:38 <rishi> KaL: Should I reassign?
10:42 <KaL> rishi: let me check, I'm not sure
10:47 <KaL> rishi: ok, reassign it and I'll look at it in detail

Hi,

this is a bug in ghostscript. But there are also 2 problems related to this in lcms2.

1) ghostscript doesn't unregister memory handling functions registered in gscms_create() by cmsPluginTHR():

It worked for me to call "cmsUnregisterPluginsTHR(memory)" in gscms_destroy() from "base/gsicc_lcms2.c" (see the attached patch).
ghostscript's upstream handles this situation by creating/deleting the cmsContext in gscms_create() and gscms_destroy() now.


2) lcms-2.5 doesn't offer the function cmsUnregisterPluginsTHR():

I'm not sure how to solve this without rebase of lcms to 2.6.


3) even if we use lcms-2.6 , it will crash somewhere else:

I looked at this and it seems that setting of default memory handling functions doesn't work well. The attached patch fixes this problem for me.


Regards

Marek

Created attachment 883681 [details]
ghostscript patch

Created attachment 883682 [details]
lcms patch

I'm not sure it's as simple as this. See, for example, bug #977528.

Ah, so lcms-2.6 is meant to fix that bug too, as well as this one.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

(In reply to Ludek Smid from comment #8)
> This request was resolved in Red Hat Enterprise Linux 7.0.

I don't think it was. The ghostscript fix can't go in until the lcms re-base.

The comment above is incorrect. The correct version is bellow.
I'm sorry for any inconvenience.
---------------------------------------------------------------

This request was NOT resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you need
to escalate this bug.

(In reply to Marek Kašík from comment #5)
> Created attachment 883682 [details]
> lcms patch

Where did you get that patch please? Do you have any link to upstream commit, please? Because I can't compile it with this patch applied...
---------------
> Checking Context memory handling ...*** Error in `./.libs/testcms': double free or corruption (out): 0x000000000129c030 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7d023)[0x7f4c406d7023]
../src/.libs/liblcms2.so.2(_cmsSubAllocDestroy+0x30)[0x7f4c40f48f30]
../src/.libs/liblcms2.so.2(cmsDeleteContext+0xae)[0x7f4c40f5762e]
./.libs/testcms[0x4190f6]
./.libs/testcms[0x40c207]
./.libs/testcms[0x405540]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f4c4067bb15]
./.libs/testcms[0x405d4d]
======= Memory map: ========
00400000-00423000 r-xp 00000000 00:26 1649147                            /builddir/build/BUILD/lcms2-2.6/testbed/.libs/testcms
00622000-00623000 r--p 00022000 00:26 1649147                            /builddir/build/BUILD/lcms2-2.6/testbed/.libs/testcms
00623000-00624000 rw-p 00023000 00:26 1649147                            /builddir/build/BUILD/lcms2-2.6/testbed/.libs/testcms
00624000-00627000 rw-p 00000000 00:00 0 
0129b000-01468000 rw-p 00000000 00:00 0                                  [heap]
7f4c3c000000-7f4c3c021000 rw-p 00000000 00:00 0 
7f4c3c021000-7f4c40000000 ---p 00000000 00:00 0 
7f4c40444000-7f4c40459000 r-xp 00000000 00:26 1010602                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f4c40459000-7f4c40658000 ---p 00015000 00:26 1010602                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f4c40658000-7f4c40659000 r--p 00014000 00:26 1010602                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f4c40659000-7f4c4065a000 rw-p 00015000 00:26 1010602                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f4c4065a000-7f4c40810000 r-xp 00000000 00:26 1013936                    /usr/lib64/libc-2.17.so
7f4c40810000-7f4c40a10000 ---p 001b6000 00:26 1013936                    /usr/lib64/libc-2.17.so
7f4c40a10000-7f4c40a14000 r--p 001b6000 00:26 1013936                    /usr/lib64/libc-2.17.so
7f4c40a14000-7f4c40a16000 rw-p 001ba000 00:26 1013936                    /usr/lib64/libc-2.17.so
7f4c40a16000-7f4c40a1b000 rw-p 00000000 00:00 0 
7f4c40a1b000-7f4c40a31000 r-xp 00000000 00:26 1013962                    /usr/lib64/libpthread-2.17.so
7f4c40a31000-7f4c40c31000 ---p 00016000 00:26 1013962                    /usr/lib64/libpthread-2.17.so
7f4c40c31000-7f4c40c32000 r--p 00016000 00:26 1013962                    /usr/lib64/libpthread-2.17.so
7f4c40c32000-7f4c40c33000 rw-p 00017000 00:26 1013962                    /usr/lib64/libpthread-2.17.so
7f4c40c33000-7f4c40c37000 rw-p 00000000 00:00 0 
7f4c40c37000-7f4c40d38000 r-xp 00000000 00:26 1013944                    /usr/lib64/libm-2.17.so
7f4c40d38000-7f4c40f37000 ---p 00101000 00:26 1013944                    /usr/lib64/libm-2.17.so
7f4c40f37000-7f4c40f38000 r--p 00100000 00:26 1013944                    /usr/lib64/libm-2.17.so
7f4c40f38000-7f4c40f39000 rw-p 00101000 00:26 1013944                    /usr/lib64/libm-2.17.so
7f4c40f39000-7f4c40f8e000 r-xp 00000000 00:26 1648892                    /builddir/build/BUILD/lcms2-2.6/src/.libs/liblcms2.so.2.0.6
7f4c40f8e000-7f4c4118d000 ---p 00055000 00:26 1648892                    /builddir/build/BUILD/lcms2-2.6/src/.libs/liblcms2.so.2.0.6
7f4c4118d000-7f4c4118e000 r--p 00054000 00:26 1648892                    /builddir/build/BUILD/lcms2-2.6/src/.libs/liblcms2.so.2.0.6
7f4c4118e000-7f4c41193000 rw-p 00055000 00:26 1648892                    /builddir/build/BUILD/lcms2-2.6/src/.libs/liblcms2.so.2.0.6
7f4c41193000-7f4c411b4000 r-xp 00000000 00:26 1013929                    /usr/lib64/ld-2.17.so
7f4c413a6000-7f4c413aa000 rw-p 00000000 00:00 0 
7f4c413b1000-7f4c413b4000 rw-p 00000000 00:00 0 
7f4c413b4000-7f4c413b5000 r--p 00021000 00:26 1013929                    /usr/lib64/ld-2.17.so
7f4c413b5000-7f4c413b6000 rw-p 00022000 00:26 1013929                    /usr/lib64/ld-2.17.so
7f4c413b6000-7f4c413b7000 rw-p 00000000 00:00 0 
7ffe94cc6000-7ffe94ce7000 rw-p 00000000 00:00 0                          [stack]
7ffe94db7000-7ffe94db9000 r--p 00000000 00:00 0                          [vvar]
7ffe94db9000-7ffe94dbb000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
make[1]: *** [check] Aborted (core dumped)
make[1]: Leaving directory `/builddir/build/BUILD/lcms2-2.6/testbed'
make: *** [check-recursive] Error 1
----------------

OK, so looking at the backtrace in RHEL-7.2, this seems to be like a problem of poppler or other package that is using it, see the backtrace:
---------------
(gdb) backtrace
#0  gs_lcms2_malloc (id=0x0, size=56) at base/gsicc_lcms2.c:48
#1  0x00007f871ab52c3d in _cmsMallocZeroDefaultFn (ContextID=<optimized out>, size=56) at cmserr.c:97
#2  0x00007f871ab53c64 in AllocateToneCurveStruct (ContextID=0x0, nEntries=nEntries@entry=4096, nSegments=nSegments@entry=1, Segments=0x7f86c27fb820, Values=Values@entry=0x0) at cmsgamma.c:231
#3  0x00007f871ab541d0 in cmsBuildSegmentedToneCurve (ContextID=ContextID@entry=0x0, nSegments=nSegments@entry=1, Segments=Segments@entry=0x7f86c27fb820) at cmsgamma.c:649
#4  0x00007f871ab544ae in cmsBuildParametricToneCurve (ContextID=ContextID@entry=0x0, Type=Type@entry=4, Params=Params@entry=0x7f86c27fb8f0) at cmsgamma.c:735
#5  0x00007f871ab71443 in Build_sRGBGamma (ContextID=0x0) at cmsvirt.c:639
#6  cmsCreate_sRGBProfileTHR (ContextID=0x0) at cmsvirt.c:655
#7  0x00007f86c05925ad in GfxColorSpace::setupColorProfiles () at GfxState.cc:440
#8  0x00007f86c059a0a2 in GfxState::GfxState (this=0x7f86b82abe20, hDPIA=<optimized out>, vDPIA=<optimized out>, pageBox=<optimized out>, rotateA=<optimized out>, upsideDown=<optimized out>) at GfxState.cc:6533
#9  0x00007f86c057c414 in Gfx::Gfx (this=0x7f86b81c0100, docA=<optimized out>, outA=<optimized out>, pageNum=1, resDict=0x7f86b81bf4f0, hDPI=72, vDPI=72, box=0x7f86c27fba90, cropBox=0x0, rotate=0, 
    abortCheckCbkA=0x0, abortCheckCbkDataA=0x0, xrefA=0x0) at Gfx.cc:559
#10 0x00007f86c05c3fbe in Page::createGfx (this=0x7f86b82106d0, out=out@entry=0x7f86b81bf2b0, hDPI=hDPI@entry=72, vDPI=vDPI@entry=72, rotate=rotate@entry=0, useMediaBox=useMediaBox@entry=false, crop=false, 
    crop@entry=true, sliceX=sliceX@entry=-1, sliceY=sliceY@entry=-1, sliceW=sliceW@entry=-1, sliceH=sliceH@entry=-1, printing=printing@entry=false, abortCheckCbk=abortCheckCbk@entry=0x0, 
    abortCheckCbkData=abortCheckCbkData@entry=0x0, xrefA=xrefA@entry=0x0) at Page.cc:545
#11 0x00007f86c0a57c67 in poppler_page_get_text_page (page=0x1b46780) at poppler-page.cc:275
#12 0x00007f86c0a59694 in poppler_page_get_selection_region (page=<optimized out>, scale=1, style=<optimized out>, selection=<optimized out>) at poppler-page.cc:665
#13 0x00007f86c0c9358e in pdf_document_text_get_text_mapping (document_text=<optimized out>, page=<optimized out>) at ev-poppler.cc:2194
#14 0x00007f871a57c7e6 in ev_job_page_data_run (job=0x202b1e0) at ev-jobs.c:745
#15 0x00007f871a57e0fa in ev_job_thread (job=0x202b1e0) at ev-job-scheduler.c:184
#16 ev_job_thread_proxy (data=<optimized out>) at ev-job-scheduler.c:217
#17 0x00007f87436e94e5 in g_thread_proxy (data=0x7f86bc0015e0) at gthread.c:764
#18 0x00007f8741c08dc5 in start_thread (arg=0x7f86c27fc700) at pthread_create.c:308
#19 0x00007f87419361cd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

(gdb) print id
$2 = (void *) 0x0
(gdb) print size
$3 = 56
(gdb) print mem
$4 = (gs_memory_t *) 0x0
-----------------

If you look into code of ghostscript (base/gsicc_lcms2.c:43), to function:
> void *gs_lcms2_malloc(cmsContext id, unsigned int size)
it requires a valid 'id'. This 'id' is typecasted to pointer 'mem', and used as parameter for 'gs_alloc_bytes()'.

'gs_alloc_bytes()' is actually this macro (base/gsmemory.h:244):
#define gs_alloc_bytes(mem, nbytes, cname)\
  (*(mem)->procs.alloc_bytes)(mem, nbytes, cname)
    gs_memory_proc_alloc_bytes((*alloc_bytes));

You can see that 'mem' is being dereferenced here, but since it's a NULL pointer, then it's natural it will receive SIGSEGV.

->> The case above is taken when I was opening the 2nd document in 'gnome-documents'.

In normal case (when I was opening the 1st document in 'gnome-documents'), the 'id' (and therefore 'mem') had a valid address. That resulted in call to 'gs_heap_alloc_bytes()' (base/gsmalloc.c:159).

Looking at the backtrace, this might be problem of:
- lcms2 (which calls ghostscript)
- poppler (which calls lcms2)
- evince
- gjs

I have tried upgrading the lcms2 to the latest upstream version, and the problem was still persisting. Therefore, I think this is a problem of one of the rest of packages using lcms2. Switching this to poppler, since it's next in the backtrace.

(In reply to David Kaspar [Dee'Kej] from comment #14)
> I have tried upgrading the lcms2 to the latest upstream version, and the
> problem was still persisting. Therefore, I think this is a problem of one of
> the rest of packages using lcms2. Switching this to poppler, since it's next
> in the backtrace.

I have to scratch this part. This *IS* actually a problem of ghostscript...

LCMS2 is part of the ghostscript in upstream repository (as well as some other packages we ship), and it is all developed as a whole suite. However, due to some licensing problems, we ship them separately.

For RHEL-7.2, we have shipped a rebase of LCMS2 to version 2.6, to fix some of the important issues. However, there's a second part that needed to be done on ghostscript side, so the integration is correct. Due to miscommunication the necessary patch has not been released for ghostscript.

Here is the upstream commit that integrated LCMS2 2.6 into ghostscipt:
http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=cdde0e961884a0dbe7

It is a really huge commit with lots of changes. Most of these changes are intended for LCMS2 integration. I have extracted the rest of these changes related to ghostscript and sucessfully tested them.

I will post the patch here for review tomorrow.

Comment on attachment 883682 [details]
lcms patch

Unfortunately, none of these patches fixes the issue, Marek.

Created attachment 1161392 [details]
extracted patch from upstream

This is the patch I have extracted from upstream commit [link in comment #15].

My initial testing on RHEL-7.2 (with LCMS2 2.6 installed) stops crashing of gnome-documents when I open documents (pdf, dvi, ps) several times in random order.

*** Bug 1280458 has been marked as a duplicate of this bug. ***

Comment on attachment 1161392 [details]
extracted patch from upstream

Hi,

the patch looks good to me. I would maybe swap these two lines but it depends on whether there can be concurrent access to the gs_memory_t structure from another thread:

+    cmsDeleteContext(ctx);
+    gs_lib_ctx_set_cms_context(memory, NULL);

And I would also remove the addition of "$(gp_h)" to the base/lib.mak since it seems unnecessary.

(In reply to Marek Kašík from comment #20)
> Comment on attachment 1161392 [details]
> extracted patch from upstream
> I would maybe swap these two lines but it
> depends on whether there can be concurrent access to the gs_memory_t
> structure from another thread:

Well, I was looking at later commits, and there seems to be no commits related to this. And for me, the order of these lines makes quite sense. In other words, I expect the concurrent access in LCMS2 is fixed (as described in release notes), and I don't want to sway away from upstream. 

> And I would also remove the addition of "$(gp_h)" to the base/lib.mak since
> it seems unnecessary.

This is true, the $(gp_h) seems unnecessary. However, I would like to keep in here anyway, in case we backport some other commits in future that might require it. Just to make future maintenance more easier.

Anyway, thank you for your review and comments! ;)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2550.html