Find a better solution for valgrind uninitialized memory issues (false-positives?) that were uncovered by bug 1593951.
Categories
(Core :: CSS Parsing and Computation, task, P3)
Tracking
()
People
(Reporter: emilio, Unassigned)
References
Details
Attachments
(1 obsolete file)
See these failures.
I did some manual auditing of the fields that were reported and they are all constructed / copy-constructed properly, but there are way too many uses of them so it seems bad to whitelist them all...
Julian, is there a good path forward for this kind of thing? Is it really a bug? I don't see how we're using uninitialized memory here. That bug landed with a couple fixes that were uncovered by other assertions in the tree, but I took a look and all the fields of e.g., nsStyleDisplay, the only struct touched from the std::_Function_handler / operator / mozilla::FrameLayerBuilder::EnumerateGenerationForDedicatedLayers caller, and they are all properly initialized / copied.
|
Reporter | |
Updated•6 years ago
|
|
||
Comment 1•6 years ago
|
||
Emilio, hi. I don't know that this is directly related, but: I have been working to fix the most problematic kinds of false positives remaining. These affect both C++ and Rust code. See [1]. I'll look into this.
[1] https://internals.rust-lang.org/t/valgrind-memcheck-false-positive-fixes-for-rust/11166.
|
|
Reporter | |
Comment 2•6 years ago
|
||
Thanks Julian, that's awesome. To reproduce in Gecko you should only need to remove the two ptr::write_bytes calls that reference this bug:
|
||
Updated•3 years ago
|
|
|
||
Updated•3 years ago
|
|
|
||
Updated•2 years ago
|
Description
•