https://bugs.winehq.org/show_bug.cgi?id=47125
Bug ID: 47125 Summary: Preloader fails to reserve a memory range when running under valgrind. Product: Wine Version: 4.7 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jeffersoncarpenter2@gmail.com Distribution: ---
Created attachment 64340 --> https://bugs.winehq.org/attachment.cgi?id=64340 Valgrind output
Exact steps to reproduce:
$ git clone git://source.winehq.org/git/wine.git
$ mkdir wine_build && cd wine_build $ ../wine/configure --enable-win64 CFLAGS="-Og -g" $ make $ cd ..
$ mkdir test_program && cd test_program $ echo 'int main() { return 0; }' > main.c $ x86_64-w64-mingw32-gcc main.c -o main.exe $ valgrind --trace-children=yes ../wine_build/loader/wine64 main.exe ... preloader: Warning: failed to reserve range 0000000000110000-0000000068000000 ...
When running under valgrind, the preloader fails to reserve the memory range and prints this warning. When not running under valgrind, no such warning is printed.
https://bugs.winehq.org/show_bug.cgi?id=47125
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase, | |valgrind CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47125
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Preloader fails to reserve |Preloader fails to reserve |a memory range when running |a memory range when running |under valgrind. |under valgrind
--- Comment #1 from Austin English austinenglish@gmail.com --- Similar occurs under win32: preloader: Warning: failed to reserve range 00110000-68000000 preloader: Warning: failed to reserve range 7f000000-82000000
Does it actually cause a problem? I'm fairly certain that's expected behavior.
https://bugs.winehq.org/show_bug.cgi?id=47125
--- Comment #2 from jeffersoncarpenter2@gmail.com --- (In reply to Austin English from comment #1)
Does it actually cause a problem? I'm fairly certain that's expected behavior.
Expected behavior for what reason? I don't know if this is a problem (valgrind fails to recognize an instruction later and kills the program, then there's an invalid write reported from the SIGILL handler), but if it were expected and correct behavior, then why print a warning?
https://bugs.winehq.org/show_bug.cgi?id=47125
--- Comment #3 from Austin English austinenglish@gmail.com --- (In reply to jeffersoncarpenter2 from comment #2)
(In reply to Austin English from comment #1)
Does it actually cause a problem? I'm fairly certain that's expected behavior.
Expected behavior for what reason? I don't know if this is a problem (valgrind fails to recognize an instruction later and kills the program, then there's an invalid write reported from the SIGILL handler), but if it were expected and correct behavior, then why print a warning?
From loader/preloader.c:
* To do this, we implement our own shared object loader that reserves memory * that is important to Wine, and then loads the main binary and its ELF * interpreter. * * We will try to set up the stack and memory area so that the program that * loads after us (eg. the wine binary) never knows we were here, except that * areas of memory it needs are already magically reserved. * * The following memory areas are important to Wine: * 0x00000000 - 0x00110000 the DOS area * 0x80000000 - 0x81000000 the shared heap * ??? - ??? the PE binary load address (usually starting at 0x00400000)
https://bugs.winehq.org/show_bug.cgi?id=47125
--- Comment #4 from jeffersoncarpenter2@gmail.com --- (In reply to Austin English from comment #3)
(In reply to jeffersoncarpenter2 from comment #2)
Expected behavior for what reason? I don't know if this is a problem (valgrind fails to recognize an instruction later and kills the program, then there's an invalid write reported from the SIGILL handler), but if it were expected and correct behavior, then why print a warning?
From loader/preloader.c:
To do this, we implement our own shared object loader that reserves memory
that is important to Wine, and then loads the main binary and its ELF
interpreter.
We will try to set up the stack and memory area so that the program that
loads after us (eg. the wine binary) never knows we were here, except that
areas of memory it needs are already magically reserved.
The following memory areas are important to Wine:
0x00000000 - 0x00110000 the DOS area
0x80000000 - 0x81000000 the shared heap
??? - ??? the PE binary load address (usually starting at
0x00400000)
Nonetheless, there's a reason why the region(s) can't be mapped under Valgrind, and I'd like to know what that is.
https://bugs.winehq.org/show_bug.cgi?id=47125
--- Comment #5 from jeffersoncarpenter2@gmail.com --- The request bounces in Valgrind's mmap2 implementation (syswrap-generic.c). The requested range 0x110000-0x68000000 would trample Valgrind's memcheck-amd64-linux image which is loaded starting at 0x58000000. On my machine, sed -i 's/0x58000000/0x68000000/' configure.ac before building valgrind is sufficient
https://bugs.winehq.org/show_bug.cgi?id=47125
--- Comment #6 from jeffersoncarpenter2@gmail.com --- The mmap2 calls that the preloader uses to reserve the regions are bounced in valgrind because they would clobber parts of its process image. Running sed -i 's/0x58000000/0x68000000/' configure.ac before compiling valgrind clears some of the warnings, but doing that is arbitrary. Valgrind also uses mmap(NULL, ...) to allocate heap memory, which too collides with Wine's attempted preloads.
Sorry for the double post -- Links is touchy.
https://bugs.winehq.org/show_bug.cgi?id=47125
--- Comment #7 from jeffersoncarpenter2@gmail.com --- Do you think we should close this bug report? I would be partial to closing it. To fix this is general would require significant changes to Valgrind internals.
https://bugs.winehq.org/show_bug.cgi?id=47125
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #8 from Austin English austinenglish@gmail.com --- (In reply to jeffersoncarpenter2 from comment #7)
Do you think we should close this bug report? I would be partial to closing it. To fix this is general would require significant changes to Valgrind internals.
Yeah, I'd say so. I was hoping others would chime in, but in any event, I'm almost certain this is invalid.
Glad to see more people interested in wine and valgrind though :)
https://bugs.winehq.org/show_bug.cgi?id=47125
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED CC| |nerv@dawncrow.de
--- Comment #9 from André H. nerv@dawncrow.de --- closing invalid
-
wine-bugs＠winehq.org -
WineHQ Bugzilla