I use a LD_PRELOAD before running wine so that i can debug my application.
The library which is preloaded is able to replace system dlsym and from that, other consequence library call.
There is no problem until, i put some Detour code(hot patching) into the kernel32.dll.so address space. But the very funny things is this ** THE PROGRAM CRASHES BEFORE MY HOTPATCH IS APPLIED **
so it seems somehow the order of cause and effect is extremely weird and frightening to me. How can a piece of code which is not excecuted be teh cause for errors PRIOR/BEFORE to its execution. And this is surely happening because when i uncomment the Hotpatch/detour lines the problem goes away.
here are some lines from the crashs ...
err:module:attach_process_dlls "user32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\windows\system32\winemenubuilder.exe" failed, status c0000005 wine: Unhandled page fault on execute access to 0x7c9e4cd7 at address 0x7c9e4cd7 (thread 000b), starting debugger... err:module:DelayLoadFailureHook failed to delay load user32.dll.BroadcastSystemMessageW wine: Call from 0x7b83ba92 to unimplemented function user32.dll.BroadcastSystemMessageW, aborting wine: Unimplemented function user32.dll.BroadcastSystemMessageW called at address 0x7b83ba92 (thread 001d), starting debugger...
Another thing to notice is that this was tested using wine1.4.1
However it DOES work with wine1.5.10 ... to get something to work for me is not the challenge, its to understand the logic behind why something does not.
THanks a lot and I am grateful for any who contributes his knowledge to this problem i am a real NOVICE
On 03/07/2013 08:53 PM, Graham wrote:
<snip> Another thing to notice is that this was tested using wine1.4.1
However it DOES work with wine1.5.10 [...]
<snip>
If it works with the latest version, it means there was a bug and we fixed it. Each commit is as small as possible to ease the identification of the issue when we need to do a regresssion testing. So, if you want to know what commit fixed the issue and what was the issue, follow the guide : http://wiki.winehq.org/RegressionTesting
Hope that helps
On Thu, Mar 07, 2013 at 07:53:57PM +0000, Graham wrote:
I use a LD_PRELOAD before running wine so that i can debug my application.
The library which is preloaded is able to replace system dlsym and from that, other consequence library call.
There is no problem until, i put some Detour code(hot patching) into the kernel32.dll.so address space. But the very funny things is this ** THE PROGRAM CRASHES BEFORE MY HOTPATCH IS APPLIED **
so it seems somehow the order of cause and effect is extremely weird and frightening to me. How can a piece of code which is not excecuted be teh cause for errors PRIOR/BEFORE to its execution. And this is surely happening because when i uncomment the Hotpatch/detour lines the problem goes away.
here are some lines from the crashs ...
err:module:attach_process_dlls "user32.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"C:\windows\system32\winemenubuilder.exe" failed, status c0000005 wine: Unhandled page fault on execute access to 0x7c9e4cd7 at address 0x7c9e4cd7 (thread 000b), starting debugger... err:module:DelayLoadFailureHook failed to delay load user32.dll.BroadcastSystemMessageW wine: Call from 0x7b83ba92 to unimplemented function user32.dll.BroadcastSystemMessageW, aborting wine: Unimplemented function user32.dll.BroadcastSystemMessageW called at address 0x7b83ba92 (thread 001d), starting debugger...
Another thing to notice is that this was tested using wine1.4.1
However it DOES work with wine1.5.10 ... to get something to work for me is not the challenge, its to understand the logic behind why something does not.
THanks a lot and I am grateful for any who contributes his knowledge to this problem i am a real NOVICE
"real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together for me...?
- wine uses it own elfloader, which might cause issues.
- during loading/linking it might also interact already.
what should the LD_PRELOAD thing achieve? Can perhaps a wine internal debug mechanism be used already?
Ciao, Marcus
On Fri, 8 Mar 2013, Marcus Meissner wrote: [...]
"real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together for me...?
- wine uses it own elfloader, which might cause issues.
Really? I thought it used the standard elf loader hence the need for tricks to get the native libraries to load in the right place. What it does have however is its own PE loader. Not sure if it's relevant here.
On 08/03/13 22:40, Francois Gouget wrote:
On Fri, 8 Mar 2013, Marcus Meissner wrote: [...]
"real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together for me...?
- wine uses it own elfloader, which might cause issues.
Really? I thought it used the standard elf loader hence the need for tricks to get the native libraries to load in the right place. What it does have however is its own PE loader. Not sure if it's relevant here.
the functions i detoured in kernel32.dll.so were LoadLibrary and FreeLibrary, the question still remains how its even possible, this should be a fairly straight-forward thing to answer for you developers, i would had thought. If its too much to understand , please say :/
i put code which detours LoadLibrary and FreeLibrary in kernel32.dll.so , but the code only runs at a later certain time after program execution ... ( trigger is actually a certain library loaded, i detect it in dlsym ) ... But in wine 1.4.1 the program crashes at a time earlier than the triggered detour, understand?? This don't seem physically possible, any explanation?
On Sat, Mar 09, 2013 at 01:40:00AM +0000, Graham wrote:
On 08/03/13 22:40, Francois Gouget wrote:
On Fri, 8 Mar 2013, Marcus Meissner wrote: [...]
"real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together for me...?
- wine uses it own elfloader, which might cause issues.
Really? I thought it used the standard elf loader hence the need for tricks to get the native libraries to load in the right place. What it does have however is its own PE loader. Not sure if it's relevant here.
the functions i detoured in kernel32.dll.so were LoadLibrary and FreeLibrary, the question still remains how its even possible, this should be a fairly straight-forward thing to answer for you developers, i would had thought. If its too much to understand , please say :/
i put code which detours LoadLibrary and FreeLibrary in kernel32.dll.so , but the code only runs at a later certain time after program execution ... ( trigger is actually a certain library loaded, i detect it in dlsym ) ... But in wine 1.4.1 the program crashes at a time earlier than the triggered detour, understand?? This don't seem physically possible, any explanation?
In loader/preloader.c is our own pre-elf-loader, which handles the specific address space layouts we use.
All the library loading is very magic even to me and I have to understand it anew every time ;)
Why not just patch the Wine source itself and build a specific Wine version for your problem? This makes it easier and avoids need of preloading tricks.
You probably also want to patch LdrLoadDll in ntdll.
Ciao, Marcus
On 09/03/13 06:03, Marcus Meissner wrote:
On Sat, Mar 09, 2013 at 01:40:00AM +0000, Graham wrote:
On 08/03/13 22:40, Francois Gouget wrote:
On Fri, 8 Mar 2013, Marcus Meissner wrote: [...]
"real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together for me...?
- wine uses it own elfloader, which might cause issues.
Really? I thought it used the standard elf loader hence the need for tricks to get the native libraries to load in the right place. What it does have however is its own PE loader. Not sure if it's relevant here.
the functions i detoured in kernel32.dll.so were LoadLibrary and FreeLibrary, the question still remains how its even possible, this should be a fairly straight-forward thing to answer for you developers, i would had thought. If its too much to understand , please say :/
i put code which detours LoadLibrary and FreeLibrary in kernel32.dll.so , but the code only runs at a later certain time after program execution ... ( trigger is actually a certain library loaded, i detect it in dlsym ) ... But in wine 1.4.1 the program crashes at a time earlier than the triggered detour, understand?? This don't seem physically possible, any explanation?
In loader/preloader.c is our own pre-elf-loader, which handles the specific address space layouts we use.
All the library loading is very magic even to me and I have to understand it anew every time ;)
Why not just patch the Wine source itself and build a specific Wine version for your problem? This makes it easier and avoids need of preloading tricks.
You probably also want to patch LdrLoadDll in ntdll.
Ciao, Marcus
Gracias.
That helps, cheers all. And Good Luck with the continuation of this awesome software
Am 09.03.2013 02:40, schrieb Graham:
On 08/03/13 22:40, Francois Gouget wrote:
On Fri, 8 Mar 2013, Marcus Meissner wrote: [...]
"real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together for me...?
- wine uses it own elfloader, which might cause issues.
Really? I thought it used the standard elf loader hence the need for tricks to get the native libraries to load in the right place. What it does have however is its own PE loader. Not sure if it's relevant here.
the functions i detoured in kernel32.dll.so were LoadLibrary and FreeLibrary, the question still remains how its even possible, this should be a fairly straight-forward thing to answer for you developers, i would had thought. If its too much to understand , please say :/
Wines loader stuff can be fairly complex as Marcus already pointed out, though the change(s) needed to fix your problem was most likely quite small and nothing we keep in mind. Why didn't you tried using Regression testing as Alexandre Goujon suggested?
i put code which detours LoadLibrary and FreeLibrary in kernel32.dll.so , but the code only runs at a later certain time after program execution ... ( trigger is actually a certain library loaded, i detect it in dlsym ) ... But in wine 1.4.1 the program crashes at a time earlier than the triggered detour, understand?? This don't seem physically possible, any explanation?
Maybe another thread or something was calling these functions before you do, or you called a function that calls one of them and you didn't expected that?
On 09/03/13 14:08, André Hentschel wrote:
Am 09.03.2013 02:40, schrieb Graham:
On 08/03/13 22:40, Francois Gouget wrote:
On Fri, 8 Mar 2013, Marcus Meissner wrote: [...]
"real NOVICE" and using LD_PRELOAD or "hotpatching" does not fit together for me...?
- wine uses it own elfloader, which might cause issues.
Really? I thought it used the standard elf loader hence the need for tricks to get the native libraries to load in the right place. What it does have however is its own PE loader. Not sure if it's relevant here.
the functions i detoured in kernel32.dll.so were LoadLibrary and FreeLibrary, the question still remains how its even possible, this should be a fairly straight-forward thing to answer for you developers, i would had thought. If its too much to understand , please say :/
Wines loader stuff can be fairly complex as Marcus already pointed out, though the change(s) needed to fix your problem was most likely quite small and nothing we keep in mind. Why didn't you tried using Regression testing as Alexandre Goujon suggested?
i put code which detours LoadLibrary and FreeLibrary in kernel32.dll.so , but the code only runs at a later certain time after program execution ... ( trigger is actually a certain library loaded, i detect it in dlsym ) ... But in wine 1.4.1 the program crashes at a time earlier than the triggered detour, understand?? This don't seem physically possible, any explanation?
Maybe another thread or something was calling these functions before you do, or you called a function that calls one of them and you didn't expected that?
i have dlsym in my LD_PRELOAD, even if another thread is calling dlsym, my logging within the implementaiton of dlsym in my LD_PRELOAD library would notify me of such? My code is very simple, i check for certain library symbol within dlsym, if its one which is called last ( i remember its name )/ at the end of the loading routine, then i will from there initiate my detour to loadlibrarya.. within loadlibrary a, i create a new thread with pthread_create,, only on condition of a particular windows dll given as argument to loadlibrarya ofc. this is how its working, and it works under 1.5 , not 1.4.1 , i go with the theory its something with the elf loader, cheers ...
-
André Hentschel -
Francois Gouget -
GOUJON Alexandre -
Graham -
Marcus Meissner