|
From: Brendan D. <bre...@pe...> - 2006-05-22 20:50:05
|
I'm using Valgrind 3.1 to try to debug a video hook for ffmpeg. Valgrind complains (very confusingly) about uninitialized values being used --- this is pretty much impossible (at least to the best of my knowledge): each class instance is initialized either from defaults (global const variables), via a copy (I've checked the copy constructor several times to be absolutely certain that all the fields are being copied over. It's possible that I've missed something, but I seriously doubt it), or via a configuration object (where the values are either read in from file or use the same defaults that the default constructor uses). There are two variables that are used on the line that generates the error: confidence and m_TauConfidence. confidence is passed by reference and ultimately lives on the stack, m_TauConfidence is a member variable. Prior to the test, confidence is computed using pixel intensities ultimately supplied by FFmpeg (FFmpeg decodes the current frame, passes it to my hook, then passes the results on to the encoder). m_TauConfidence is written precisely once (and that's when the instance is constructed). Needless to say, I'm confused as to how these values are considered uninitialized, unless the data coming from the input frame is uninitialized. Regardless, it would be really helpful to know which of these values is actually uninitialized. Second issue that I'm fighting with: I seem to be suffering from stack corruption when running this hook. Is there anyway to use Valgrind to try to figure this out? Ideally, I'd like to make sure that every time I jump into a function call or return from a function call, the relevant addresses are valid and at least plausible. I have no idea what support there is for tracking valid return addresses during function calls might be in place. I suspect that this is probably going to be language dependent, which means probably outside the scope of Valgrind. Any thoughts? Thanks much, Brendan. -- Brendan Drew Research Scientist PercepTek, Inc. 12395 North Mead Way Littleton, CO 80125 Tel: 720-344-1037 x 126 Fax: 720-344-2360 |
|
From: Tom H. <to...@co...> - 2006-05-22 23:06:57
|
In message <447...@pe...>
Brendan Drew <bre...@pe...> wrote:
> I'm using Valgrind 3.1 to try to debug a video hook for ffmpeg. Valgrind
> complains (very confusingly) about uninitialized values being used ---
> this is pretty much impossible (at least to the best of my knowledge):
> each class instance is initialized either from defaults (global const
> variables), via a copy (I've checked the copy constructor several times
> to be absolutely certain that all the fields are being copied over. It's
> possible that I've missed something, but I seriously doubt it), or via a
> configuration object (where the values are either read in from file or
> use the same defaults that the default constructor uses). There are two
> variables that are used on the line that generates the error: confidence
> and m_TauConfidence. confidence is passed by reference and ultimately
> lives on the stack, m_TauConfidence is a member variable. Prior to the
> test, confidence is computed using pixel intensities ultimately supplied
> by FFmpeg (FFmpeg decodes the current frame, passes it to my hook, then
> passes the results on to the encoder). m_TauConfidence is written
> precisely once (and that's when the instance is constructed). Needless
> to say, I'm confused as to how these values are considered
> uninitialized, unless the data coming from the input frame is
> uninitialized. Regardless, it would be really helpful to know which of
> these values is actually uninitialized.
So put some VALGRIND_CHECK_READABLE() calls in the source to see
which one is the problem.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2006-05-23 11:58:56
|
> So put some VALGRIND_CHECK_READABLE() calls in the source to see > which one is the problem. Or VALGRIND_CHECK_DEFINED, which is a convenience wrapper around VALGRIND_CHECK_READABLE, iirc. Also, try using (on x86) the latest sources from svn. They have some extra refinements to further reduce the false positive rate. See http://www.valgrind.org/downloads/repository.html for details of how to check out / build. J |
|
From: Dennis L. <pla...@in...> - 2006-05-23 12:14:28
|
Hi, tracking down uninitialized values is quite hard, but valgrind has a very low rate of false positives due to the fact that i reports them only at the point where something else depends on them (often compilers copy uninitialized values around, validly, since nothing depends on them). This often leads to confusion, since from the point initialized to the point where the value is used, some unitialized value from some other origin slipped in. My usual best way to handle this is to do valgrind client request (wrapped up behind some nicer template interface for C++) to check for initialized data. If you are using C/C++ and have gcc 4.1 or newer, you should also give libmudflap a try, its integrated into gcc and instruments the code, and can check for a few stack based errors. the disadvantage though is you have to compile your program with special options. greets Dennis Am Montag, den 22.05.2006, 14:50 -0600 schrieb Brendan Drew: > I'm using Valgrind 3.1 to try to debug a video hook for ffmpeg. Valgrind > complains (very confusingly) about uninitialized values being used --- > this is pretty much impossible (at least to the best of my knowledge): > each class instance is initialized either from defaults (global const > variables), via a copy (I've checked the copy constructor several times > to be absolutely certain that all the fields are being copied over. It's > possible that I've missed something, but I seriously doubt it), or via a > configuration object (where the values are either read in from file or > use the same defaults that the default constructor uses). There are two > variables that are used on the line that generates the error: confidence > and m_TauConfidence. confidence is passed by reference and ultimately > lives on the stack, m_TauConfidence is a member variable. Prior to the > test, confidence is computed using pixel intensities ultimately supplied > by FFmpeg (FFmpeg decodes the current frame, passes it to my hook, then > passes the results on to the encoder). m_TauConfidence is written > precisely once (and that's when the instance is constructed). Needless > to say, I'm confused as to how these values are considered > uninitialized, unless the data coming from the input frame is > uninitialized. Regardless, it would be really helpful to know which of > these values is actually uninitialized. > > Second issue that I'm fighting with: I seem to be suffering from stack > corruption when running this hook. Is there anyway to use Valgrind to > try to figure this out? Ideally, I'd like to make sure that every time I > jump into a function call or return from a function call, the relevant > addresses are valid and at least plausible. I have no idea what support > there is for tracking valid return addresses during function calls might > be in place. I suspect that this is probably going to be language > dependent, which means probably outside the scope of Valgrind. Any thoughts? > > Thanks much, > > Brendan. > |