On 05/07/2018 12:56 AM, Jan Engelhardt wrote:
On Monday 2018-05-07 05:20, David C. Rankin wrote:
I have filed https://bugzilla.opensuse.org/show_bug.cgi?id=1092054 against
The valgrind report is completely correct.
If it is reporting 1028 bytes allocated for 1-integer, it is most certainly NOT correct.
You can drop the act - you are doing more than "just" allocating one puny integer buffer. *Besides* the printf which was pointed out to you in bugzilla, given just the right laboratory conditions (ulimit -v somethingsomething), I can make your 5-liner program exhibit undefined behavior, at which point a program is allowed to do anything — that, by definition, can include allocations.
There is no act Jan, frustration perhaps at people dancing around the issue of: All prior releases, valgind reports: 1-allocation, 4-bytes -- which is 100% correct. Now on leap 15, the same code reports 2-allocations, 1028-bytes -- which is not correct. What does your comment about a hypothetical ulimit change have to do with this current valgrind issue? SuSE, the openSuSE releases from the beginning through Leap 42.3 all report: 1-allocation, 4-bytes -- which is 100% correct. Leap 15 reports 2-allocations, 1028-bytes -- which is not correct. If you are saying, "Well, nobody is going to fix it, so valgind may report a few extra allocations and the bytes reported as allocated will no longer have any relation to the allocation the user makes." Then that fine, we will just have a degraded and much less useful valgrind that have ever existed before. One of the 2 differing behaviors is wrong, and it doesn't take a rocket-scientist to tell which one (although I am qualified in that regard as well) Have you tested on both Leap 42.3 and the Leap 15?? If you have, then Why does valgrid give different output between them. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org