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