valgrind errors in X server

[Jeremy Huddleston]

On Oct 11, 2011, at 02:52, Michal Suchanek wrote:

> Hello,
> 
> While valgrinding the X server to track a double free in one of my
> patches I found the errors below.
> 
> I run Xorg +extension GLX +extension RANDR +extension RENDER -logfile
> /scratch/xdummy.log -config ~hramrach/xdummy.conf :1
> 
> 
> ==3355== Conditional jump or move depends on uninitialised value(s)
> ==3355==    at 0x6DCE290: inflateReset2 (in /usr/lib/libz.so.1.2.3.4)
> ==3355==    by 0x6DCE37F: inflateInit2_ (in /usr/lib/libz.so.1.2.3.4)
> ==3355==    by 0x5B65E95: BufFilePushZIP (in /usr/lib/libXfont.so.1.4.1)
...
> ==3355==  Uninitialised value was created by a heap allocation
> ==3355==    at 0x4C2779D: malloc (in
> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==3355==    by 0x6DCE35B: inflateInit2_ (in /usr/lib/libz.so.1.2.3.4)
> ==3355==    by 0x5B65E95: BufFilePushZIP (in /usr/lib/libXfont.so.1.4.1)
...

BufFilePushZIP does:

  xzip_buf *x;

  x = malloc (sizeof (xzip_buf));
  if (!x) return 0;
  /* these are just for raw calloc/free */
  x->z.zalloc = Z_NULL;
  x->z.zfree = Z_NULL;
  x->z.opaque = Z_NULL;
  x->f = f;

  /* force inflateInit to allocate it's own history buffer */
  x->z.next_in = Z_NULL;
  x->z.next_out = Z_NULL;
  x->z.avail_in = x->z.avail_out = 0;

  /* using negative windowBits sets "nowrap" mode, which turns off
     zlib header checking [undocumented, for gzip compatibility only?] */
  x->zstat = inflateInit2(&(x->z), -MAX_WBITS);
...

Perhaps this -MAX_WBITS and your zlib don't get along... ?  I have 0 familiarity with that code.


> ==3355== Syscall param socketcall.setsockopt(optval) points to
> uninitialised byte(s)
> ==3355==    at 0x691344A: setsockopt (syscall-template.S:82)
> ==3355==    by 0x4E362FC: udev_monitor_filter_update (in /lib/libudev.so.0.9.3)
> ==3355==    by 0x4E36414: udev_monitor_enable_receiving (in
> /lib/libudev.so.0.9.3)
> ==3355==    by 0x492C45: config_udev_init (udev.c:293)
> ==3355==    by 0x491728: config_init (config.c:39)
> ==3355==    by 0x472944: InitInput (xf86Init.c:927)
> ==3355==    by 0x4271F5: main (main.c:258)
> ==3355==  Address 0x7ff000212 is on thread 1's stack
> ==3355==  Uninitialised value was created by a stack allocation
> ==3355==    at 0x4E2FA58: ??? (in /lib/libudev.so.0.9.3)

Looks like a udev bug to me ...