Segmentation fault after sending email #591
Labels
Comments
|
Backtrace (not very useful I'm afraid): |
|
Could there be a memory leak in the prosess plugin api?
tor. 1. nov. 2018 kl. 00:22 skrev Lars Kotthoff <notifications@github.com>:
… Backtrace (not very useful I'm afraid):
#0 0x00007ffff0132d7f in raise () at /usr/lib/libc.so.6
#1 0x00007ffff011d672 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff0175878 in __libc_message () at /usr/lib/libc.so.6
#3 0x00007ffff017c18a in () at /usr/lib/libc.so.6
#4 0x00007ffff017f24c in _int_malloc () at /usr/lib/libc.so.6
#5 0x00007ffff0181736 in calloc () at /usr/lib/libc.so.6
#6 0x00007ffff315f2aa in g_malloc0 () at /usr/lib/libglib-2.0.so.0
#7 0x00007ffff4b30754 in () at /usr/lib/libgtk-3.so.0
#8 0x00007ffff4b45624 in () at /usr/lib/libgtk-3.so.0
#9 0x00007ffff4b32ef6 in () at /usr/lib/libgtk-3.so.0
#10 0x00007ffff4b31c95 in () at /usr/lib/libgtk-3.so.0
#11 0x00007ffff4b329cd in () at /usr/lib/libgtk-3.so.0
#12 0x00007ffff4b32a1b in () at /usr/lib/libgtk-3.so.0
#13 0x00007ffff4b32a1b in () at /usr/lib/libgtk-3.so.0
#14 0x00007ffff4b32a1b in () at /usr/lib/libgtk-3.so.0
#15 0x00007ffff4b32a1b in () at /usr/lib/libgtk-3.so.0
#16 0x00007ffff4b32a1b in () at /usr/lib/libgtk-3.so.0
#17 0x00007ffff4b32a1b in () at /usr/lib/libgtk-3.so.0
#18 0x00007ffff4b189f0 in () at /usr/lib/libgtk-3.so.0
#19 0x00007ffff324e3d5 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#20 0x00007ffff323b195 in () at /usr/lib/libgobject-2.0.so.0
#21 0x00007ffff323f01e in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff323fa80 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#23 0x00007ffff48f431b in () at /usr/lib/libgdk-3.so.0
#24 0x00007ffff48deb2b in () at /usr/lib/libgdk-3.so.0
#25 0x00007ffff3165b63 in () at /usr/lib/libglib-2.0.so.0
#26 0x00007ffff3166271 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#27 0x00007ffff3167f89 in () at /usr/lib/libglib-2.0.so.0
#28 0x00007ffff3167fce in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0
#29 0x00007ffff453d7ee in g_application_run () at /usr/lib/libgio-2.0.so.0
#30 0x000055555565a4ff in Astroid::Astroid::run(int, char**) ()
#31 0x0000555555655d7b in main ()
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#591 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADd-6Y5HEHG5dlrDQmtzdyUmogIo-_9ks5uqjC_gaJpZM4YDMDa>
.
|
|
I guess there could be. I've tried running it through valgrind, but haven't been able to reproduce the crash then. Running through valgrind is too slow to do it in general. |
|
Yes, and probably noisy with all the other leaks... 😛
tor. 1. nov. 2018 kl. 16:27 skrev Lars Kotthoff <notifications@github.com>:
… I guess there could be. I've tried running it through valgrind, but
haven't been able to reproduce the crash then. Running through valgrind is
too slow to do it in general.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#591 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADd-_Np0GyL2QUCXQE4hKzfNsjnS-Uhks5uqxL0gaJpZM4YDMDa>
.
|
|
Ok, I think I'm getting closer. It doesn't seem to crash in valgrind, but I'm getting messages like this: |
|
Hm, perhaps the ComposeMessage object is deleted while the signal still hasn't been handled. Still, ComposeMessage is |
|
Is the editmessage window configured to close after successful send? |
|
Would this perhaps be this upstream issue[1] ?
[1] https://gitlab.gnome.org/GNOME/glibmm/issues/28
…On Fri, 02 Nov 2018 12:00:09 -0700, Gaute Hope ***@***.***> wrote:
Hm, perhaps the ComposeMessage object is deleted while the signal still hasn't been handled. Still, ComposeMessage is `sigc::trackable` so it should cleaned up.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#591 (comment) part: text/html
|
|
@gauteh Yes, configured to auto close on success. |
|
Lars Kotthoff writes on November 2, 2018 22:04:
@gauteh Yes, configured to auto close on success.
Migth be helpful to know if it still happens without this option. Maybe
the EditMessage is closed too soon.
|
|
Will Dietz writes on November 2, 2018 21:09:
Would this perhaps be this upstream issue[1] ?
[1] https://gitlab.gnome.org/GNOME/glibmm/issues/28
Hm, I'm not sure. SocketClient isn't used in any of the classes here.
Maybe a related issue..
|
|
I've commented the following lines in edit_message.cc and it hasn't crashed since then -- take this with a grain of salt for now as I haven't been able to reliably reproduce crashes. |
|
Lars Kotthoff writes on November 3, 2018 21:27:
I've commented the following lines in edit_message.cc and it hasn't crashed since then -- take this with a grain of salt for now as I haven't been able to reliably reproduce crashes.
```
if (status_icon_visible) {
main_window->notebook.remove_widget (&message_sending_status_icon);
}
```
Hm, there could be some issues there.. if the ::close call is handled
before the signals emitted from EM causing changes to the icon are
handled there could be issues. I also just noticed that there might be
an issue with ReplyMessage and ForwardMessage subscribed to
message_sent_attempt if EditMessage is auto_closed. These should be
handled before closing..
Maybe closing needs to go on the signal queue to ensure anything already
emitted is handled before the EditMessage window is closed.
Also see #592 for some cleanups of ComposeMessage references as well as
re-org of emitting closing order (might help..).
|
|
Ok, that wasn't it (or at least not the only thing) -- still getting crashes with this commented. |
|
Do you get the crash if you turn off the auto-close option? |
|
I haven't gotten any crashes recently. Maybe it was related to the webkit threads not being cleaned up (#593 -- I'm using a version with these changes included). I'll try to investigate though. |
|
Ok, with the merge of #593 I am closing this untill it can be reproduced. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I sometimes get a segmentation fault after a message is sent. This doesn't always happen, and seems to happen in particular for emails with attachments (though again not always). Here's the debug output from one of those crashes:
I'm not sure where the
Error sending IPC messageis coming from, but I've seen this error in other contexts as well and it didn't seem to have any negative effects.The text was updated successfully, but these errors were encountered: