undefined | Better HN

0 pointsjulian-klode4mo ago0 comments

It's certainly what we aim for in APT. We do have an overwrite of course, since we need to copy uninitiated data around: The cache file is allocated as a whole and written at the end, but not all parts of it are used, but it triggers stuff.

Don't want to introduce complex code to only copy the parts that are actually reachable would be silly and introduce bugs.

But keep in mind valgrind is super buggy and we spend quite a bunch of time working around valgrind false positives (outside of amd64)

0 comments

paulf384mo ago

TBH most “false positives” that I investigate are wishful thinking or the result of ignorance of what is really happening. It looks like you are using Debian. That probably doesn’t help. Here is a typical Debian “bug” report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778

10 years old. It never was a false positive. It was fixed a good few years ago. The fix did not involve suppressing the error.

Valgrind does need a lot of work, especially for missing CPU features and for Darwin. I’m not aware of many memcheck bugs that aren’t relatively obscure corner cases.

If you have encountered bugs please report them to https://bugs.kde.org.

julian-klodeOP4mo ago

Like the last one was/is the inability to comprehend safety of large buffers on ppc64el because the stack clash protector code generated by gcc isn't understood. The one before that was more problems of that sort on armhf where it also didn't understand the clash protector - in more cases.

It's quite surprising and it takes days to weeks to debug each of these, going down to the assembler level and verifying that by hand.

j / k navigate · click thread line to collapse