I'm getting segfaults with current cvs, I've tracked it down to this patch http://cvs.winehq.org/patch.py?id=12187
last few lines in a +relay are 0009:Call ntdll.NtCreateKey(bfffcd84,000f003f,bfffe190,00000000,00000000,00000000,00000000) ret=4051e47a 0009:Ret ntdll.NtCreateKey() retval=00000000 ret=4051e47a 0009:Call ntdll.RtlInitUnicodeString(bfffc52c,405d616e L"windows") ret=4051e27f 0009:Ret ntdll.RtlInitUnicodeString() retval=00000000 ret=4051e27f 0009:Call ntdll.NtQueryValueKey(00000010,bfffc52c,00000002,bfffc534,00000800,bfffc528) ret=4051e2be 0009:Ret ntdll.NtQueryValueKey() retval=00000000 ret=4051e2be 0009:Call ntdll.RtlDosPathNameToNtPathName_U(bfffc540 L"c:\Windows",bfffc49c,00000000,00000000) ret=4053ecd2 Segmentation fault
On Thursday 29 April 2004 06:56 pm, Kevin Koltzau wrote:
I'm getting segfaults with current cvs, I've tracked it down to this patch http://cvs.winehq.org/patch.py?id=12187
last few lines in a +relay are 0009:Call ntdll.NtCreateKey(bfffcd84,000f003f,bfffe190,00000000,00000000,00000000,00000000) ret=4051e47a 0009:Ret ntdll.NtCreateKey() retval=00000000 ret=4051e47a 0009:Call ntdll.RtlInitUnicodeString(bfffc52c,405d616e L"windows") ret=4051e27f 0009:Ret ntdll.RtlInitUnicodeString() retval=00000000 ret=4051e27f 0009:Call ntdll.NtQueryValueKey(00000010,bfffc52c,00000002,bfffc534,00000800,bfffc528) ret=4051e2be 0009:Ret ntdll.NtQueryValueKey() retval=00000000 ret=4051e2be 0009:Call ntdll.RtlDosPathNameToNtPathName_U(bfffc540 L"c:\Windows",bfffc49c,00000000,00000000) ret=4053ecd2 Segmentation fault
I've narrowed it down to a buffer overrun, no idea where yet..but if I force RtlAllocateHeap to always allocate 1 extra byte, the segfault goes away..
"Kevin" == Kevin Koltzau kevin@plop.org writes:
Kevin> I've narrowed it down to a buffer overrun, no idea where yet..but Kevin> if I force RtlAllocateHeap to always allocate 1 extra byte, the Kevin> segfault goes away..
It always a good start to run a buffer overrun with +relay,+heap. That way, the corruption is noticed on the next heap operation after the corruption.
Bye
On Friday 30 April 2004 09:37 am, Uwe Bonnes wrote:
Kevin> I've narrowed it down to a buffer overrun, no idea where yet..but Kevin> if I force RtlAllocateHeap to always allocate 1 extra byte, the Kevin> segfault goes away..It always a good start to run a buffer overrun with +relay,+heap. That way, the corruption is noticed on the next heap operation after the corruption.
Attached is a run of WINEDEBUG="+relay,+heap" ./wine
"Kevin" == Kevin Koltzau kevin@plop.org writes:
Kevin> On Friday 30 April 2004 09:37 am, Uwe Bonnes wrote: I've narrowed Kevin> it down to a buffer overrun, no idea where yet..but if I force Kevin> RtlAllocateHeap to always allocate 1 extra byte, the segfault Kevin> goes away.. >> It always a good start to run a buffer overrun with +relay,+heap. >> That way, the corruption is noticed on the next heap operation after >> the corruption.
Kevin> Attached is a run of WINEDEBUG="+relay,+heap" ./wine
Is http://cvs.winehq.org/patch.py?id=12192 applied?
it could be related.
On Friday 30 April 2004 09:59 am, Uwe Bonnes wrote:
Is http://cvs.winehq.org/patch.py?id=12192 applied?
it could be related.
Yes its applied, I am running on current cvs as of this morning
"Kevin" == Kevin Koltzau kevin@plop.org writes:
Kevin> On Friday 30 April 2004 09:59 am, Uwe Bonnes wrote: >> Is http://cvs.winehq.org/patch.py?id=12192 applied? >> >> it could be related.
Kevin> Yes its applied, I am running on current cvs as of this morning
Could you try appended patch?
On Friday 30 April 2004 10:47 am, Uwe Bonnes wrote:
Could you try appended patch?
Looks like that worked, thanks
-
Kevin Koltzau -
Uwe Bonnes