Re: valgrind finds problems

"D. Hugh Redelmeier" <[email protected]> Mon, 16 Apr 2007 10:51:02 -0400 (EDT)
Newsgroups gmane.comp.multimedia.libnjb.user
Message-ID <[email protected]>
| From: D. Hugh Redelmeier <[email protected]>

These following messages went away when I updated valgrind.  The
version in Fedora Core 6 is valgrind-3.2.1-4.  One of the things
listed in the Release Notes for 3.2.2 is:
	138896   Add support for usb ioctls

I recommend that anyone trying to use valgrind on libnjb use the
most recent version (3.2.3).

| ==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/