Bug 251075 - mail/claws-mail core dump: cannot allocate memory
Summary: mail/claws-mail core dump: cannot allocate memory
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Chris Hutchinson
Depends on:
Reported: 2020-11-12 13:22 UTC by gerrit.kuehn
Modified: 2023-08-12 07:45 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (portmaster)


Note You need to log in before you can comment on or make changes to this bug.
Description gerrit.kuehn 2020-11-12 13:22:03 UTC
claws often emits the following error message when accessing imap mailboxes:

***MEMORY-ERROR***: claws-mail[27942]: GSlice: failed to allocate 240 bytes (alignment: 256): Cannot allocate memory

This is followed by eating up all available RAM and then dumping core. The same version of claws works fine with the same mail account under Linux.
Comment 1 Chris Hutchinson 2020-11-12 19:24:16 UTC
(In reply to gerrit.kuehn from comment #0)
Thanks for your feedback.
Could you please add the output of

uname -a

on the machine you're experiencing this on, as well
as the version of claws-mail you're currently using?

Thanks again!
Comment 2 gerrit.kuehn 2020-11-26 12:26:09 UTC
This is on:
FreeBSD comet2.terra.ger 12.1-RELEASE-p10 FreeBSD 12.1-RELEASE-p10 GENERIC  amd64

Software installed is: claws-mail-3.17.5_3

Meanwhile, I was also able to get a bt using gdb (just in case this helps):

***MEMORY-ERROR***: claws-mail[16999]: GSlice: failed to allocate 240 bytes (alignment: 256): Cannot allocate memory

--Type <RET> for more, q to quit, c to continue without paging--

Thread 1 received signal SIGABRT, Aborted.
0x0000000801b401ba in thr_kill () from /lib/libc.so.7
(gdb) bt
#0  0x0000000801b401ba in thr_kill () at /lib/libc.so.7
#1  0x0000000801b3e5e4 in raise () at /lib/libc.so.7
#2  0x0000000801ab27e9 in abort () at /lib/libc.so.7
#3  0x000000080125d4a0 in  () at /usr/local/lib/libglib-2.0.so.0
#4  0x000000080125c3f6 in  () at /usr/local/lib/libglib-2.0.so.0
#5  0x000000080125bea8 in g_slice_alloc () at /usr/local/lib/libglib-2.0.so.0
#6  0x000000080125d647 in g_slist_prepend () at /usr/local/lib/libglib-2.0.so.0
#7  0x00000000003a290a in  ()
#8  0x000000000039cd19 in  ()
#9  0x0000000000388639 in  ()
#10 0x0000000000388b54 in folder_item_move_msgs ()
#11 0x000000000043b834 in procmsg_move_messages ()
#12 0x0000000000456bfe in summary_execute ()
#13 0x0000000801134ced in g_closure_invoke ()
    at /usr/local/lib/libgobject-2.0.so.0
#14 0x000000080114a602 in  () at /usr/local/lib/libgobject-2.0.so.0
#15 0x000000080114b45b in g_signal_emit_valist ()
    at /usr/local/lib/libgobject-2.0.so.0
#16 0x000000080114bb16 in g_signal_emit ()
    at /usr/local/lib/libgobject-2.0.so.0
#17 0x00000008007513a4 in  () at /usr/local/lib/libgtk-x11-2.0.so.0
#18 0x00000008007535d1 in  () at /usr/local/lib/libgtk-x11-2.0.so.0
#19 0x0000000801134ced in g_closure_invoke ()

This happens when moving mails, usually when moving messages marked for deletion to the trash folder.
Comment 3 Chris Hutchinson 2020-11-26 20:26:44 UTC
(In reply to gerrit.kuehn from comment #2)
Thanks for the imformation, gerrit!
I'm currently in the process of upgrading
mail/claws-mail to version 3.17.8.
( bug #251092 )
Once it gets committed I'm hoping it will
solve your problem.

Thanks again!

Comment 4 gerrit.kuehn 2020-11-30 06:32:04 UTC
Thank you for working for this. I'll certainly try the new version.
However, I have seen this issue over various past versions of claws through the past years, so I guess I'd be very lucky if it goes away this time.
Comment 5 gerrit.kuehn 2021-01-20 14:48:30 UTC
I upgraded to 3.17.8 (12.2) meanwhile, and I still see the same issue. It might be less pronounced, but that's more "felt" than actually measured quantitatively.
Comment 6 Chris Hutchinson 2021-10-11 05:58:38 UTC
Claws mail is now at 3.18.0.
Does your problem still persist?
If not. Please close this pr. We can open another
if you should run into this or another problem

Thanks! :-)

Comment 7 Chris Hutchinson 2021-12-20 16:56:54 UTC
I think this can be closed now. :-)
Comment 8 gerrit.kuehn 2021-12-21 06:47:05 UTC
Sorry, I didn't notice you comment before.
No, the problem is not gone, it is still the same. However, meanwhile I think it is somewhat triggered by the mailserver on the other end. I think it only happens if this is LotusNotes. However, claws still shouldn't crash, even if the mailserver might be doing something wrong.
Comment 9 Chris Hutchinson 2021-12-21 07:03:17 UTC
(In reply to gerrit.kuehn from comment #8)
OK. Fair enough. :-)
The output from your crash appears to be System || Gnome related.
Are you still on 12.1? Is your system any closer to a current 12?
Which is at 12.3 at this juncture. I get the feeling that the
problem is more "system" related, than claws related. As it
appears to fail against read/write -- like a timeout during
a long read/write that isn't closed correctly. Are you still
running the same desktop version? Claws version? OS version?

-- Chris
Comment 10 gerrit.kuehn 2021-12-21 07:25:27 UTC
12.2 meanwhile. I have a new system with 13.0 prepared, but I'm not using it for mail (yet).
"long read/write" rings a bell, though. The mentioned LN mailserver is very slow sometimes.
Comment 11 gerrit.kuehn 2022-05-30 08:26:29 UTC
(In reply to gerrit.kuehn from comment #10)
Issue appears to be fixed (or is at least less often happening) using FreeBSD 12.3 and claws 3.18.0.
Comment 12 bsd 2022-05-30 08:39:26 UTC
(In reply to gerrit.kuehn from comment #11)
What about 3.19.0? That's recent version in ports...
Comment 13 Chris Hutchinson 2022-05-30 20:58:40 UTC
(In reply to gerrit.kuehn from comment #11)
That's good to hear. Thanks for the information, gerrit.
If you *do* run into this problem again.  Please ensure
you're running the current version available in the ports
tree. As it's fairly difficult to test against older
versions of the port && system.

Thanks again, gerrit!