GNOME Bugzilla – Bug 460513
assertion failures when displaying/inserting broken image in messages
Last modified: 2021-05-19 11:56:07 UTC
Hi, When displaying a message with a corrupted image (I'll attach a sample), or when trying to insert this image in a new HTML message, evolution crashes. This is with 2.18.3. The backtrace is sadly completely useless, despite the -dbg packages being installed: Backtrace was generated from '/usr/bin/evolution' Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1233344848 (LWP 12147)] [New Thread -1286640752 (LWP 12192)] [New Thread -1278248048 (LWP 12190)] [New Thread -1269462128 (LWP 12189)] [New Thread -1261069424 (LWP 12188)] [New Thread -1249530992 (LWP 12173)] [New Thread -1240544368 (LWP 12170)] 0xffffe410 in ?? ()
+ Trace 150644
I tested other Gtk applications such as eog, and these correctly handle the GdkPixbuf loading error and display a popup. Bye,
Created attachment 92443 [details] Sample crashing gif
To reproduce, simply insert this image in a new HTML message.
salut loïc, sigh... we get some many useless traces from debian currently. any idea? opensuse 10.2 has the same problem: https://bugzilla.novell.com/show_bug.cgi?id=258433
(In reply to comment #3) > salut loïc, sigh... we get some many useless traces from debian currently. any > idea? opensuse 10.2 has the same problem: > https://bugzilla.novell.com/show_bug.cgi?id=258433 Oh thanks for the information; it has been months that Debian and Ubuntu systems have the issue, and we didn't find out why. Setting vdso_enabled to 0 froze my computer, but booting with this value on the command line produced a marginally better backtrace. Still not that useful though: Backtrace was generated from '/usr/bin/evolution' Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1232886096 (LWP 4899)] [New Thread -1259955312 (LWP 4957)] [New Thread -1278223472 (LWP 4955)] [New Thread -1269830768 (LWP 4954)] [New Thread -1261438064 (LWP 4953)] [New Thread -1249072240 (LWP 4931)] [New Thread -1240085616 (LWP 4930)] 0xb7fc27f2 in shared object not open () from /lib/ld-linux.so.2
+ Trace 150703
Thread 1 (Thread -1232886096 (LWP 4899))
I tried to reproduce this with Evo 2.11.5 and it doesn't crash. I downloaded the attachment, clicked on "New Message", "Format->HTML", then the Image Button in the toolbar and selected that downloaded file. I'll attach a screenshot. Could you try this with the latest Evolution as well?
Created attachment 92871 [details] That's the way it looks if I attach a broken image eog displays an error, if I want to open it.
Dear Reporter, is this still an issue, or can we close it as OBSOLETE as per comment #6?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
Oh sorry, missed the ping Evolution 2.22.3 doesn't crash, but I get: (evolution:5339): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_write: assertion `priv->closed == FALSE' failed (evolution:5339): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_write: assertion `priv->closed == FALSE' failed (evolution:5339): GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_write: assertion `priv->closed == FALSE' failed
I can reproduce this with vo 2.23.2. I lower severity, as Evo doesn't crash. For reference, I'll post a stacktrace which leads to that critical. GdkPixbuf-CRITICAL **: gdk_pixbuf_loader_write: assertion `priv->closed == FALSE' failed aborting... Program received signal SIGTRAP, Trace/breakpoint trap.
+ Trace 204825
Thread 140254627243904 (LWP 23440)
(gdb) Apparently, the line has a nice comment ;-) /* FIXME ! Check return value */ I have no experience with gdk_pixbufs, but the problem seems to be that it tries to write malformed data to the GdkPixbufLoader and it gets closed as soon as it receives that wrong data (in fact, it sets the GError and complains about an unrecognized format). But we're still trying to write in that GdkPixbufLoader after that. I don't know whether it makes sense, but we should probably pass the return value of gdk_pixbuf_loader_write back to the place where it has been originally called and don't try to write the data anymore. However, this doesn't look straight forward to me in first place.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.