valgrind-users

[Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,

I was running mozilla TB and found a message during a test run


==20163== Conditional jump or move depends on uninitialised value(s)
==20163==    at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
  ...

so there is an uninitialized usage.

In this particular instance, I  realized that it would be really great
to know the value of this uninitialized memory (turns out to be
automatic variable on the stack.)
so that I can learn what has happened to the subsequent processing.
Can the uninitialized value was zero or not, for example?

Can valgrind print value of used uninitialized memory location, say,
something along the suggested manner below?

I use the above example:

  ==20163== Conditional jump or move depends on uninitialised value(s)
  ==20163== The value used was: 0xdeadbeaf (4 bytes)
  ==20163==    at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
  ...

or maybe considering the possibility of byte block:

  ==20163== Conditional jump or move depends on uninitialised value(s)
  ==20163== The value used started with 0xde 0xad 0xbe 0xaf 0xaa 0xbb
0xcc ... (up to the minimum of first N octets or the size of the data,
maybe N can be 16 , etc.)
  ==20163==    at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)

I believe this simple addition makes the detection very useful
because it would make creating the suggested patch easier by knowing
why a program that has been used so long had a hidden issue for so many
years.

Thank you for sharing this great tool with the programming community.

Best Regards,
Chiaki Ishikawa

Re: [Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

[Maurice v. S. <ma...@bl...>]

Hi Chiaki, 

If you use --track-origins=yes, then valgrind will report where the variable was first allocated (or put on the stack). 

That's usually enough to figure out which it is. 

][ Maurice van Swaaij, Blue Sky Studios ][ 

----- Original Message -----

| From: "chiaki ISHIKAWA" <ish...@yk...>
| To: val...@li...
| Sent: Thursday, April 23, 2015 12:13:38 PM
| Subject: [Valgrind-users] Can valgrind print the used "uninitialized
| value" and its size?

| Hi,

| I was running mozilla TB and found a message during a test run

| ==20163== Conditional jump or move depends on uninitialised value(s)
| ==20163== at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
| void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
| ...

| so there is an uninitialized usage.

| In this particular instance, I realized that it would be really great
| to know the value of this uninitialized memory (turns out to be
| automatic variable on the stack.)
| so that I can learn what has happened to the subsequent processing.
| Can the uninitialized value was zero or not, for example?

| Can valgrind print value of used uninitialized memory location, say,
| something along the suggested manner below?

| I use the above example:

| ==20163== Conditional jump or move depends on uninitialised value(s)
| ==20163== The value used was: 0xdeadbeaf (4 bytes)
| ==20163== at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
| void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)
| ...

| or maybe considering the possibility of byte block:

| ==20163== Conditional jump or move depends on uninitialised value(s)
| ==20163== The value used started with 0xde 0xad 0xbe 0xaf 0xaa 0xbb
| 0xcc ... (up to the minimum of first N octets or the size of the
| data,
| maybe N can be 16 , etc.)
| ==20163== at 0x90974BC: nsJSObjWrapper::NP_SetProperty(NPObject*,
| void*, _NPVariant const*) (nsJSNPRuntime.cpp:137)

| I believe this simple addition makes the detection very useful
| because it would make creating the suggested patch easier by knowing
| why a program that has been used so long had a hidden issue for so
| many
| years.

| Thank you for sharing this great tool with the programming community.

| Best Regards,
| Chiaki Ishikawa

| ------------------------------------------------------------------------------
| BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
| Develop your own process in accordance with the BPMN 2 standard
| Learn Process modeling best practices with Bonita BPM through live
| exercises
| http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
| event?utm_
| source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
| _______________________________________________
| Valgrind-users mailing list
| Val...@li...
| https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

[Philippe W. <phi...@sk...>]

On Fri, 2015-04-24 at 01:13 +0900, ISHIKAWA,chiaki wrote:

> Can valgrind print value of used uninitialized memory location, say,
> something along the suggested manner below?
I am not a specialist in the way memcheck does all that,
but at first sight, I do not see major difficulties to implement that.
However, as far as I can see, it would imply to add a new PARAM to all
the error reporting helpers, which means the generated code will
grow and/or be less efficient. Growing the generated code just for
that seems not that attractive.

As an alternative, when an error is encountered, you can debug
your program (using vgdb) at the moment of the error, and e.g.
examine the value of the variables and/or the definedness of
what is used in the conditional jump.

Philippe

Re: [Valgrind-users] Can valgrind print the used "uninitialized value" and its size?

[ISHIKAWA,chiaki <ish...@yk...>]

Hi,

On 2015/04/24 4:10, Philippe Waroquiers wrote:
> On Fri, 2015-04-24 at 01:13 +0900, ISHIKAWA,chiaki wrote:
>
>> Can valgrind print value of used uninitialized memory location, say,
>> something along the suggested manner below?
> I am not a specialist in the way memcheck does all that,
> but at first sight, I do not see major difficulties to implement that.
> However, as far as I can see, it would imply to add a new PARAM to all
> the error reporting helpers, which means the generated code will
> grow and/or be less efficient. Growing the generated code just for
> that seems not that attractive.

I see. I thought it was simply adding some print code somewhere and 
knowledgeable person could do this in a matter of a day, but
I did not realize there is this size/speed implications.

>
> As an alternative, when an error is encountered, you can debug
> your program (using vgdb) at the moment of the error, and e.g.
> examine the value of the variables and/or the definedness of
> what is used in the conditional jump.

I will try this approach with this particular issue I found lately.

> Philippe

Thank you for the pointers.

Chiaki