http://bugs.winehq.org/show_bug.cgi?id=8924
--- Comment #31 from jvlad dmda@yandex.ru 2009-10-02 15:21:30 --- I'm sorry if what I reported is still not clear.
It's indeed hard to reproduce. If you didn't change anything, it should be possible to find combination. I hope with full wine code compiled with debug info, it would be easier to find the origin of the problem.
What I reported is basicly outlined below:
1) environment block is allocated say at address 0x700000 2) program gets some environment variables using getenv(). It's known that getenv() returns pointer to static buffer. So the program does not bother to copy the returned strings. Say, it gets 2 pointers to 0x701000 and 0x701100 3) program makes some changes to the environment block and allocates some new variables. 4) it seems that at some point (after some modifications per p.2) wine reallocates whole the environment block. Say, not the block is allocated at 0x800000. What did happen to the pointers returned per p.1 0x701000 and 0x701100? Nothing, absolutely. They still point to the same strings, now in fried memory, and the memory itself is still not used so the values are exactly the same as before. It's not enough to reallocate the environment block, it's necessary to get the released block allocated for something else. Then the pointers will point to bogus data. Perhaps you know it better how to use wine's memory manager and get all the fried blocks filled up with somekind of fillers, like MS fills with 0xBAADF00D when compiled with debug CRT. In this case you'll see dangling pointers right after block is reallocated.
Please let me know if anything remained unclear.