Bug 414541 - cantor git master and maxima 5.43 crash
Summary: cantor git master and maxima 5.43 crash
Status: RESOLVED FIXED
Alias: None
Product: cantor
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR crash
Target Milestone: ---
Assignee: Alexander Semke
URL:
Keywords: drkonqi
Depends on:
Blocks:
 
Reported: 2019-11-26 15:52 UTC by nijso
Modified: 2020-09-17 02:20 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
New crash information added by DrKonqi (8.45 KB, text/plain)
2020-09-17 02:20 UTC, superwaitsum
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nijso 2019-11-26 15:52:56 UTC
Application: cantor (20.03.70)

Qt Version: 5.9.7
Frameworks Version: 5.55.0
Operating System: Linux 4.12.14-lp151.28.32-default x86_64
Distribution: "openSUSE Leap 15.1"

-- Information about the crash:
- What I was doing when the application crashed:

just installed cantor from git (master) and installed maxima 5.43.0 from sourceforge
started cantor from the command line in kde (opensuse)

evaluating any maxima command will result in a crash for my system setup
This does not happen with cantor 18.12.3-lp151.2.1, which is the current release of my opensuse distribution.

The crash can be reproduced every time.

-- Backtrace:
Application: Cantor (cantor), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f87dda17140 (LWP 22179))]

Thread 4 (Thread 0x7f87a7e4b700 (LWP 22184)):
#0  0x00007f87ce39cff0 in g_mutex_unlock () from /usr/lib64/libglib-2.0.so.0
#1  0x00007f87ce3566fc in g_main_context_prepare () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f87ce3570db in ?? () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f87ce3572bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#4  0x00007f87d65ef96b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#5  0x00007f87d659490a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#6  0x00007f87d63b2daa in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#7  0x00007f87d63b7ced in ?? () from /usr/lib64/libQt5Core.so.5
#8  0x00007f87d3540569 in start_thread () from /lib64/libpthread.so.0
#9  0x00007f87d57649ef in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f87bb114700 (LWP 22181)):
#0  0x00007f87ce39cff4 in g_mutex_unlock () from /usr/lib64/libglib-2.0.so.0
#1  0x00007f87ce3572c6 in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f87d65ef96b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#3  0x00007f87d659490a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#4  0x00007f87d63b2daa in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#5  0x00007f87d80d89e5 in ?? () from /usr/lib64/libQt5DBus.so.5
#6  0x00007f87d63b7ced in ?? () from /usr/lib64/libQt5Core.so.5
#7  0x00007f87d3540569 in start_thread () from /lib64/libpthread.so.0
#8  0x00007f87d57649ef in clone () from /lib64/libc.so.6

Thread 2 (Thread 0x7f87c32cd700 (LWP 22180)):
#0  0x00007f87d575a19b in poll () from /lib64/libc.so.6
#1  0x00007f87cbc0c307 in ?? () from /usr/lib64/libxcb.so.1
#2  0x00007f87cbc0df3a in xcb_wait_for_event () from /usr/lib64/libxcb.so.1
#3  0x00007f87c5c0e939 in ?? () from /usr/lib64/libQt5XcbQpa.so.5
#4  0x00007f87d63b7ced in ?? () from /usr/lib64/libQt5Core.so.5
#5  0x00007f87d3540569 in start_thread () from /lib64/libpthread.so.0
#6  0x00007f87d57649ef in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f87dda17140 (LWP 22179)):
[KCrash Handler]
#6  0x00007f87d570e5b3 in __memmove_sse2_unaligned_erms () from /lib64/libc.so.6
#7  0x00007f87d3c29a04 in cmsOpenIOhandlerFromMem () from /usr/lib64/liblcms2.so.2
#8  0x00007f87d3c2b245 in cmsOpenProfileFromMemTHR () from /usr/lib64/liblcms2.so.2
#9  0x00007f87d249d2f5 in gsicc_set_device_profile () from /usr/lib64/libgs.so.9
#10 0x00007f87d249da22 in gsicc_init_device_profile_struct () from /usr/lib64/libgs.so.9
#11 0x00007f87d26b697c in gs_setdevice_no_erase () from /usr/lib64/libgs.so.9
#12 0x00007f87d27ae43c in zsetdevice () from /usr/lib64/libgs.so.9
#13 0x00007f87d2783278 in ?? () from /usr/lib64/libgs.so.9
#14 0x00007f87d2783523 in gs_interpret () from /usr/lib64/libgs.so.9
#15 0x00007f87d27766cc in ?? () from /usr/lib64/libgs.so.9
#16 0x00007f87d2776b90 in gs_main_init2aux () from /usr/lib64/libgs.so.9
#17 0x00007f87d2777152 in gs_main_init2 () from /usr/lib64/libgs.so.9
#18 0x00007f87d2779e6e in gs_main_init_with_args () from /usr/lib64/libgs.so.9
#19 0x00007f87dc27084c in spectre_gs_run () from /usr/lib64/libspectre.so.1
#20 0x00007f87dc27143e in spectre_device_render () from /usr/lib64/libspectre.so.1
#21 0x00007f87dc271db3 in spectre_page_render () from /usr/lib64/libspectre.so.1
#22 0x00007f87dc26fc3f in spectre_document_render_full () from /usr/lib64/libspectre.so.1
#23 0x00007f87dd629626 in Cantor::Renderer::epsRenderToImage (url=..., scale=1, useHighRes=false, size=0x7ffc6627bb10, errorReason=0x0) at /home/nijso/mathematics/cantor/src/lib/renderer.cpp:153
#24 0x00007f87dd62a07f in Cantor::Renderer::renderToImage (this=0x1401f10, url=..., method=Cantor::Renderer::EPS, size=0x7ffc6627bb10) at /home/nijso/mathematics/cantor/src/lib/renderer.cpp:237
#25 0x00007f87dd6290e8 in Cantor::Renderer::renderToResource (this=0x1401f10, document=0x1a62840, method=Cantor::Renderer::EPS, url=..., internal=...) at /home/nijso/mathematics/cantor/src/lib/renderer.cpp:107
#26 0x00007f87dd628cb9 in Cantor::Renderer::render (this=0x1401f10, document=0x1a62840, method=Cantor::Renderer::EPS, url=..., uuid=...) at /home/nijso/mathematics/cantor/src/lib/renderer.cpp:79
#27 0x00007f87a935f35b in TextResultItem::setLatex (this=0x1a99820, result=0x1aa98d0) at /home/nijso/mathematics/cantor/src/textresultitem.cpp:160
#28 0x00007f87a935eef0 in TextResultItem::update (this=0x1a99820) at /home/nijso/mathematics/cantor/src/textresultitem.cpp:124
#29 0x00007f87a935e28b in TextResultItem::TextResultItem (this=0x1a99820, parent=0x10c3260, result=0x1aa98d0) at /home/nijso/mathematics/cantor/src/textresultitem.cpp:43
#30 0x00007f87a935dbc4 in ResultItem::create (parent=0x10c3260, result=0x1aa98d0) at /home/nijso/mathematics/cantor/src/resultitem.cpp:56
#31 0x00007f87a932b12d in CommandEntry::updateEntry (this=0x10c3260) at /home/nijso/mathematics/cantor/src/commandentry.cpp:744
#32 0x00007f87a9333ad6 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (CommandEntry::*)()>::call(void (CommandEntry::*)(), CommandEntry*, void**) (f=&virtual table offset 264, o=0x10c3260, arg=0x7ffc6627c080) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:136
#33 0x00007f87a93335ec in QtPrivate::FunctionPointer<void (CommandEntry::*)()>::call<QtPrivate::List<>, void>(void (CommandEntry::*)(), CommandEntry*, void**) (f=&virtual table offset 264, o=0x10c3260, arg=0x7ffc6627c080) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:169
#34 0x00007f87a93324f7 in QtPrivate::QSlotObject<void (CommandEntry::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x1aac1f0, r=0x10c3260, a=0x7ffc6627c080, ret=0x0) at /usr/include/qt5/QtCore/qobject_impl.h:120
#35 0x00007f87d65c564f in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5
#36 0x00007f87dd64949d in Cantor::Expression::gotResult (this=0x1a20890) at /home/nijso/mathematics/cantor/build/src/lib/cantorlibs_autogen/EWIEGA46WW/moc_expression.cpp:205
#37 0x00007f87dd616d84 in Cantor::Expression::addResult (this=0x1a20890, result=0x1aa98d0) at /home/nijso/mathematics/cantor/src/lib/expression.cpp:155
#38 0x00007f87dd6175a7 in Cantor::Expression::latexRendered (this=0x1a20890, renderer=0x1a99290, result=0x1a45c00) at /home/nijso/mathematics/cantor/src/lib/expression.cpp:245
#39 0x00007f87dd61707c in Cantor::Expression::<lambda()>::operator()(void) const (__closure=0x1abe430) at /home/nijso/mathematics/cantor/src/lib/expression.cpp:228
#40 0x00007f87dd617fd8 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, Cantor::Expression::renderResultAsLatex(Cantor::Result*)::<lambda()> >::call(Cantor::Expression::<lambda()> &, void **) (f=..., arg=0x7ffc6627c4b0) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:130
#41 0x00007f87dd617f8f in QtPrivate::Functor<Cantor::Expression::renderResultAsLatex(Cantor::Result*)::<lambda()>, 0>::call<QtPrivate::List<>, void>(Cantor::Expression::<lambda()> &, void *, void **) (f=..., arg=0x7ffc6627c4b0) at /usr/include/qt5/QtCore/qobjectdefs_impl.h:240
#42 0x00007f87dd617ed7 in QtPrivate::QFunctorSlotObject<Cantor::Expression::renderResultAsLatex(Cantor::Result*)::<lambda()>, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=1, this_=0x1abe420, r=0x1a99290, a=0x7ffc6627c4b0, ret=0x0) at /usr/include/qt5/QtCore/qobject_impl.h:168
#43 0x00007f87d65c564f in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5
#44 0x00007f87dd64b4e5 in Cantor::LatexRenderer::done (this=0x1a99290) at /home/nijso/mathematics/cantor/build/src/lib/cantorlibs_autogen/EWIEGA46WW/moc_latexrenderer.cpp:169
#45 0x00007f87dd6275f7 in Cantor::LatexRenderer::convertingDone (this=0x1a99290) at /home/nijso/mathematics/cantor/src/lib/latexrenderer.cpp:305
#46 0x00007f87dd64b2bb in Cantor::LatexRenderer::qt_static_metacall (_o=0x1a99290, _c=QMetaObject::InvokeMetaMethod, _id=7, _a=0x7ffc6627c7d0) at /home/nijso/mathematics/cantor/build/src/lib/cantorlibs_autogen/EWIEGA46WW/moc_latexrenderer.cpp:108
#47 0x00007f87d65c5535 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5
#48 0x00007f87d6510daf in QProcess::finished(int, QProcess::ExitStatus) () from /usr/lib64/libQt5Core.so.5
#49 0x00007f87d6517bd7 in ?? () from /usr/lib64/libQt5Core.so.5
#50 0x00007f87d6517cf9 in ?? () from /usr/lib64/libQt5Core.so.5
#51 0x00007f87d65c5535 in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib64/libQt5Core.so.5
#52 0x00007f87d65d1a98 in QSocketNotifier::activated(int, QSocketNotifier::QPrivateSignal) () from /usr/lib64/libQt5Core.so.5
#53 0x00007f87d65d1e62 in QSocketNotifier::event(QEvent*) () from /usr/lib64/libQt5Core.so.5
#54 0x00007f87d73403dc in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#55 0x00007f87d7347ca4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQt5Widgets.so.5
#56 0x00007f87d65968d8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib64/libQt5Core.so.5
#57 0x00007f87d65f05ad in ?? () from /usr/lib64/libQt5Core.so.5
#58 0x00007f87ce356e87 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#59 0x00007f87ce357230 in ?? () from /usr/lib64/libglib-2.0.so.0
#60 0x00007f87ce3572bc in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#61 0x00007f87d65ef94f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#62 0x00007f87d659490a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQt5Core.so.5
#63 0x00007f87d659d9b4 in QCoreApplication::exec() () from /usr/lib64/libQt5Core.so.5
#64 0x000000000040f852 in main (argc=1, argv=0x7ffc6627d728) at /home/nijso/mathematics/cantor/src/main.cpp:154
[Inferior 1 (process 22179) detached]

Reported using DrKonqi
Comment 1 Nikita Sirgienko 2019-11-26 22:27:18 UTC
I have tried Maxima 5.43, cantor (master) on Ubuntu 18.12 - all works fine.
I will test this combination on openSuse, but I am already see, that you have some problems with latex typesetting (so you can disable this via option "Enable LaTeX typesetting" in Cantor settings, if you want).
Comment 2 nijso 2019-11-26 22:46:09 UTC
That's interesting, deactivating latex typesetting prevents it from crashing. 
Just tried cantor 19.08.3 with/without latex typesetting and that seems to work fine.
Comment 3 Alexander Semke 2019-11-27 21:15:36 UTC
(In reply to nijso from comment #2)
> That's interesting, deactivating latex typesetting prevents it from
> crashing. 
> Just tried cantor 19.08.3 with/without latex typesetting and that seems to
> work fine.
The crash happens in libspectre. This library is used to convert the EPS file produced by LaTeX to an image that is shown in Cantor's worksheet. So, deactivating LaTeX typesetting clearly avoids this problem, but you don't have any nicely rendered formulas anymore.

Which version of libspectre is used on your system?

Do you have maybe another installation of Cantor on the system in parallel? Like 19.08 and you installed in addition the current version from master? If yes, can you remove everything first and the try to compile/install the master again?
Comment 4 nijso 2019-11-27 22:51:55 UTC
Hi, I have the most recent version of libspectre, 0.2.8. I re-compiled libspectre and cantor and it still crashes, also for the previous cantor version 19.08 (I thought that one worked, but unfortunately it doesn't work either. I tried cantor 18.04 but that one crashes when I load it). 

I could improve the debugging information for the libspectre part:


#18 0x00007f112c9fe68c in spectre_gs_run (gs=gs@entry=0x282f2e0, n_args=<optimized out>, args=args@entry=0x2bbe880) at spectre-gs.c:201
#19 0x00007f112c9ff21e in spectre_device_render (device=device@entry=0x289fc00, page=0, rc=rc@entry=0x2bc3460, x=x@entry=0, y=y@entry=0, width=13, height=16, page_data=0x7ffdf9334950, row_length=0x7ffdf933494c) at spectre-device.c:366
#20 0x00007f112c9ffb55 in spectre_page_render (page=page@entry=0x28230d0, rc=rc@entry=0x2bc3460, page_data=page_data@entry=0x7ffdf9334950, row_length=row_length@entry=0x7ffdf933494c) at spectre-page.c:164
#21 0x00007f112c9fdb2f in spectre_document_render_full (document=0x2833030, rc=0x2bc3460, page_data=0x7ffdf9334950, row_length=0x7ffdf933494c) at spectre-document.c:351
#22 0x00007f112ddb7636 in Cantor::Renderer::epsRenderToImage (url=..., scale=1, useHighRes=false, size=0x7ffdf9334b40, errorReason=0x0) at /home/nijso/mathematics/cantor/src/lib/renderer.cpp:153
Comment 5 Alexander Semke 2019-11-29 07:55:37 UTC
(In reply to nijso from comment #4)
> Hi, I have the most recent version of libspectre, 0.2.8. I re-compiled
> libspectre and cantor and it still crashes, also for the previous cantor
> version 19.08 (I thought that one worked, but unfortunately it doesn't work
> either. I tried cantor 18.04 but that one crashes when I load it). 
I'm also on openSUSE and also observed this crash in the past. The crash disappeared later and I never managed to look into this. Now it's crashing permanently for me and I had a closer look into it.

The crash happens in glibc in the memcopy call (Cantor -> Spectre -> GhostScript -> Little-CMS -> GNU C lib). Modern versions of glibc use the AVX-optimized implementations where the propper AVX-instructions are used/generated depending on the available CPU-features ("CPU-dispatching", https://lwn.net/Articles/691932/). On my and on your computer the CPU has the AVX extension and we go into the AVX-case where __memmove_avx_unaligned_erms is used. But, this generates "somehow" an instruction which is not recognized by the CPU(?) and the process crashes.

Recompiling glibc without AVX-optimization or patching the compiled library as described in https://stackoverflow.com/questions/42451492/disable-avx-optimized-functions-in-glibc-ld-hwcap-mask-etc-ld-so-nohwcap-for/44468494#44468494 will help here but is surely not an option for everybody.

I'm not sure how to deal with this now. This problem is clearly outside of Cantor.

We introduced the support for Jupyter notebooks recently:
https://sirgienkogsoc2019.blogspot.com/2019/08/cantor-and-support-for-jupyter.html

Here, for the mathematical formulas embedded into the text we also use LaTeX to generate the images. We use pdflatex to generate PDF and to render it to an image via Poppler. For general latex entries in the worksheet  we use latex as the renderer and the path is tex->EPS->libspectre->image - this is where the crash happens. Since we now require pdflatex anyway for the support of Jupyter notebooks, we should maybe completely switch to pdflatex also for normal latex entries in the worksheet. This will simplify the code a bit and also avoid this crash in the AVX-optimized glibc on openSUSE and maybe on some other distributions.
Comment 6 nijso 2019-11-30 08:08:30 UTC
Thank you for the detailed explanation - good to hear that there is a fix. Removing the pathway that leads to the error completely by switching to pdflatex sounds like a good idea.

I wanted to try cantor because of its jupyter support, which I think provides great added value to the package.
Comment 7 Alexander Semke 2019-11-30 11:19:52 UTC
(In reply to nijso from comment #6)
> Thank you for the detailed explanation - good to hear that there is a fix.
> Removing the pathway that leads to the error completely by switching to
> pdflatex sounds like a good idea.
I'm working on the fix already.


> I wanted to try cantor because of its jupyter support, which I think
> provides great added value to the package.
To unblock you, instead of using a latex entry you can work with a markdown entry and use the $...$ environment to set mathematical expressions. For this we already work with pdflatex and PDF to generate images.
Comment 8 nijso 2019-12-01 21:23:25 UTC
(In reply to Alexander Semke from comment #7)
> To unblock you, instead of using a latex entry you can work with a markdown
> entry and use the $...$ environment to set mathematical expressions. For
> this we already work with pdflatex and PDF to generate images.

Thanks! I see the rendered equation between $...$, but if I just type e.g. $\alpha=1$, the rendered equation is displayed in a normal size, but with a lot of whitespace surrounding the equation on all sides. Effectively, the result fills an entire page. Actually, if I open the pdf-file it shows an entire page with the equation somehwere in the middle. It looks like cantor does not scale the equation to something that fits on a single line. Is this connected? Do you see the same behavior?
Comment 9 Nikita Sirgienko 2019-12-02 17:40:40 UTC
(In reply to nijso from comment #8)
> (In reply to Alexander Semke from comment #7)
> > To unblock you, instead of using a latex entry you can work with a markdown
> > entry and use the $...$ environment to set mathematical expressions. For
> > this we already work with pdflatex and PDF to generate images.
> 
> Thanks! I see the rendered equation between $...$, but if I just type e.g.
> $\alpha=1$, the rendered equation is displayed in a normal size, but with a
> lot of whitespace surrounding the equation on all sides. Effectively, the
> result fills an entire page. Actually, if I open the pdf-file it shows an
> entire page with the equation somehwere in the middle. It looks like cantor
> does not scale the equation to something that fits on a single line. Is this
> connected? Do you see the same behavior?

It's actually bug with some latex code on openSUSE. It will be fixed in 19.12, when this version will release (but the master branch already have the fix).
Comment 10 Alexander Semke 2019-12-02 20:29:33 UTC
(In reply to nijso from comment #8)
> (In reply to Alexander Semke from comment #7)
> > To unblock you, instead of using a latex entry you can work with a markdown
> > entry and use the $...$ environment to set mathematical expressions. For
> > this we already work with pdflatex and PDF to generate images.
> 
> Thanks! I see the rendered equation between $...$, but if I just type e.g.
> $\alpha=1$, the rendered equation is displayed in a normal size, but with a
> lot of whitespace surrounding the equation on all sides. Effectively, the
> result fills an entire page. Actually, if I open the pdf-file it shows an
> entire page with the equation somehwere in the middle. It looks like cantor
> does not scale the equation to something that fits on a single line. Is this
> connected? Do you see the same behavior?
As Nikita already mentioned, this was fixed recently. Can you do git pull and try again?
Comment 11 nijso 2019-12-03 21:03:50 UTC
Hi, thanks, I did a git clone today of master and I do not have this problem anymore. Thank you all for getting me started with Cantor.
Comment 12 Christoph Feck 2019-12-27 22:17:26 UTC
The comments seem to indicate the originally reported crash is caused by upstream components. Is there anything left to be done for this ticket?
Comment 13 Nikita Sirgienko 2019-12-28 07:09:52 UTC
(In reply to Christoph Feck from comment #12)
> The comments seem to indicate the originally reported crash is caused by
> upstream components. Is there anything left to be done for this ticket?

Yes, you right, I close this ticket (I have fogotten to do this)
Comment 14 superwaitsum 2020-09-17 02:20:38 UTC
Created attachment 131713 [details]
New crash information added by DrKonqi

cantor (20.08.1) using Qt 5.15.1

- What I was doing when the application crashed:

Made a simple plot2d with maxima backend, also happens with other backends, it is really similar to this bug report, but using latest Cantor, tried using other repositories, but also crashes (This error has been happening since I installed it more than a month ago even after updates)

-- Backtrace (Reduced):
#5  0x00007f64f30cfd9f in cmsSignalError () from /usr/lib64/liblcms2.so.2
#6  0x00007f64f30d1cea in cmsOpenIOhandlerFromMem () from /usr/lib64/liblcms2.so.2
#7  0x00007f64f30d5b26 in cmsOpenProfileFromMemTHR () from /usr/lib64/liblcms2.so.2
#8  0x00007f64f227fd85 in gsicc_set_device_profile (pdev=pdev@entry=0x5618f73e91d8, mem=0x5618f733c1d8, file_name=file_name@entry=0x5618f76f9558 "default_rgb.icc", pro_enum=pro_enum@entry=gsDEFAULTPROFILE) at ./base/gsicc_manage.c:1985
#9  0x00007f64f2280494 in gsicc_init_device_profile_struct (dev=0x5618f73e91d8, profile_name=0x5618f76f9558 "default_rgb.icc", profile_type=gsDEFAULTPROFILE) at ./base/gsicc_manage.c:1808