|
From: Tom H. <to...@co...> - 2007-12-20 18:47:22
|
I have recently been working on trying to get valgrind and wine to work together and have run into a rather nasty problem. I've read Dan Kegel's information at http://wiki.winehq.org/Wine_and_Valgrind and looked at his patch but it doesn't address the issue I'm having. The basic problem is that windows applications like to load at a relatively low address but because the PE windows executable is loaded by an ELF executable (wine) it needs to make sure that wine itself has not been loaded in an inconvenient place. So the wine folks do much the same as we do - wine-preloader is run, which is a static executable linked to load at a high address. That then mmaps everything from 0 up to 1.5Gb before acting as an ELF loader and loading the real wine executable and it's shared libraries into memory and transferring control. The problem of course is that under valgrind the wine preloader fails to map that low address space (if for no other reason than that valgrind is in the middle of it!) and so when it starts loading wine there is a risk that some of will wind up in the place where wine will want to load the windows executable. In my case the problem was actually libwine.so, which the prelinker had chosen to load in exactly the wrong place ;-) Does anybody have any brilliant solutions to this? Have you ever seen this problem Dan? Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Dan K. <da...@ke...> - 2007-12-20 19:04:26
|
On Dec 20, 2007 10:47 AM, Tom Hughes <to...@co...> wrote: > I have recently been working on trying to get valgrind and wine to > work together Yay! > I've read Dan Kegel's information at > http://wiki.winehq.org/Wine_and_Valgrind and looked at his patch but > it doesn't address the issue I'm having. It's not my patch - I'm just providing a rediff of a rollup of a patch from Eric Pouech and maybe Adam Gundy; the origins are lost in the sands of time :-) > The problem of course is that under valgrind the wine preloader fails > to map that low address space (if for no other reason than that > valgrind is in the middle of it!) and so when it starts loading wine > there is a risk that some of will wind up in the place where wine will > want to load the windows executable. > > In my case the problem was actually libwine.so, which the prelinker > had chosen to load in exactly the wrong place ;-) I've noticed warnings about the wine preloader not getting its way, but so far they haven't annoyed me too much, I must be lucky. (I'm also not really too worried about whether valgrind works on individual apps yet, as I'm still mostly just running it on the entire wine test suite, and am happy when I get meaningful results for 90% of that.) - Dan |
|
From: Julian S. <js...@ac...> - 2007-12-21 01:27:13
|
> So the wine folks do much the same as we do - wine-preloader is run, > which is a static executable linked to load at a high address. That > then mmaps everything from 0 up to 1.5Gb before acting as an ELF > loader and loading the real wine executable and it's shared libraries > into memory and transferring control. What happens if you change V's load address to say 0x90000000 (by messing with valt_load_address_normal in configure.in) ? J |
|
From: Robert W. <rj...@du...> - 2007-12-21 02:07:40
|
I wonder if Valgrind needs to have the Wine loader built in? Regards, Robert. On Dec 20, 2007, at 5:26 PM, Julian Seward <js...@ac...> wrote: > >> So the wine folks do much the same as we do - wine-preloader is run, >> which is a static executable linked to load at a high address. That >> then mmaps everything from 0 up to 1.5Gb before acting as an ELF >> loader and loading the real wine executable and it's shared libraries >> into memory and transferring control. > > What happens if you change V's load address to say 0x90000000 > (by messing with valt_load_address_normal in configure.in) ? > > J > > --- > ---------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <to...@co...> - 2007-12-21 09:03:55
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> So the wine folks do much the same as we do - wine-preloader is run,
>> which is a static executable linked to load at a high address. That
>> then mmaps everything from 0 up to 1.5Gb before acting as an ELF
>> loader and loading the real wine executable and it's shared libraries
>> into memory and transferring control.
>
> What happens if you change V's load address to say 0x90000000
> (by messing with valt_load_address_normal in configure.in) ?
I did actually try that but it didn't help much as valgrind stuck
a block of SkAnonV memory below 0x60000000 which still stopped wine's
preloader reserving that memory :-(
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2007-12-21 10:12:32
|
In message <d82...@ma...>
Tom Hughes <to...@co...> wrote:
> I have recently been working on trying to get valgrind and wine to
> work together and have run into a rather nasty problem.
Unprelinking libwine has temporarily got me past the other problem, and
sorting out the trapno issue in signal handlers that the patch on the
wine wiki addresses then gets me to this failure:
--13050-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
--13050-- si_code=2; Faulting address: 0xBEEF0007; sp: 0x469CC4C
valgrind: the 'impossible' happened:
Killed by fatal signal
==13050== at 0x380293B3: vgPlain_get_StackTrace2 (m_stacktrace.c:153)
==13050== by 0x380294DB: vgPlain_get_StackTrace (m_stacktrace.c:437)
==13050== by 0x380164E2: vgPlain_record_ExeContext (m_execontext.c:300)
==13050== by 0x380025AE: create_MC_Chunk (mc_malloc_wrappers.c:141)
==13050== by 0x38002C17: vgMemCheck_new_block (mc_malloc_wrappers.c:211)
==13050== by 0x3800305C: vgMemCheck_malloc (mc_malloc_wrappers.c:226)
==13050== by 0x38034E47: do_client_request (scheduler.c:1277)
==13050== by 0x38036387: vgPlain_scheduler (scheduler.c:987)
==13050== by 0x38049C28: run_a_thread_NORETURN (syswrap-linux.c:89)
Now the fault address is obviously a little "suspicious" to say the
least... Should we not be a bit more careful when doing frame pointer
based unwinds on x86 though and just give up if we get a segv?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Eric P. <eri...@or...> - 2007-12-23 13:36:27
|
Tom Hughes a écrit : > In message <d82...@ma...> > Tom Hughes <to...@co...> wrote: > > >> I have recently been working on trying to get valgrind and wine to >> work together and have run into a rather nasty problem. >> > > Unprelinking libwine has temporarily got me past the other problem, and > sorting out the trapno issue in signal handlers that the patch on the > wine wiki addresses then gets me to this failure: > > --13050-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting > --13050-- si_code=2; Faulting address: 0xBEEF0007; sp: 0x469CC4C > > valgrind: the 'impossible' happened: > Killed by fatal signal > ==13050== at 0x380293B3: vgPlain_get_StackTrace2 (m_stacktrace.c:153) > ==13050== by 0x380294DB: vgPlain_get_StackTrace (m_stacktrace.c:437) > ==13050== by 0x380164E2: vgPlain_record_ExeContext (m_execontext.c:300) > ==13050== by 0x380025AE: create_MC_Chunk (mc_malloc_wrappers.c:141) > ==13050== by 0x38002C17: vgMemCheck_new_block (mc_malloc_wrappers.c:211) > ==13050== by 0x3800305C: vgMemCheck_malloc (mc_malloc_wrappers.c:226) > ==13050== by 0x38034E47: do_client_request (scheduler.c:1277) > ==13050== by 0x38036387: vgPlain_scheduler (scheduler.c:987) > ==13050== by 0x38049C28: run_a_thread_NORETURN (syswrap-linux.c:89) > > Now the fault address is obviously a little "suspicious" to say the > least... Should we not be a bit more careful when doing frame pointer > based unwinds on x86 though and just give up if we get a segv? > > Tom > > that's why there's another patch on the Wine wiki to ask valgrind to explicit check the stack frames against the stacks that a given program dares to give (which valgrind doesn't do at the moment) this is likely the same kind of behavior that J Reiser tries to fix in his fixes for UML support under valgrind IIRC, in WIne's case, this is needed for two reasons : 1/ the stack unwind (in generic cases) cannot be terminated properly (likely Wine misses a watchdog at stack's top) 2/ but also nasty 16/32 bits stack switches for some emulations even if 1/ could be worked around in wine, 2/ is anyway a showstopper I'd really like to see better stack unwinding protection in valgrind A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams) |
|
From: Tom H. <to...@co...> - 2007-12-23 19:10:32
|
On 23/12/2007, Eric Pouech <eri...@or...> wrote: > Tom Hughes a =E9crit : > > In message <d82...@ma...= > > > Tom Hughes <to...@co...> wrote: > > > >> I have recently been working on trying to get valgrind and wine to > >> work together and have run into a rather nasty problem. > > > > Unprelinking libwine has temporarily got me past the other problem > > which Linux distro are you using (it does work under some configurations)= ? Fedora 8. > > , and > > sorting out the trapno issue in signal handlers that the patch on the > > wine wiki addresses then gets me to this failure: > > > > --13050-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSE= GV) - exiting > > --13050-- si_code=3D2; Faulting address: 0xBEEF0007; sp: 0x469CC4C > > > > valgrind: the 'impossible' happened: > > Killed by fatal signal > > =3D=3D13050=3D=3D at 0x380293B3: vgPlain_get_StackTrace2 (m_stacktra= ce.c:153) > > =3D=3D13050=3D=3D by 0x380294DB: vgPlain_get_StackTrace (m_stacktrac= e.c:437) > > =3D=3D13050=3D=3D by 0x380164E2: vgPlain_record_ExeContext (m_execon= text.c:300) > > =3D=3D13050=3D=3D by 0x380025AE: create_MC_Chunk (mc_malloc_wrappers= .c:141) > > =3D=3D13050=3D=3D by 0x38002C17: vgMemCheck_new_block (mc_malloc_wra= ppers.c:211) > > =3D=3D13050=3D=3D by 0x3800305C: vgMemCheck_malloc (mc_malloc_wrappe= rs.c:226) > > =3D=3D13050=3D=3D by 0x38034E47: do_client_request (scheduler.c:1277= ) > > =3D=3D13050=3D=3D by 0x38036387: vgPlain_scheduler (scheduler.c:987) > > =3D=3D13050=3D=3D by 0x38049C28: run_a_thread_NORETURN (syswrap-linu= x.c:89) > > > > Now the fault address is obviously a little "suspicious" to say the > > least... Should we not be a bit more careful when doing frame pointer > > based unwinds on x86 though and just give up if we get a segv? > > > looks like a 16bit stack address, erroneously translated to a 32bit addre= ss > which program are you trying to run ? not a 16bit I hope Absolutely anything I think - even the wine supplied notepad... Tom --=20 Tom Hughes (to...@co...) http://www.compton.nu/ |