Summary: | cantor git master and maxima 5.43 crash | ||
---|---|---|---|
Product: | [Applications] cantor | Reporter: | nijso <bigfootedrockmidget> |
Component: | general | Assignee: | Alexander Semke <alexander.semke> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | alexander.semke, superwaitsum, warquark |
Priority: | NOR | Keywords: | drkonqi |
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | New crash information added by DrKonqi |
Description
nijso
2019-11-26 15:52:56 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). 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. (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? 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 (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. 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. (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. (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? (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). (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? 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. The comments seem to indicate the originally reported crash is caused by upstream components. Is there anything left to be done for this ticket? (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) 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
|