At 08:09 04/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> I can currently produce this race (without my patch applied) by adding a "Sleep(
>> 1000 )"
>> to the USR1 signal handler in ntdll/signal_i386.c. The wineserve
At 10:15 03/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> anything that uses SuspendThread is inherently racy and unpleasant. Even the
>> Microsoft
>> documentation says "don't use this!". Of course, they ignore t
At 21:44 03/04/03 +0200, Eric Pouech wrote:
>>Apart from the duplication of the signal mechanism, it also introduces
>>races, since we depend on the client to do part of the suspend
>>code. It means the server state will not necessarily match the actual
>>state of the client thread, which could cau
At 08:08 03/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> Solaris isn't an issue here - valgrind only works on linux/x86.
>
>Of course Solaris is an issue, unless you somehow make your patch take
>effect only when running under
At 16:53 03/04/03 +0200, Sylvain Petreolle wrote:
>With your new patch applied to a cvs version of valgrind,
>valgrind fails to compile. I get :
>
>make[1]: Entre dans le répertoire `/home/valgrind/coregrind'
>source='vg_to_ucode.c' object='vg_to_ucode.o' libtool=no \
>depfile='.deps/vg_to_ucode.Po
At 14:50 02/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> * dlls/Makefile.in: Rebuild the msvcrt directory twice, once for
>> msvcrt.dll.so and once for the debug msvcrtd.dll.so.
>
>You can't do
At 16:47 03/04/03 +0200, Sylvain Petreolle wrote:
>You included the following suppression within wine.supp into your
>valgrind patch,
>did you do debug or must a bug be open on bugzuilla ?
>
># The CTLCOLOR message handler doesn't fill in pResult - BUG!
>{
> CWnd::ReflectChildNotify/CWnd::OnChil
At 06:57 03/04/03 -0500, Dimitrie O. Paun wrote:
>On April 3, 2003 05:45 am, Adam Gundy wrote:
>> I've never got very far with winelib - as soon as any code involving OLE
>> gets involved, things won't compile. In fact, getting stuff without OLE to
>> compile
At 20:34 02/04/03 +0200, Eric Pouech wrote:
>>the reason msvcrtd is there is that you need to use it for valgrind to do
>>any checking of the heap - an instrumented malloc (see the changes to ntdll/heap.c)
>>is required to tell valgrind that freshly allocated blocks are uninitialized,
>>and the fre
At 09:27 02/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> which part of the signal stuff won't work? all that has happened is that the
>> "kill( , SIGUSR1 )" has moved from the wineserver to the client (for 'local
At 19:45 01/04/03 -0600, Eric Pouech <[EMAIL PROTECTED]> wrote:
>Adam Gundy wrote:
>> a new version of the valgrind patch has been uploaded to sourceforge -
>> the only change is a small fix to the signal handling which should
>> prevent "signal han
At 12:17 01/04/03 -0800, you wrote:
>Adam Gundy <[EMAIL PROTECTED]> writes:
>
>> a new version of the valgrind patch has been uploaded to sourceforge -
>> the only change is a small fix to the signal handling which should
>> prevent "signal handler frame"
hi... after much hard work and midnight oil, I have made valgrind (the memory
access checking tool) work with WINE.
You can run multi-threaded Windows programs under WINE (under valgrind), and
have stack traces printed out for all the memory errors both in WINE and in
the Windows program (and yes
At 10:17 06/03/03 -0500, Dimitrie O. Paun wrote:
>On March 6, 2003 06:04 am, Adam Gundy wrote:
>
>[wine-devel Cc:ed to keep people in the loop]
>
>> Is a listview guaranteed to be single threaded? I assume it is because it
>> is all message driven - so some flag in the
14 matches
Mail list logo
