Bug#410135: slrn: Charset fallback causes regular segfaults when expunging
Hi Bas, I'm not sure what is happening, because the h-from is explicitly malloced in process_xover(), which is also the only place in the source (afaics) where any Slrn_Header_Type is malloced. So, the only thing I can think of is that slrn messes with the from field somewhere lese in the code. I'll try looking into it later today... Turns out I was wrong with the double free idea: [...] I'll dig further on sunday. Could you try if the attached replacement for debian/patches/302_fallback_charset.diff fixes the problem? It does. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410135: slrn: Charset fallback causes regular segfaults when expunging
Hi Moritz!
You wrote:
I'm not sure what is happening, because the h-from is explicitly malloced
in process_xover(), which is also the only place in the source (afaics)
where any Slrn_Header_Type is malloced.
So, the only thing I can think of is that slrn messes with the from field
somewhere lese in the code. I'll try looking into it later today...
Turns out I was wrong with the double free idea:
[...]
I'll dig further on sunday.
Could you try if the attached replacement for
debian/patches/302_fallback_charset.diff fixes the problem?
Thanks!
--
Kind regards,
++
| Bas Zoetekouw | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 |
++
#! /bin/sh -e
if [ $# -ne 1 ]; then
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1
fi
case $1 in
-patch) patch -f --no-backup-if-mismatch -p1 $0;;
-unpatch) patch -f --no-backup-if-mismatch -R -p1 $0;;
*)
echo 2 `basename $0`: script expects -patch|-unpatch as argument
exit 1;;
esac
exit 0
@DPATCH@
diff -Naur eerst/slrn-0.9.8.1pl1/src/art.c slrn-0.9.8.1pl1/src/art.c
--- art.c.eerst 2007-02-10 15:24:40.418301661 +0100
+++ slrn-0.9.8.1pl1/src/art.c 2007-02-10 15:29:38.486194048 +0100
@@ -473,6 +473,9 @@
remove_from_hash_table (h);
slrn_free (h-tree_ptr);
slrn_free (h-subject);
+#ifdef USE_ICONV /* we've copied this string */
+ if (h-from_malloced != NULL) slrn_free (h-from_malloced);
+#endif
slrn_free (h-date);
slrn_free (h-realname);
slrn_free_additional_headers (h-add_hdrs);
@@ -5519,7 +5522,7 @@
static Slrn_Header_Type *process_xover (Slrn_XOver_Type *xov)
{
Slrn_Header_Type *h;
- unsigned char *c;
+ char *c;
h = (Slrn_Header_Type *) slrn_safe_malloc (sizeof (Slrn_Header_Type));
@@ -5527,9 +5530,33 @@
Number_Total++;
#ifdef USE_ICONV
- /* ok, some news client (Outlook Express *sigh*) just put unencoded
+
+ /* Annoyingly, h-from wasn't malloced separately, but is part of the same
+* buffer as h-subject (ie free()ing h-subject will also delete the memory
+* space used by h-from(). That sucks, so make a copy of from, to make
+* sure we can freely mess with the strings as we see fit.
+* NOTE: h-from is free()ed in free_header()
+*/
+ h-from_malloced = slrn_safe_strmalloc( h-from );
+ h-from = h-from_malloced;
+
+ /* ok, some news clients (Outlook Express *sigh*) just put unencoded
* latin1/9 chars in their headers. As we don't know any charset at
-* this time, replace those chars by '?' chars */
+* this time, try to translating them using the (user-specified) default
+* charset, or if the user didn't specify any, replace all non-ASCII
+* chars by question marks
+*/
+
+ /* if the user specified a fallback charset */
+ if ( Slrn_Fallback_Input_Charset_Default == 0 )
+ {
+ slrn_chmap_translate_string(Slrn_Fallback_Input_Charset,
+ Slrn_Charset, (h-subject));
+ slrn_chmap_translate_string(Slrn_Fallback_Input_Charset,
+ Slrn_Charset, (h-from));
+ }
+ else /* no fallback charset specified, so replace all high chars by ? */
+ {
c = h-subject;
while (*c!='\0' *c!=0x0a *c!=0x0d)
{
@@ -5540,6 +5567,8 @@
{
if (*c=0x7f) *c = '?'; c++;
}
+ }
+
#endif /* USE_ICONV */
#if SLRN_HAS_MIME
diff -Naur eerst/slrn-0.9.8.1pl1/src/art.h slrn-0.9.8.1pl1/src/art.h
--- art.h.eerst 2007-02-10 15:24:55.290425513 +0100
+++ slrn-0.9.8.1pl1/src/art.h 2007-02-10 15:26:54.530374227 +0100
@@ -84,6 +84,11 @@
#endif /* NOT SLRNPULL_CODE */
+#ifdef USE_ICONV
+extern char *Slrn_Fallback_Input_Charset;
+extern short int Slrn_Fallback_Input_Charset_Default;
+#endif
+
typedef struct Slrn_Header_Line_Type
{
char *name;
@@ -123,6 +128,9 @@
int bytes;
char *subject; /* malloced separately */
char *from;
+#ifdef USE_ICONV
+ char *from_malloced; /* malloced */
+#endif
char *date; /* malloced */
char *msgid; /* pointers to above space */
char *refs;
diff -Naur eerst/slrn-0.9.8.1pl1/src/chmap.c slrn-0.9.8.1pl1/src/chmap.c
--- eerst/slrn-0.9.8.1pl1/src/chmap.c 2007-01-15 18:54:23.798361500 +0100
+++ slrn-0.9.8.1pl1/src/chmap.c 2007-01-15 19:01:51.939060247 +0100
@@ -75,6 +75,11 @@
#ifdef USE_ICONV
+/* the user-specified fallback charset */
+char *Slrn_Fallback_Input_Charset = NULL;
+/* is set to a true value if the user didn't specify an override fallback */
+short int Slrn_Fallback_Input_Charset_Default = 0;
+
const iconv_t ICONV_FAIL = (iconv_t) -1;
/* translate the string *str_ptr from charset cs_from to charset cs_to */
@@ -92,7 +97,7 @@
/* make sure the charsets are
Bug#410135: slrn: Charset fallback causes regular segfaults when expunging
I've tracked it down to this hunk: +#ifdef USE_ICONV /* we've copied this string */ + slrn_free (h-from); +#endif This triggers a double free. With slrn_free (h-from); removed slrn works w/o segfaults. Yes, that's what I expected. However, simply removing the slrn_free() will result in lots of memleaks. I'm not sure what is happening, because the h-from is explicitly malloced in process_xover(), which is also the only place in the source (afaics) where any Slrn_Header_Type is malloced. So, the only thing I can think of is that slrn messes with the from field somewhere lese in the code. I'll try looking into it later today... -- Bas Zoetekouw
Bug#410135: slrn: Charset fallback causes regular segfaults when expunging
Bas Zoetekouw wrote: I've tracked it down to this hunk: +#ifdef USE_ICONV /* we've copied this string */ + slrn_free (h-from); +#endif This triggers a double free. With slrn_free (h-from); removed slrn works w/o segfaults. Yes, that's what I expected. However, simply removing the slrn_free() will result in lots of memleaks. I'm not sure what is happening, because the h-from is explicitly malloced in process_xover(), which is also the only place in the source (afaics) where any Slrn_Header_Type is malloced. So, the only thing I can think of is that slrn messes with the from field somewhere lese in the code. I'll try looking into it later today... Turns out I was wrong with the double free idea: ==14705== Invalid free() / delete / delete[] ==14705==at 0x401D0CA: free (vg_replace_malloc.c:233) ==14705==by 0x40A6B10: SLfree (in /lib/libslang.so.2.0.6) ==14705==by 0x8050068: free_header (art.c:477) ==14705==by 0x8055316: art_xpunge (art.c:6881) ==14705==by 0x807A7C1: main (slrn.c:1786) ==14705== Address 0x598 is 72 bytes inside a block of size 108 free'd ==14705==at 0x401D0CA: free (vg_replace_malloc.c:233) ==14705==by 0x40A6B10: SLfree (in /lib/libslang.so.2.0.6) ==14705==by 0x805005D: free_header (art.c:475) ==14705==by 0x8055316: art_xpunge (art.c:6881) ==14705==by 0x807A7C1: main (slrn.c:1786) I'll dig further on sunday. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410135: slrn: Charset fallback causes regular segfaults when expunging
Hi Moritz! I've upgraded my sid-based notebook last week and I'm running into problems caused by the charset fallback patch. I'm regularly using x to remove all non-tagged read articles from the article list and slrn segfaults every 5-7th time. I suppose it's some kind of memory corruption. I don't have prior experience with the slrn code base and lack the time to dig further for the cause. Bas, could you have a look? I'd be happy to test patches. Hmm, that's weird, I thought my patch should work fine, at least valgrind showed no heap corruptions here. Could you try running valgrind --leak-check=full --show-reachable=yes on one of the session that crashes? That should give me some information about which variable is causing the corruption. Thanks, Bas. -- Bas Zoetekouw
Bug#410135: slrn: Charset fallback causes regular segfaults when expunging
On Thu, Feb 08, 2007 at 02:47:00PM +0100, Bas Zoetekouw wrote: Hi Moritz! I've upgraded my sid-based notebook last week and I'm running into problems caused by the charset fallback patch. I'm regularly using x to remove all non-tagged read articles from the article list and slrn segfaults every 5-7th time. I suppose it's some kind of memory corruption. I don't have prior experience with the slrn code base and lack the time to dig further for the cause. Bas, could you have a look? I'd be happy to test patches. Hmm, that's weird, I thought my patch should work fine, at least valgrind showed no heap corruptions here. Could you try running valgrind --leak-check=full --show-reachable=yes on one of the session that crashes? That should give me some information about which variable is causing the corruption. I've tracked it down to this hunk: +#ifdef USE_ICONV /* we've copied this string */ + slrn_free (h-from); +#endif This triggers a double free. With slrn_free (h-from); removed slrn works w/o segfaults. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410135: slrn: Charset fallback causes regular segfaults when expunging
Package: slrn Version: 0.9.8.1pl1-26 Severity: important I've upgraded my sid-based notebook last week and I'm running into problems caused by the charset fallback patch. I'm regularly using x to remove all non-tagged read articles from the article list and slrn segfaults every 5-7th time. One article which can reproduce this all the time is an article from debian-release about glibc time zone changes. I'm attaching a backtrace: (gdb) bt #0 0xb7d0192d in free () from /lib/tls/libc.so.6 #1 0xb7efcb11 in SLfree () from /lib/libslang.so.2 #2 0x08050069 in free_header (h=0x86213a8) at art.c:477 #3 0x08055317 in art_xpunge () at art.c:6881 #4 0x0807a7c2 in main (argc=1, argv=0xbfcd39e4) at slrn.c:1786 (gdb) up #1 0xb7efcb11 in SLfree () from /lib/libslang.so.2 (gdb) up #2 0x08050069 in free_header (h=0x86213a8) at art.c:477 477slrn_free (h-from); (gdb) print h-from $1 = 0x8623560 Aurelien Jarno [EMAIL PROTECTED] (gdb) I've read through the patches and the fact that h-from caused the crash made me wonder, if the change from Bas in 0.9.8.1pl1-25 may be the cause: | * Added fallback charset patch from Bas Zoetekouw and documented the new |feature in NEWS.Debian. (closes: #403781, #406210) So I backed out patch 302 and after that I no longer see crashes. I suppose it's some kind of memory corruption. I don't have prior experience with the slrn code base and lack the time to dig further for the cause. Bas, could you have a look? I'd be happy to test patches. The segfaults are very frequent for my usage pattern (every few minutes) and quite annoying. I'm running an X-less environment with a plain fbcon console. (Which could make a difference, I'm not sure) Cheers, Moritz -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages slrn depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii debianutils 2.17.5 Miscellaneous utilities specific t ii libc6 2.3.6.ds1-10 GNU C Library: Shared libraries ii libcanlock2 2b-4 library for creating and verifying ii libgnutls13 1.4.4-3 the GNU TLS library - runtime libr ii libslang2 2.0.6-4 The S-Lang programming library - r slrn recommends no packages. -- debconf information: slrn/getdescs_now: false * shared/mailname: inutil.org slrn/manual_getdescs: * shared/news/server: localhost slrn/getdescs: cron job slrn/lost_slrnpull: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
