Re: conditional jumps based on uninitialized values in IMAP code
On Sat, May 13, 2006 at 07:25:50AM -0400, Thomas Dickey wrote:
> On Sat, 13 May 2006, Christoph Ludwig wrote:
>
> >I did not find out why line 170 in command.c depends on uninitialzed
> >values -
> >AFAICT the data idata->buf points to is read by mutt_socket_readln in
> >line 144. I am not familiar with mutt's code, so it's likely I miss
> >something. Can anyone else explain what causes valgrind's complaints?
>
> well it could be glibc (there are a large number of valgrind complaints
> pointing there). You can test this particular one by doing a memset of
> the buffer to 0's before the read. If the problem still appears, it's
> just another of glibc's bugs unrelated to the crash.
Since neither memsetting nor explicitly initializing (i.e., in a for loop) the
reallocated memory solved the problems, I played a little bit more with the
macros VALGRIND_CHECK_READABLE and VALGRID_CHECK_DEFINED. It appears the
undefindness of the data pointed to by idata->buf is a mere side effect of the
use of an uninitialized value inside mutt_socket_readchar() in mutt_socket.c.
With the following patch
Index: mutt_socket.c
===================================================================
RCS file: /home/roessler/cvs/mutt/mutt_socket.c,v
retrieving revision 3.16
diff -u -u -r3.16 mutt_socket.c
--- mutt_socket.c 28 Apr 2006 08:35:03 -0000 3.16
+++ mutt_socket.c 13 May 2006 13:53:24 -0000
@@ -45,6 +45,9 @@
#include <string.h>
#include <errno.h>
+#include <valgrind/valgrind.h>
+#include <valgrind/memcheck.h>
+
/* support for multiple socket connections */
static CONNECTION *Connections = NULL;
@@ -150,6 +153,17 @@
/* simple read buffering to speed things up. */
int mutt_socket_readchar (CONNECTION *conn, char *c)
{
+ if (RUNNING_ON_VALGRIND)
+ {
+ if (VALGRIND_CHECK_DEFINED(conn->bufpos))
+ {
+ VALGRIND_PRINTF("conn->bufpos undefined\n");
+ }
+ if (VALGRIND_CHECK_DEFINED(conn->available))
+ {
+ VALGRIND_PRINTF("conn->available undefined\n");
+ }
+ }
if (conn->bufpos >= conn->available)
{
if (conn->fd >= 0)
valgrind logged
==28370== Uninitialised byte(s) found during client check request
==28370== at 0x80C2530: mutt_socket_readchar (mutt_socket.c:162)
==28370== by 0x80C26B4: mutt_socket_readln_d (mutt_socket.c:200)
==28370== by 0x80C7E46: imap_cmd_step (command.c:161)
==28370== by 0x80C93BC: imap_open_connection (imap.c:400)
==28370== by 0x80C966E: imap_conn_find (imap.c:362)
==28370== by 0x80CC008: imap_open_mailbox (imap.c:553)
==28370== by 0x8084804: mx_open_mailbox (mx.c:698)
==28370== by 0x807A57D: main (main.c:957)
==28370== Address 0x1BDC389C is 1364 bytes inside a block of size 1396 alloc'd
==28370== at 0x1B900B88: calloc (in /usr/lib/valgrind/vgpreload_memcheck.so)
==28370== by 0x80A7262: safe_calloc (lib.c:131)
==28370== by 0x80C2911: mutt_conn_find (mutt_socket.c:385)
==28370== by 0x80C962B: imap_conn_find (imap.c:323)
==28370== by 0x80CC008: imap_open_mailbox (imap.c:553)
==28370== by 0x8084804: mx_open_mailbox (mx.c:698)
==28370== by 0x807A57D: main (main.c:957)
**28370** conn->available undefined
**28370** conn->available undefined
and so on. Where is the available field of the connection structures supposed
to be initialized?
Regards
Christoph
--
FH Worms - University of Applied Sciences
Fachbereich Informatik / Telekommunikation
Erenburgerstr. 19, 67549 Worms, Germany