valgrind finds problems

I have a new Creative Zen V.  I'm playing with Gnomad2 to manage it.
I'm investigating some bugs.  I'm trying valgrind on it.

If I just start gnomad2, and then tell gnomad2 to quit, everything
seems fine.  Yet if I do this under valgrind, I get a lot of error
reports.  Some are likely benign but some may be latent bugs.

The ones I've looked at seem to be problems in libraries that are
called.  In particular, in libnjb or in libusb.

Has any libnjb developer tried valgrind on it?

Here are the first messages from valgrind.  My system is an up-to-date
Fedora Core 6 system running on x86_64.  The gnomad2 is from the
current CVS HEAD.


$ valgrind ./gnomad2
==18535== Memcheck, a memory error detector.
==18535== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==18535== Using LibVEX rev 1658, a library for dynamic binary translation.
==18535== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==18535== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==18535== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==18535== For more details, rerun with: -v
==18535==
==18535== Syscall param writev(vector[...]) points to uninitialised byte(s)
==18535==    at 0x3503AC65AC: writev (writev.c:46)
==18535==    by 0x30F224641B: (within /usr/lib64/libX11.so.6.2.0)
==18535==    by 0x30F224B2AE: _XSend (in /usr/lib64/libX11.so.6.2.0)
==18535==    by 0x30F223CF9F: XQueryExtension (in /usr/lib64/libX11.so.6.2.0)
==18535==    by 0x30F22317D3: XInitExtension (in /usr/lib64/libX11.so.6.2.0)
==18535==    by 0x30F3A03B89: XFixesFindDisplay (Xfixes.c:58)
==18535==    by 0x30F3A03DF8: XFixesQueryExtension (Xfixes.c:302)
==18535==    by 0x30F483A43E: gdk_display_open (gdkdisplay-x11.c:195)
==18535==    by 0x30F4819AAC: gdk_display_open_default_libgtk_only (gdk.c:278)
==18535==    by 0x30F432D4E3: gtk_init_check (gtkmain.c:889)
==18535==    by 0x30F432D508: gtk_init (gtkmain.c:924)
==18535==    by 0x40C094: main (gnomad2.c:486)
==18535==  Address 0x4CC6C6C is 324 bytes inside a block of size 16,384 alloc'd
==18535==    at 0x4A04BA2: calloc (vg_replace_malloc.c:279)
==18535==    by 0x30F2237116: XOpenDisplay (in /usr/lib64/libX11.so.6.2.0)
==18535==    by 0x30F483A298: gdk_display_open (gdkdisplay-x11.c:145)
==18535==    by 0x30F4819AAC: gdk_display_open_default_libgtk_only (gdk.c:278)
==18535==    by 0x30F432D4E3: gtk_init_check (gtkmain.c:889)
==18535==    by 0x30F432D508: gtk_init (gtkmain.c:924)
==18535==    by 0x40C094: main (gnomad2.c:486)

I'd guess that this is xlib misbehaving, but I haven't looked.

==18535==
==18535== Syscall param ioctl(generic) points to uninitialised byte(s)
==18535==    at 0x3503AC6147: ioctl (in /lib64/libc-2.5.so)
==18535==    by 0x321E604B0A: usb_os_find_devices (linux.c:417)
==18535==    by 0x321E601D81: usb_find_devices (usb.c:98)
==18535==    by 0x3359607A83: njb_discover (base.c:108)
==18535==    by 0x3359612DA5: NJB_Discover (procedure.c:115)
==18535==    by 0x411683: jukebox_discover (jukebox.c:758)
==18535==    by 0x40B776: create_select_jukebox_dialog (gnomad2.c:124)
==18535==    by 0x40B9BF: expose (gnomad2.c:215)
==18535==    by 0x30F433266C: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
==18535==    by 0x321740AF18: g_closure_invoke (gclosure.c:490)
==18535==    by 0x321741A787: signal_emit_unlocked_R (gsignal.c:2440)
==18535==    by 0x321741B99C: g_signal_emit_valist (gsignal.c:2209)
==18535==  Address 0x7FEFFDBE0 is on thread 1's stack

Perhaps valgrind cannot correctly analyze the dataflow in an unknown
ioctl.  Maybe this one only writes to memory.  So this could be a
false positive.

==18535==
==18535== Conditional jump or move depends on uninitialised value(s)
==18535==    at 0x321E603FE5: usb_os_determine_children (linux.c:537)
==18535==    by 0x321E601EF6: usb_find_devices (usb.c:175)
==18535==    by 0x3359607A83: njb_discover (base.c:108)
==18535==    by 0x3359612DA5: NJB_Discover (procedure.c:115)
==18535==    by 0x411683: jukebox_discover (jukebox.c:758)
==18535==    by 0x40B776: create_select_jukebox_dialog (gnomad2.c:124)
==18535==    by 0x40B9BF: expose (gnomad2.c:215)
==18535==    by 0x30F433266C: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
==18535==    by 0x321740AF18: g_closure_invoke (gclosure.c:490)
==18535==    by 0x321741A787: signal_emit_unlocked_R (gsignal.c:2440)
==18535==    by 0x321741B99C: g_signal_emit_valist (gsignal.c:2209)
==18535==    by 0x321741BDA2: g_signal_emit (gsignal.c:2243)

This looks questionable.  Is njb_discover asking usb_find_device
something invalid or is this a bug in libusb?

==18535==
==18535== Use of uninitialised value of size 8
==18535==    at 0x321E603FEA: usb_os_determine_children (linux.c:538)
==18535==    by 0x321E601EF6: usb_find_devices (usb.c:175)
==18535==    by 0x3359607A83: njb_discover (base.c:108)
==18535==    by 0x3359612DA5: NJB_Discover (procedure.c:115)
==18535==    by 0x411683: jukebox_discover (jukebox.c:758)
==18535==    by 0x40B776: create_select_jukebox_dialog (gnomad2.c:124)
==18535==    by 0x40B9BF: expose (gnomad2.c:215)
==18535==    by 0x30F433266C: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84)
==18535==    by 0x321740AF18: g_closure_invoke (gclosure.c:490)
==18535==    by 0x321741A787: signal_emit_unlocked_R (gsignal.c:2440)
==18535==    by 0x321741B99C: g_signal_emit_valist (gsignal.c:2209)
==18535==    by 0x321741BDA2: g_signal_emit (gsignal.c:2243)

Same question.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/