Continuing the saga!!
I have this program that I am trying to run under RedHat Enterprise Linux 3.
I have installed the 20031118 rh8 rpm. (Big saga as to why that one)
When I first run the program after a reboot (of the linux) the program fails When I run it again it works, and it continues to work until the next reboot.
The BIG difference between the two runs is which memory it uses. Can anyone tell me why it is using such different areas of memory?
When it fails it is basically using memory up at approx 0xb6000000 When it is working it is using memory down at 0x40000000
-kernel32.__wine_register_dll_16(40b35374) ret=40a8cc12 +kernel32.__wine_register_dll_16(b6b8f3c4) ret=b6ae6c12
On Tue, 04 May 2004 21:11:47 -0700, Bill Medland wrote:
When I first run the program after a reboot (of the linux) the program fails When I run it again it works, and it continues to work until the next reboot.
How does it fail?
The BIG difference between the two runs is which memory it uses. Can anyone tell me why it is using such different areas of memory?
When it fails it is basically using memory up at approx 0xb6000000 When it is working it is using memory down at 0x40000000
-kernel32.__wine_register_dll_16(40b35374) ret=40a8cc12 +kernel32.__wine_register_dll_16(b6b8f3c4) ret=b6ae6c12
Maybe this is due to the address space problems on RHEL. I think the latest versions of Wine have a fix, but could be wrong, I'm pretty sure there's a fix in CrossOver for it. Alexandre?
On May 5, 2004 06:54 am, Mike Hearn wrote:
On Tue, 04 May 2004 21:11:47 -0700, Bill Medland wrote:
When I first run the program after a reboot (of the linux) the program fails When I run it again it works, and it continues to work until the next reboot.
(Actually I was slightly wrong; it fails until I log out and log back in, and then it works consistently; but the memory issue remains)
How does it fail?
I wish I knew.
While running the EntryPoint of the Crystal Reports CRPE32.dll it goes through a process to link dynamically to crheapalloc.dll and get the address of the crHeapAlloc function. When running correctly it does so.
When it fails somehow the memory location that is supposed to hold a 32 bit address pointing to the string "crHeapAlloc" ends up holding a 16bit value. That is passed to GetProcAddress which, of course, thinks it's an ordinal and fails to find the address (big deal) and then in the error reporting code it calls strcmp with that 16 bit value and a pointer to the string crHeapAlloc and of course the strcmp throws a page fault.
Now the bit that I don't yet understand is how that 16 bit value ends up in there instead of the correct address.
I am trying various approaches to find out. In particular I am trying to run with +relay for both a good and a bad run and see if there is a difference, but I am swamped by the differences between the memory addresses. (If I get several good runs then they only differ by about 6 lines in 564491)
It seemed to me that such a fundmental difference between the memory usage could very well be related, so it was worth following up.
The BIG difference between the two runs is which memory it uses. Can anyone tell me why it is using such different areas of memory?
When it fails it is basically using memory up at approx 0xb6000000 When it is working it is using memory down at 0x40000000
-kernel32.__wine_register_dll_16(40b35374) ret=40a8cc12 +kernel32.__wine_register_dll_16(b6b8f3c4) ret=b6ae6c12
Maybe this is due to the address space problems on RHEL. I think the latest versions of Wine have a fix, but could be wrong, I'm pretty sure there's a fix in CrossOver for it. Alexandre?
Oh. I didn't notice that (not that I concentrate too hard on the list). Got a reference?
Mike Hearn mh@codeweavers.com writes:
Maybe this is due to the address space problems on RHEL. I think the latest versions of Wine have a fix, but could be wrong, I'm pretty sure there's a fix in CrossOver for it. Alexandre?
There's a hack in Crossover to work around that problem, but it's not a proper fix. The right way is to reserve the high memory area so that things don't get mapped there.
On Wed, 2004-05-05 at 09:12 -0700, Alexandre Julliard wrote:
There's a hack in Crossover to work around that problem, but it's not a proper fix. The right way is to reserve the high memory area so that things don't get mapped there.
What address range is that? At the moment I think Mikes preloader patch only reserves the PE load area, DOS area and shared heap area. Is there another we need?
Mike Hearn mh@codeweavers.com writes:
What address range is that? At the moment I think Mikes preloader patch only reserves the PE load area, DOS area and shared heap area. Is there another we need?
Basically everything above 2Gb. But there's no need to do that in the preloader, it can be done in the normal init code.
On Wed, 2004-05-05 at 11:32 -0700, Alexandre Julliard wrote:
Basically everything above 2Gb. But there's no need to do that in the preloader, it can be done in the normal init code.
I thought the kernel would be happy to mmap addresses >2gig for the dynamic linker - no?
Mike Hearn mh@codeweavers.com writes:
I thought the kernel would be happy to mmap addresses >2gig for the dynamic linker - no?
It doesn't matter, we don't need that space, we just need to prevent dlls from getting mapped there.
Alexandre Julliard wrote:
Mike Hearn mh@codeweavers.com writes:
What address range is that? At the moment I think Mikes preloader patch only reserves the PE load area, DOS area and shared heap area. Is there another we need?
Basically everything above 2Gb. But there's no need to do that in the preloader, it can be done in the normal init code.
What would such a program do on Win2K Advanced server with 3GB of user memory?
Shachar
On Thu, 6 May 2004, Shachar Shemesh wrote: [...]
What would such a program do on Win2K Advanced server with 3GB of user memory?
IIRC Windows NT/2000 only gives 3GB of address space to apps that ask for it via a flag in the PE header. So this app would probably be all mapped in the lower 2GBs.
On May 5, 2004 10:29 am, Mike Hearn wrote:
On Wed, 2004-05-05 at 09:12 -0700, Alexandre Julliard wrote:
There's a hack in Crossover to work around that problem, but it's not a proper fix. The right way is to reserve the high memory area so that things don't get mapped there.
What address range is that? At the moment I think Mikes preloader patch only reserves the PE load area, DOS area and shared heap area. Is there another we need?
Any chance either of a pointer to Mike's preloader patch or a hint on the Crossover hack? (I want to see if it fixes my printing problem too)
-
Alexandre Julliard -
Bill Medland -
Francois Gouget -
Mike Hearn -
Shachar Shemesh