Jump to content

environment modification & uninitialised members (valgrind)


photo

Recommended Posts

Hi,

using valgrind we ran into a number of errors produced in Unigine itself. We resolved most of the ones we currently see:

- getenv does an invalid read due to memory corruption. It is not allowed for multithreaded programs to modify the environment, however in EnginePlugins.cpp a putenv call is done adding a variable to the environment. This conflicts with an addition done by valgrind causing memory corruption. Every subsequent getenv call (and they are many) causes an error.

- in many cases class and struct members are not fully initialised causing "Conditional jump or move depends on uninitialised value(s)" errors. Examples that caused errors for us:

  • Physics::time_residue 
  • Render::taa_frame
  • Variable::int_v (?)

Note that these are just a few examples and that we probably have not hit all paths leading to errors.

Our own possible errors disappear between the dozens of (mostly) irrelevant errors. So most of the time we end up tracing and fixing the Unigine errors as well to get as clean a slate as possible. However this is often very time consuming (even with --track-origins) and not really efficient.

Please fix and might I suggest a policy of religiously  'always initialise Everything Everywhere Everytime' ;)

 

(I'd be happy to provide our valgrind logs)

Edited by esger.abbink
Link to comment

Hi Silent,

we don't use anything esoteric: valgrind --track-origins=yes, with sometimes --error-limit=no or --num-callers=50

Keep in mind that valgrind will not complain about memory being uninitialised, even when said memory is being copied around (there are legitimate reasons that could be perfectly fine). It will only complain if an uninitialised value is being *used* inapropriately, ie. in an if statement. That means that even if valgrind gives you a clean slate of health *now*, using the same code in a different way could uncover alternate paths where there still are errors. This is especially the case of course for library code. It is clearly impossible for you to test all possible paths through your code that your customers can conceive of. Hence the religious policy: initialising every member, local and global variable always should eliminate any alternate paths you are not able to test from causing errors. Or at the very least diminish the number of errors to a fraction.

Link to comment
×
×
  • Create New...