Why different use of memory
Bill Medland
billmedland at mercuryspeed.com
Wed May 5 11:05:02 CDT 2004
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?
--
Bill Medland
mailto:billmedland at mercuryspeed.com
http://webhome.idirect.com/~kbmed
More information about the wine-devel
mailing list