| Summary: | when opened message (incapsulated by outlook) kmail crashes | ||
|---|---|---|---|
| Product: | [Applications] kmail2 | Reporter: | Diego Ercolani <diego.ercolani> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | ABeisemann, arnold338250622, auxsvr, bugrprt21882, habero, kdebugzilla, matze, montel, ripper, ruthesroses, vkrause, wbauer1 |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.10.3 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kdepim-addons/07524e4302f1b25d70a371f42265a2a45c4f39e4 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | New crash information added by DrKonqi | ||
|
Description
Diego Ercolani
2019-06-21 16:32:23 UTC
it seems to be a crash from KItinerary plugins I add volker as CC This is Poppler crashing on the attached PDF I think. A local workaround is to delete /usr/lib64/plugins/messageviewer/bodypartformatter/messageviewer_bodypartformatter_semantic.so (exact location can vary slightly depending on the distro). For addressing the actual issue (assuming it still exists in newer Poppler versions) we'd need the PDF causing this. @Volker, I did it: pc-diego:~ # mv /usr/lib64/qt5/plugins/messageviewer/bodypartformatter/messageviewer_bodypartformatter_semantic.so /usr/lib64/qt5/plugins/messageviewer/bodypartformatter/messageviewer_bodypartformatter_semantic.so.bak Restarting kontact and I can read the mail without crashing. I can also read the pdf documents attached without any problem using okular. To answer your request, I can provide you the original e-mail message, but, although it is not containing "secrets" it contain contractual information so I can not divulgate publically so I need an email address or a personal contact of you Thank you Diego pc-diego:~ # rpm -qf /usr/lib64/qt5/plugins/messageviewer/bodypartformatter/messageviewer_bodypartformatter_semantic.so kdepim-addons-18.12.3-lp151.3.1.x86_64 Okular being able to display the document is indeed an important observation, could be a bug in the extractor plugin after all, or a different way of using Popppler. Providing the affected document in private is perfectly fine of course, you can send it to vkrause@kde.org (GPG key 0x7F96CCD64D12D247 if you want to encrypt it) and I'll delete as soon as the problem has been debugged. Thanks! The document it's on its way to you. Thank you Created attachment 121688 [details]
New crash information added by DrKonqi
kmail (5.10.3) using Qt 5.9.7
- What I was doing when the application crashed:
Clicked on an unread email in kmail, the email has 3 attachements, all of which are PDF.
-- Backtrace (Reduced):
#7 0x00007f594a993e6a in opj_destroy_codec (p_codec=0x56090098f140) at /usr/src/debug/openjpeg2-2.3.0-lp151.2.3.x86_64/src/lib/openjp2/openjpeg.c:929
#8 0x00007f594b0394e4 in JPXStreamPrivate::init2 (this=0x5609006922e0, format=format@entry=OPJ_CODEC_JP2, buf=buf@entry=0x56090098f7d0 "", length=length@entry=95180, indexed=<optimized out>) at /usr/src/debug/poppler-0.62.0-lp151.3.4.x86_64/poppler/JPEG2000Stream.cc:356
#9 0x00007f594b039969 in JPXStream::init (this=0x56090098f070) at /usr/src/debug/poppler-0.62.0-lp151.3.4.x86_64/poppler/JPEG2000Stream.cc:236
#10 0x00007f594b039f2e in JPXStream::getImageParams (this=0x56090098f070, bitsPerComponent=0x7fffef5bf7b8, csMode=0x7fffef5bf7bc) at /usr/src/debug/poppler-0.62.0-lp151.3.4.x86_64/poppler/JPEG2000Stream.cc:142
#11 0x00007f594af7a92f in Gfx::doImage (this=this@entry=0x5608feb1add0, ref=ref@entry=0x7fffef5bfe90, str=0x56090098f070, inlineImg=inlineImg@entry=false) at /usr/src/debug/poppler-0.62.0-lp151.3.4.x86_64/poppler/Gfx.cc:4221
I can confirm: Kmail crashes while opening a mail with an attached pdf. Saving the mail (with another version of kmail) and trying to open the .mbox file leads to the crash as well. - The same mail without attachement (edited the mbox file) does open fine, the attached PDF file can be displayed in Okular without problems. - Removing the base64 encoded part is sufficient to prevent kmail from crashing. - Replacing the PDF by another (base64 encoded) PDF works fine as well. - Rewriting the PDF with gs -sDEVICE=pdfwrite and attaching it as base64 encoded file works as well. Thus I think it is a specific problem with the PDF file. I can send the file on request. Is bug 372142 a duplicate of this? Is that with KMail 5.10/18.12 for you as well? I so far cannot reproduce this with more recent versions, but if you have a document that crashes 5.11/19.04 or 5.12/19.08 I'm of course very much interested. Independent of that, I'm looking at moving the PDF parsing out of process to avoid this problem more fundamentally. Until then, see Comment #3 for a local workaround. I'm on openSUSE 15.1 with Kontact==KMail 5.10.3 (kmail 18.12.3-lp151.3.7.1) KDE Frameworks 5.55.0 Qt 5.9.7 Git commit 07524e4302f1b25d70a371f42265a2a45c4f39e4 by Volker Krause. Committed on 11/08/2019 at 08:39. Pushed by vkrause into branch 'master'. Use external itinerary extraction process This avoids parsing PDF files in the KMail process, isolating us entirely from crashes or hangs due to corrupt files or bugs in our PDF parser. M +4 -18 plugins/messageviewer/bodypartformatter/semantic/semanticprocessor.cpp https://commits.kde.org/kdepim-addons/07524e4302f1b25d70a371f42265a2a45c4f39e4 *** Bug 416190 has been marked as a duplicate of this bug. *** *** Bug 414102 has been marked as a duplicate of this bug. *** *** Bug 417979 has been marked as a duplicate of this bug. *** FTR, as I found out yesterday, the crash in openSUSE Leap 15.1 was because libopenjpeg1 and libopenjp2 were loaded into the same process. Leap's ffmpeg-3 (libavcodec57) package is built with openjpeg1, and is used by QtWebEngine. So poppler (which uses libopenjp2) ended up calling some functions from libopenjpeg1 instead (both libs contain functions with the same name), resulting in some things not being initialized properly and leading to the crash in libopenjp2 later on. The switch to using an external process actually fixed that as well btw, as the separate executable has much smaller dependencies, in particular it doesn't load QtWebEngine... wow, nice find, that's a nasty one *** Bug 414574 has been marked as a duplicate of this bug. *** *** Bug 416318 has been marked as a duplicate of this bug. *** *** Bug 419317 has been marked as a duplicate of this bug. *** |