Re: Complex config triggering Segfault in pattern matching code.

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 17,  9:18am, Jonathan H wrote:
} Subject: Re: Complex config triggering Segfault in pattern matching code.
}
} So, I ran ZSH for over 48 hours, and it finally crashed. I don't know
} if it was the normal crashes I'm seeing because valgrind seems to have
} rendered all of my tests useless. (Also, it gobbled up all of my RAM,
} so I can't tell if that's why it crashed).
} 
} Attached is the STDERR from "valgrind -q --trace-children=yes
} --track-origins=yes"

Thanks.  If you do this again I think you can avoid --trace-children.

} A lot of errors seem to have cropped up.

Yeah, but the vast majority of them are the same error repeating.

Already fixed this one:

==1705== Source and destination overlap in strcpy(0x402bd24, 0x402bd51)
==1705==    at 0x4C2D766: __GI_strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1705==    by 0x488CD0: stringsubst (subst.c:301)

This one seems obvious:

==1705==  Uninitialised value was created by a heap allocation
==1705==    at 0x4C29F90: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1705==    by 0x45C446: zalloc (mem.c:896)
==1705==    by 0x65A4781: init_keymaps (zle_keymap.c:1194)


diff --git a/Src/Zle/zle_keymap.c b/Src/Zle/zle_keymap.c
index be02f3a..cfef882 100644
--- a/Src/Zle/zle_keymap.c
+++ b/Src/Zle/zle_keymap.c
@@ -1201,7 +1201,7 @@ init_keymaps(void)
 {
     createkeymapnamtab();
     default_bindings();
-    keybuf = (char *)zalloc(keybufsz);
+    keybuf = (char *)zshcalloc(keybufsz);
     lastnamed = refthingy(t_undefinedkey);
 }


This is the one that repeats a lot:

==1705==  Uninitialised value was created by a heap allocation
==1705==    at 0x4C2C29E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==1705==    by 0x45C798: zrealloc (mem.c:938)
==1705==    by 0x65B0D18: set_region_highlight (zle_refresh.c:454)

It would appear that the loop at zle_refresh.c:461 needs to assign
values to rhp->start_meta and rhp->end_meta at the same time that it
calculates rhp->start and rhp->end.  However, I'm not familiar enough
with the region_highlight algorithm to be sure how to initialize those.

It's possible that fixing this will fix the next one as a side-effect.

Finally this one repeats a few times:

==1705== Conditional jump or move depends on uninitialised value(s)
==1705==    at 0x5A04253: vfprintf (in /usr/lib/libc-2.20.so)
==1705==    by 0x5A278FA: vsprintf (in /usr/lib/libc-2.20.so)
==1705==    by 0x5A0ACD6: sprintf (in /usr/lib/libc-2.20.so)
==1705==    by 0x65B0B66: get_region_highlight (zle_refresh.c:410)

That's this:

	sprintf(digbuf1, "%d", rhp->start);
	sprintf(digbuf2, "%d", rhp->end);

I'm confused about that one because I can't see where rhp->start might
be coming from without getting initialized.  It LOOKS like the loop in
set_region_highlight() always either initializes those, or truncates
the array to be no more than N_SPECIAL_HIGHLIGHTS elements long.  In
the latter case the loop containing those sprintf's should never make
a circuit.  There is a potential problem in that the loop test is just
(arrsize--) which could go on infinitely if arrsize is negative when
the loop begins, but there isn't enough log output for this to be an
infinite loop.