|
From: Daniel M. <da...@im...> - 2004-09-28 17:01:30
|
I'm using valgrind 2.2.0 for the first time, on a linux 2.6.7 system with gcc 3.3.4. I have optimizations set to -O. However, I'm getting *many* warnings about "Conditional jump or move depends on uninitialized value"... some of these warnings are clearly spurious; a typical example is: result = get_number_of_luns(udev) ; total_luns = (result <= 0) ? 1 : result ; // line 1449 ==25533== Conditional jump or move depends on uninitialised value(s) ==25533== at 0x805AC84: find_dev_cap(unsigned) (imilib.cpp:1449) result is defined as int, and get_number_of_luns() returns int. So result cannot be uninitialized here. I even tried removing optimization flags entirely, but it didn't change these warnings. What, if anything, can I do to resolve these warnings and get down to valid messages?? |
|
From: Robert W. <rj...@du...> - 2004-09-28 17:30:05
|
> I'm using valgrind 2.2.0 for the first time, on a linux 2.6.7 system with > gcc 3.3.4. I have optimizations set to -O. However, I'm getting *many* > warnings about "Conditional jump or move depends on uninitialized value"... > some of these warnings are clearly spurious; a typical example is: > > result = get_number_of_luns(udev) ; > total_luns = (result <= 0) ? 1 : result ; // line 1449 > > ==25533== Conditional jump or move depends on uninitialised value(s) > ==25533== at 0x805AC84: find_dev_cap(unsigned) (imilib.cpp:1449) > > result is defined as int, and get_number_of_luns() returns int. So result > cannot be uninitialized here. > > I even tried removing optimization flags entirely, but it didn't change > these warnings. What, if anything, can I do to resolve these warnings and > get down to valid messages?? Check to see if get_number_of_luns is returning an initialized value. Valgrind won't report that on exit of get_number_of_luns, but it will pass the uninitialized value around and Valgrind will detect when it's used to make a decision. Try compiling it with -Wall to see if gcc spots anything. |
|
From: Daniel M. \(IMI\) <da...@im...> - 2004-09-28 17:36:08
|
First, I *do* compile with -Wall (I learned that lesson a LONG time ago!!!).
Also, my code has been linted and is lint-clean.
Here's the get_number_of_luns() function:
//**************************************************************************
**
static int get_number_of_luns(usb_dev_handle *udev)
{
char xbuf ;
// swap bytes around because u16 fields in
// usb_control_msg() are big-endian
int result = usb_control_msg(udev, // handle
0xA1, // requesttype
0xFE, // request
0, // value
0, // index
&xbuf, // data pointer
1, // length
5000) ; // timeout
if (result < 0)
return result;
result = (int) (xbuf) + 1 ;
return result;
}
The A1/FE control message returns one byte. So it doesn't look, to me, as
though get_number_of_luns() can fail to return a value...
Dan
----- Original Message -----
From: "Robert Walsh" <rj...@du...>
To: "Daniel Miller" <da...@im...>
Cc: <val...@li...>
Sent: Tuesday, September 28, 2004 10:29
Subject: Re: [Valgrind-users] improbably "uninitialized value" warning
> > I'm using valgrind 2.2.0 for the first time, on a linux 2.6.7 system
with
> > gcc 3.3.4. I have optimizations set to -O. However, I'm getting *many*
> > warnings about "Conditional jump or move depends on uninitialized
value"...
> > some of these warnings are clearly spurious; a typical example is:
> >
> > result = get_number_of_luns(udev) ;
> > total_luns = (result <= 0) ? 1 : result ; // line 1449
> >
> > ==25533== Conditional jump or move depends on uninitialised value(s)
> > ==25533== at 0x805AC84: find_dev_cap(unsigned) (imilib.cpp:1449)
> >
> > result is defined as int, and get_number_of_luns() returns int. So
result
> > cannot be uninitialized here.
> >
> > I even tried removing optimization flags entirely, but it didn't change
> > these warnings. What, if anything, can I do to resolve these warnings
and
> > get down to valid messages??
>
> Check to see if get_number_of_luns is returning an initialized value.
> Valgrind won't report that on exit of get_number_of_luns, but it will
> pass the uninitialized value around and Valgrind will detect when it's
> used to make a decision. Try compiling it with -Wall to see if gcc
> spots anything.
>
>
>
|
|
From: Daniel M. \(IMI\) <da...@im...> - 2004-09-28 17:46:24
|
Okay, I added
char xbuf = 0 ;
to the beginning of get_number_of_luns(). I understand now that valgrind
doesn't realize that xbuf will be initialized unless usb_control_msg()
returned negative value, and in either case get_number_of_luns() will return
a valid value. So I'll have to add unnecessary initialization code to quiet
valgrind, tho it isn't needed by the actual application.
Are there some kind of conditional compile flags that I can use to remove
such code when I'm not going to run valgrind (similar to the #ifdef _lint
for lint), so I don't always have this extra code installed?
Dan Miller
// repeating the get_number_of_luns() function for reference purposes...
//**************************************************************************
**
static int get_number_of_luns(usb_dev_handle *udev)
{
char xbuf = 0 ; // initializing here is not needed, except to quiet
valgrind warnings
// swap bytes around because u16 fields in
// usb_control_msg() are big-endian
int result = usb_control_msg(udev, // handle
0xA1, // requesttype
0xFE, // request
0, // value
0, // index
&xbuf, // data pointer
1, // length
5000) ; // timeout
if (result < 0)
return result;
result = (int) (xbuf) + 1 ;
return result;
}
----- Original Message -----
From: "Robert Walsh" <rj...@du...>
To: "Daniel Miller" <da...@im...>
Cc: <val...@li...>
Sent: Tuesday, September 28, 2004 10:29
Subject: Re: [Valgrind-users] improbably "uninitialized value" warning
> > I'm using valgrind 2.2.0 for the first time, on a linux 2.6.7 system
with
> > gcc 3.3.4. I have optimizations set to -O. However, I'm getting *many*
> > warnings about "Conditional jump or move depends on uninitialized
value"...
> > some of these warnings are clearly spurious; a typical example is:
> >
> > result = get_number_of_luns(udev) ;
> > total_luns = (result <= 0) ? 1 : result ; // line 1449
> >
> > ==25533== Conditional jump or move depends on uninitialised value(s)
> > ==25533== at 0x805AC84: find_dev_cap(unsigned) (imilib.cpp:1449)
> >
> > result is defined as int, and get_number_of_luns() returns int. So
result
> > cannot be uninitialized here.
> >
> > I even tried removing optimization flags entirely, but it didn't change
> > these warnings. What, if anything, can I do to resolve these warnings
and
> > get down to valid messages??
>
> Check to see if get_number_of_luns is returning an initialized value.
> Valgrind won't report that on exit of get_number_of_luns, but it will
> pass the uninitialized value around and Valgrind will detect when it's
> used to make a decision. Try compiling it with -Wall to see if gcc
> spots anything.
>
>
>
|
|
From: Tom H. <th...@cy...> - 2004-09-28 18:32:22
|
In message <014a01c4a583$10e44270$0401a8c0@dan>
"Daniel Miller \(IMI\)" <da...@im...> wrote:
> Okay, I added
> char xbuf = 0 ;
> to the beginning of get_number_of_luns(). I understand now that valgrind
> doesn't realize that xbuf will be initialized unless usb_control_msg()
> returned negative value, and in either case get_number_of_luns() will return
> a valid value. So I'll have to add unnecessary initialization code to quiet
> valgrind, tho it isn't needed by the actual application.
You shouldn't need to do that as valgrind will monitor the code
in usb_control_msg() and should see xbuf being written to.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bryan O'S. <bo...@se...> - 2004-09-28 18:49:44
|
On Tue, 2004-09-28 at 10:46 -0700, Daniel Miller (IMI) wrote: > Okay, I added > char xbuf = 0 ; > to the beginning of get_number_of_luns(). I understand now that valgrind > doesn't realize that xbuf will be initialized unless usb_control_msg() > returned negative value, and in either case get_number_of_luns() will return > a valid value. So I'll have to add unnecessary initialization code to quiet > valgrind, tho it isn't needed by the actual application. Why do you think get_number_of_luns is returning a valid value in xbuf? It is quite possible that it is not. Since I assuming you're using libusb, you should check the source and find out. > Are there some kind of conditional compile flags that I can use to remove > such code when I'm not going to run valgrind (similar to the #ifdef _lint > for lint), so I don't always have this extra code installed? Yes, you can use #ifdef NVALGRIND. However, if you're talking about setting a char value to zero, there's no reason to avoid it. <b |
|
From: Daniel M. \(IMI\) <da...@im...> - 2004-09-28 19:01:20
|
----- Original Message ----- From: "Bryan O'Sullivan" <bo...@se...> To: "Daniel Miller (IMI)" <da...@im...> Cc: "Robert Walsh" <rj...@du...>; <val...@li...> Sent: Tuesday, September 28, 2004 11:49 Subject: Re: [Valgrind-users] improbably "uninitialized value" warning > On Tue, 2004-09-28 at 10:46 -0700, Daniel Miller (IMI) wrote: > > Okay, I added > > char xbuf = 0 ; > > to the beginning of get_number_of_luns(). I understand now that valgrind > > doesn't realize that xbuf will be initialized unless usb_control_msg() > > returned negative value, and in either case get_number_of_luns() will return > > a valid value. So I'll have to add unnecessary initialization code to quiet > > valgrind, tho it isn't needed by the actual application. > > Why do you think get_number_of_luns is returning a valid value in xbuf? > It is quite possible that it is not. Since I assuming you're using > libusb, you should check the source and find out. > > > Are there some kind of conditional compile flags that I can use to remove > > such code when I'm not going to run valgrind (similar to the #ifdef _lint > > for lint), so I don't always have this extra code installed? > > Yes, you can use #ifdef NVALGRIND. However, if you're talking about > setting a char value to zero, there's no reason to avoid it. > Agreed... I'm thinking more of some other functions which have larger buffers which I'm having to zero in order to clear valgrind warnings. OTOH, since these buffers are all in libusb, I suppose I don't have any guarantee that there aren't bugs in the code... so I probably *shouldn't* comment out the inits... |
|
From: Tom H. <th...@cy...> - 2004-09-28 18:24:18
|
In message <014101c4a581$a0840f70$0401a8c0@dan>
"Daniel Miller \(IMI\)" <da...@im...> wrote:
> static int get_number_of_luns(usb_dev_handle *udev)
> {
> char xbuf ;
> // swap bytes around because u16 fields in
> // usb_control_msg() are big-endian
> int result = usb_control_msg(udev, // handle
> 0xA1, // requesttype
> 0xFE, // request
> 0, // value
> 0, // index
> &xbuf, // data pointer
> 1, // length
> 5000) ; // timeout
> if (result < 0)
> return result;
> result = (int) (xbuf) + 1 ;
> return result;
> }
>
> The A1/FE control message returns one byte. So it doesn't look, to me, as
> though get_number_of_luns() can fail to return a value...
But where does use_control_msg get the value of xbuf from?
Given that this is obviously originating from a USB device it
is possible that there is some ioctl involved that valgrind
doesn't understand - do you get any warnings about ioctls?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Daniel M. \(IMI\) <da...@im...> - 2004-09-28 18:35:04
|
----- Original Message -----
From: "Tom Hughes" <th...@cy...>
To: <rj...@du...>; <da...@im...>
Cc: <val...@li...>
Sent: Tuesday, September 28, 2004 11:24
Subject: Re: [Valgrind-users] improbably "uninitialized value" warning
> In message <014101c4a581$a0840f70$0401a8c0@dan>
> "Daniel Miller \(IMI\)" <da...@im...> wrote:
>
> > static int get_number_of_luns(usb_dev_handle *udev)
> > {
> > char xbuf ;
> > // swap bytes around because u16 fields in
> > // usb_control_msg() are big-endian
> > int result = usb_control_msg(udev, // handle
> > 0xA1, // requesttype
> > 0xFE, // request
> > 0, // value
> > 0, // index
> > &xbuf, // data pointer
> > 1, // length
> > 5000) ; // timeout
> > if (result < 0)
> > return result;
> > result = (int) (xbuf) + 1 ;
> > return result;
> > }
> >
> > The A1/FE control message returns one byte. So it doesn't look, to me,
as
> > though get_number_of_luns() can fail to return a value...
>
> But where does use_control_msg get the value of xbuf from?
>
> Given that this is obviously originating from a USB device it
> is possible that there is some ioctl involved that valgrind
> doesn't understand - do you get any warnings about ioctls?
>
> Tom
Yeah, I get three of the following; I'm still trying to figure out what
0x4B30 is and what to do about them...
==29190== Warning: noted but unhandled ioctl 0x4B30 with no size/direction
hints
==29190== This could cause spurious value errors to appear.
==29190== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
proper wrapper.
However, the usb_control_msg ioctl is 0x5530, not 0x4B30. In any case, if
usb_control_msg fails to get its data, it typically returns -1, and I don't
use xbuf in that case, which is what I was referring to previously...
Dan
|
|
From: Tom H. <th...@cy...> - 2004-09-28 18:55:54
|
In message <014f01c4a589$da94bd60$0401a8c0@dan>
"Daniel Miller \(IMI\)" <da...@im...> wrote:
> Yeah, I get three of the following; I'm still trying to figure out what
> 0x4B30 is and what to do about them...
>
> ==29190== Warning: noted but unhandled ioctl 0x4B30 with no size/direction
> hints
> ==29190== This could cause spurious value errors to appear.
> ==29190== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
> proper wrapper.
>
> However, the usb_control_msg ioctl is 0x5530, not 0x4B30. In any case, if
> usb_control_msg fails to get its data, it typically returns -1, and I don't
> use xbuf in that case, which is what I was referring to previously...
The problem is that if that ioctl returns some data and valgrind
does't realise then it won't mark that data as defined and the
effects will propagate through your program.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-09-28 18:59:49
|
In message <014f01c4a589$da94bd60$0401a8c0@dan>
"Daniel Miller \(IMI\)" <da...@im...> wrote:
> Yeah, I get three of the following; I'm still trying to figure out what
> 0x4B30 is and what to do about them...
>
> ==29190== Warning: noted but unhandled ioctl 0x4B30 with no size/direction
> hints
> ==29190== This could cause spurious value errors to appear.
> ==29190== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a
> proper wrapper.
As far as I can see 0x4b30 is KDMKTONE from linux/kd.h.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Daniel M. \(IMI\) <da...@im...> - 2004-09-28 19:30:47
|
----- Original Message ----- From: "Tom Hughes" <th...@cy...> To: <rj...@du...>; <da...@im...> Cc: <val...@li...> Sent: Tuesday, September 28, 2004 11:59 Subject: Re: [Valgrind-users] improbably "uninitialized value" warning > In message <014f01c4a589$da94bd60$0401a8c0@dan> > "Daniel Miller \(IMI\)" <da...@im...> wrote: > > > Yeah, I get three of the following; I'm still trying to figure out what > > 0x4B30 is and what to do about them... > > > > ==29190== Warning: noted but unhandled ioctl 0x4B30 with no size/direction > > hints > > ==29190== This could cause spurious value errors to appear. > > ==29190== See README_MISSING_SYSCALL_OR_IOCTL for guidance on writing a > > proper wrapper. > > As far as I can see 0x4b30 is KDMKTONE from linux/kd.h. > YES!!! Thank you, and I *am* using the speaker in our application. I can just ignore that warning, I think. |
|
From: Paul P. <ppl...@gm...> - 2004-09-28 17:28:32
|
On Tue, 28 Sep 2004 16:44:27 +0000 (UTC), Daniel Miller
<da...@im...> wrote:
> some of these warnings are clearly spurious; a typical example is: [...]
> result is defined as int, and get_number_of_luns() returns int. So result
> cannot be uninitialized here.
Oh yes, it can!
Try this test case:
int foo() { int x; return x; } // returns "uninitialized" value
int main() {
int x = foo();
if (x) return 0;
return 1;
}
Cheers,
|
|
From: Tom H. <th...@cy...> - 2004-09-28 18:03:05
|
In message <Xns95726316C156Fdancarddupercom@80.91.229.5>
Daniel Miller <da...@im...> wrote:
> I'm using valgrind 2.2.0 for the first time, on a linux 2.6.7 system with
> gcc 3.3.4. I have optimizations set to -O. However, I'm getting *many*
> warnings about "Conditional jump or move depends on uninitialized value"...
> some of these warnings are clearly spurious; a typical example is:
>
> result = get_number_of_luns(udev) ;
> total_luns = (result <= 0) ? 1 : result ; // line 1449
>
> ==25533== Conditional jump or move depends on uninitialised value(s)
> ==25533== at 0x805AC84: find_dev_cap(unsigned) (imilib.cpp:1449)
>
> result is defined as int, and get_number_of_luns() returns int. So result
> cannot be uninitialized here.
It can be uninitialised ig get_number_luns() returns a value
that is not properly initialised.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dennis L. <pla...@gm...> - 2004-09-28 18:19:58
|
At 18:44 28.09.2004, you wrote: >==25533== Conditional jump or move depends on uninitialised value(s) >==25533== at 0x805AC84: find_dev_cap(unsigned) (imilib.cpp:1449) > >result is defined as int, and get_number_of_luns() returns int. So result >cannot be uninitialized here. Valgrind does not only check for uninitialized complete variables, but for single bits. You should check the get_number_of_luns() call where exactly the values come from, and if they are "initialized" by logical bit operations, which might leave even one bit unset... greets Dennis Carpe quod tibi datum est |