|
|
On Thu, 2004-05-06 at 07:54, James Yonan wrote:
> > ==3026== Conditional jump or move depends on uninitialised value(s)
> > ==3026== at 0x4002496B: strlen (mac_replace_strmem.c:162)
> > ==3026== by 0x804BA02: string_alloc (buffer.c:341)
> > ==3026== by 0x806E279: verify_callback (ssl.c:510)
> > ==3026== by 0x40322BE4: (within
> > /usr/lib/i686/cmov/libcrypto.so.0.9.7)
Probably fixed with:
--- ssl.c.old 2004-05-06 17:52:46.000000000 +0300
+++ ssl.c 2004-05-06 17:53:00.000000000 +0300
@@ -505,6 +505,8 @@
char common_name[TLS_CN_LEN];
if (ctx->error_depth == 0)
extract_common_name (common_name, TLS_CN_LEN, subject);
+ else
+ common_name[0] = '\0';
if (session->common_name)
free (session->common_name);
session->common_name = string_alloc (common_name, NULL);
> > ==3026== Syscall param socketcall.sendto(msg) contains uninitialised or
> > unaddressable byte(s)
> > ==3026== at 0x40466456: __libc_sendto (in /lib/libc-2.3.2.so)
> > ==3026== by 0x805D3A1: tunnel_point_to_point (openvpn.c:81)
> > ==3026== by 0x805D5B7: main (openvpn.c:163)
> > ==3026== Address 0x41B417F6 is 98 bytes inside a block of size 1579
..
I'm not sure about this as it's skipping some of the functions before
sendto()..
> > And lots of problems inside libcrypto. I'm not sure if they're real or
> > not.
>
> These tend to look like false alarms.
Valgrind usually shows pretty correctly if there's problems. Sometimes
it just reports the errors in a bit wrong place or without enough
information.
Attachment:
signature.asc
Description: This is a digitally signed message part
|