view a message with a large attachement (6127616 bytes) segfaults at the first time. second time (message is cached local) view this message works fine. bt and bt full is attached
Created attachment 616 [details] bt from segfault bt
Created attachment 617 [details] bt full from segfault bt full
Changes related to this bug have been committed. Please check latest CVS and update the bug accordingly. You can also get the patch from: http://www.colino.net/claws-mail/ 2008-07-29 [colin] 3.5.0cvs37 * src/news.c Fix bug 1684, 'view news messages with large attachements segfaults'
still segfaults bt and bt full
Created attachment 618 [details] bt from segfault 3.5.0cvs37 bt from segfault 3.5.0cvs37
Created attachment 619 [details] bt full from segfault 3.5.0cvs37 bt full from segfault 3.5.0cvs37
Then it's probably a memory corruption error in libetpan. Can you install the debug symbols for libetpan, run with valgrind and send us the log?
Created attachment 620 [details] valgrind memcheck no crash with valgrind, the same posting segfaults CM without valgrind
the problem also exists in 3.3.0 with libetpan 0.54 btw: where are the release tarballs between 3.3.0 und 2.10.0 at sourceforge?
2.10.0, 3.0.0 works fine 3.1.0 segfaults
claws-mail-3.1.0 + libetpan-0.53 segfault claws-mail-3.1.0 + libetpan-0.52 segfault claws-mail-3.1.0 + libetpan-0.51 segfault libetpan-0.50 (compiler error) mailsmtp.c: In function 'sasl_getsecret': mailsmtp.c:1101: warning: unused parameter 'conn' mailsmtp.c: In function 'sasl_getrealm': mailsmtp.c:1119: warning: unused parameter 'availrealms' mailsmtp.c: In function 'mailesmtp_auth_sasl': mailsmtp.c:1260: error: 'f' undeclared (first use in this function) mailsmtp.c:1260: error: (Each undeclared identifier is reported only once mailsmtp.c:1260: error: for each function it appears in.) claws-mail-3.1.0 + libetpan-0.49 segfault
This is a libetpan bug.
libetpan bug at sf.net is https://sourceforge.net/tracker/?func=detail&atid=429697&aid=2041394&group_id=41064 no response yet
I think Hoa's on holidays :)
sf bug for libetpan closed... "This bug seems to be related to claws mail and not to libetpan." https://sourceforge.net/tracker/?func=detail&atid=429697&aid=2041394&group_id=41064 problem still exists
Created attachment 828 [details] new bt from abrt
There's new versions of Claws Mail and LibEtPan (and code in nntp.c has changed a lot), and the tracker with LibEtPan bug doesn't exist anymore. Is this still reproducible with a recent version?
still the same segfaults if the message ist ~800KB $ rpm -q claws-mail libetpan claws-mail-3.9.0-1.fc18.i686 libetpan-1.1-3.fc18.i686
Same backtrace than the last one you posted? (3.5.0) If possible attach the 3.9.0 backtrace. thanks in advance,
Created attachment 1255 [details] bt for 3.9.0
Created attachment 1256 [details] bt full for 3.9.0
Created attachment 1257 [details] Proposed fix Thanks Sthephan for the backtraces. From what I see following the code flow, the g_free(result); line causing the crash is wrong. The data returned into result in the end comes from a libEtPan's "str" member in a MMAPString structure, which is not allocated by glib functions but by the malloc/realloc functions (src/data-types/mmapstring.c in libEtPan). Going a bit further, seems the MMAPString used for reading the article (see mailstream_read_multiline in mailstream_helper.c) is simply reused (first call is mmap_string_assign(multiline_buffer, "")), so the buffer is not intended to be freed by the caller. To summarise, can build from 3.9.0 sources with the attached patch applied and see if it stops crashing? :)
sorry for delay! probably-fix-1684.patch works for me with 3.9.0 :)
Changes related to this bug have been committed. Please check latest Git and update the bug accordingly. You can also get the patch from: http://git.claws-mail.org/ http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=f46d6934781359c0a4e6df3f78e74a799c883f4a Author: Ricardo Mones <ricardo@mones.org> Date: Thu May 2 09:28:15 2013 +0200 Fix bug #1684 'view news messages with large attachements segfaults' Don't g_free MMAPString str data which we didn't allocate