https://bugs.kde.org/show_bug.cgi?id=487862
Bug ID: 487862
Summary: memcheck does not believe that bytes on new pages are
Defined by brk() system call
Classification: Developer tools
Product: valgrind
Version: 3.23.0
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: jrei...@bitwagon.com
Target Milestone: ---
Created attachment 170032
--> https://bugs.kde.org/attachment.cgi?id=170032&action=edit
assembly-language test program for brk() system call
SUMMARY
On Linux, when the brk() system call adds new pages to the address space, then
those pages are guaranteed to be all-zero, but memcheck thinks the bytes are
Undefined.
STEPS TO REPRODUCE
1. Build the attached short assembly-language program brk-test.S for x86_64.
The program finds the next page boundary at or above "the .brk",
then uses system call brk() to append 345 bytes to "the .brk".
Linux must add one entire page, and guarantees that the page is all-zero.
2. Run under valgrind(memcheck) and note the complaint about Uninit value.
3. Comment-out the "jmp no_clear" instruction, re-build and re-run.
4. Note that the complaint disapears.
5. Use a debugger to single-step the two programs, examining memory to convince
yourself that the code to zero the added address space on a new page is
effectively a no-op.
OBSERVED RESULT
Step 2:
$ valgrind --track-origins=yes ./brk-test
==5737== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==5737== Command: ./brk-test
==5737==
==5737== Syscall param exit(status) contains uninitialised byte(s)
==5737== at 0x401051: ??? (in /home/jreiser/brk-test)
==5737== Uninitialised value was created
==5737== at 0x401039: ??? (brk-test.S:38) ## the third brk() syscall
Step 4: Note no complaint from memcheck
$ valgrind --track-origins=yes ./brk-test
==5768== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==5768== Command: ./brk-test
==5768==
==5768==
==5768== HEAP SUMMARY:
EXPECTED RESULT
No complaint from Step 2 (and thus no complaint in either case.)
SOFTWARE/OS VERSIONS
Windows:
macOS:
Linux/KDE Plasma:
$ uname -a
Linux fedora 6.8.10-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Fri May 17 21:20:54
UTC 2024 x86_64 GNU/Linux
$ rpm -q valgrind
valgrind-3.23.0-1.fc40.x86_64
(available in About System)
KDE Plasma Version:
KDE Frameworks Version:
Qt Version:
ADDITIONAL INFORMATION
The Go-lang runtime _dl_early_allocate uses initialization code like this when
-static binding. Thus memcheck can generate many many false-positive
complaints from many different tracebacks.
--
You are receiving this mail because:
You are watching all bug changes.
