esger.abbink_ Posted October 31, 2017 Share Posted October 31, 2017 (edited) 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 October 31, 2017 by esger.abbink Link to comment
silent Posted November 1, 2017 Share Posted November 1, 2017 Hi Esger, I believe we've fixed some UB issues in latest release, but not all of them for sure. Could you please tell us your valgrind launch command so we can check it on our side as well? Thanks! How to submit a good bug report --- FTP server for test scenes and user uploads: ftp://files.unigine.com user: upload password: 6xYkd6vLYWjpW6SN Link to comment
esger.abbink_ Posted November 1, 2017 Author Share Posted November 1, 2017 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
Recommended Posts