>* Can i make assumption, that log produced by wine is not buffered anywhere
>and is written to console sequentially and immediately when that event
>happened? (in other words log output doesn't outrun each other lines)
Sadly, not in a multithreaded program.
>* Is HEAP_ValidateInUseArena called a
Thanks Henri... I think i got "heap headache" :-/
* Can i make assumption, that log produced by wine is not buffered anywhere
and is written to console sequentially and immediately when that event
happened? (in other words log output doesn't outrun each other lines)
* Is HEAP_ValidateInUseArena
2010/5/6 :
> BTW: why it takes so long (cca 6 hours) a post to appear, when i send
> mail to wine-devel? Some kind of mail graylist?
If you are not subscribe to wine-devel, an administrator must approve
your email before it is sent to the list.
--
-Austin
On 6 May 2010 11:18, wrote:
> * The first 0022: and 0018: are thread numbers?
Yes
> * Can be the problem in 0018: be caused by different thread?
Yes
> * What is that 0/19?
That means the first of 19 tail bytes was overwritten. The message as
a whole means that there's a block of memory at 0x195
> > Allocates me 3E0 (rounded 3d4) bytes filled with
> > zeros, begining at adr1 and this:
> > a) adr1 should be "relatively close" to the 0x0011
> > b) adr1 should be same as adr2
> >
> You can't really make those assumptions, though I guess
> they may
> sometimes be true in practice.
>
OK
On 5/6/10 1:57 AM, wy...@volny.cz wrote:
> BTW: why it takes so long (cca 6 hours) a post to appear, when i send
> mail to wine-devel? Some kind of mail graylist?
If you're not subscribed to wine-devel, your messages are subject to
moderation.
Chip
> > #274 before wined3d_mutex_unlock(), 0x0020a3f0=HeapAlloc(),
> > #274 after wined3d_mutex_unlock(), 0x18fa7048=HeapAlloc()
> > ^^^
> >
> What exactly is wrong with that address?
Hi Henri, to my understending, when i take real values:
adr
2010/5/6 :
>> What exactly is wrong with that address?
>
> Hi Henri, to my understending, when i take real values:
>
> adr1 = HeapAlloc(0x0011, 0x0008, 0x03d4);
> HeapFree (0x0011, 0, adr1);
>
> adr2 = HeapAlloc(0x0011, 0x0008, 0x03d4);
> HeapFree (0x0011, 0, adr2);
On 5 May 2010 01:39, wrote:
> #274 before wined3d_mutex_unlock(), 0x0020a3f0=HeapAlloc(),
> &wined3d_cs=0x7e22fda0
> #274 after wined3d_mutex_unlock(), 0x18fa7048=HeapAlloc(),
> &wined3d_cs=0x7e22fda0
> ^^^
> Any suggestion?
>
What exactl
So after next few hours of "debuging my way" (HeapAlloc + printf + HeapFree)
and bisecting where HeapAlloc is OK and where isn't i come to conclusion,
that there is someting bad with wined3d_mutex_unlock(), i.e. it looks
like pure luck, that the game runs with native openal32 and freezes
with buil
> So how do i find out, why HeapAlloc does not return sane values like
> in first call of DirectSoundDevice_Create()?
Sounds like heap corruption. Try using valgrind to see if there are
memory errors before the second call to DirectSoundDevice_Create().
--Juan
Hi, for those of readers who don't know yet, i'm a "Hello word" programmer,
so sorry for bad wording or speculation etc.
I decided to look into a regression since wine 1.1.30, who nobody apparently
not know what to do, otherwise it would be solved ;)
The game freezes during sound initialization a
12 matches
Mail list logo
