From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9607 invoked by alias); 21 Nov 2007 13:43:30 -0000 Received: (qmail 9598 invoked by uid 22791); 21 Nov 2007 13:43:29 -0000 X-Spam-Check-By: sourceware.org Received: from nf-out-0910.google.com (HELO nf-out-0910.google.com) (64.233.182.185) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 Nov 2007 13:43:22 +0000 Received: by nf-out-0910.google.com with SMTP id b11so2157216nfh for ; Wed, 21 Nov 2007 05:43:17 -0800 (PST) Received: by 10.86.98.18 with SMTP id v18mr7350783fgb.1195652597470; Wed, 21 Nov 2007 05:43:17 -0800 (PST) Received: by 10.86.27.20 with HTTP; Wed, 21 Nov 2007 05:43:17 -0800 (PST) Message-ID: <4053daab0711210543w4b241e1ek2371e887f3c4f7d2@mail.gmail.com> Date: Wed, 21 Nov 2007 13:43:00 -0000 From: "Pedro Alves" To: gdb-patches@sourceware.org Subject: Re: [win32] Fix suspend count handling Cc: "Pierre Muller" In-Reply-To: <000001c82c31$4a57b220$df071660$@u-strasbg.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47437D3A.3000107@portugalmail.pt> <000001c82c31$4a57b220$df071660$@u-strasbg.fr> X-Google-Sender-Auth: 88871a42858a1d1d X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-11/txt/msg00395.txt.bz2 On Nov 21, 2007 11:25 AM, Pierre Muller wrote: > Hi Pedro, > > I agree with you that the ResumeThread should be called > only once, even if the suspend_count is > 1, but when I tested your test > application, > I obtained 4 as a result with the current gdb head. > This is because in fact the thread suspend_count are > only restored after ContinueDebugEvent is called. I suspect you didn't reproduce the exact steps I described, probably because I didn't describe it sufficiently. Here's a test run: $ gdb/gdb.exe main.exe GNU gdb 6.7.50.20071121 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) list 37 32 printf ("SuspendThreadFailed\n"); 33 return 1; 34 } 35 36 37 suspend_count = ResumeThread (h); /* set breakpoint here */ 38 39 printf ("%lu\n", suspend_count); /* should be 3 */ 40 41 while ((suspend_count = ResumeThread (h)) != 0 (gdb) b 37 Breakpoint 1 at 0x40119a: file main.c, line 37. (gdb) r Starting program: /d/gdb/build/main.exe Breakpoint 1, main (argc=1, argv=0x6b3270) at main.c:37 37 suspend_count = ResumeThread (h); /* set breakpoint here */ (gdb) info threads 3 thread 11344.0x2e54 0x7c90eb94 in ntdll!LdrAccessResource () from /cygdrive/c/WINNT/system32/ntdll.dll 2 thread 11344.0x1e4c 0x7c90eb94 in ntdll!LdrAccessResource () from /cygdrive/c/WINNT/system32/ntdll.dll * 1 thread 11344.0x2d00 main (argc=1, argv=0x6b3270) at main.c:37 (gdb) thread 3 [Switching to thread 3 (thread 11344.0x2e54)]#0 0x7c90eb94 in ntdll!LdrAccessResource () from /cygdrive/c/WINNT/system32/ntdll.dll (gdb) thread 1 [Switching to thread 1 (thread 11344.0x2d00)]#0 main (argc=1, argv=0x6b3270) at main.c:37 37 suspend_count = ResumeThread (h); /* set breakpoint here */ (gdb) n 39 printf ("%lu\n", suspend_count); /* should be 3 */ (gdb) p suspend_count $1 = 0 (gdb) You must switch to the suspended thread for gdb to call SuspendThread on it, otherwise, gdb will not try to ResumeThread it, and the bug isn't triggered. I mentioned "thread 2" in the other mail, but as seen on the "info threads" result, the gdb tid of the suspended thread will vary. A proper testcase would switch to all threads one by one and then back to thread 1 to ensure the bug is triggered. > Thus the debugged event can possibly called > ResumeThread before gdb does so, thus obtaining a > Thread count of 4 instead of 0... > The first answer that comes to mind would be to > called ResumeThread before calling ContinueDebugEvent, > but that would mean that other threads would be restarted before > the thread that caused the debug event, which is > probably also not good. > Not true. See here: [The Win32 Debugging Application Programming Interface] http://msdn2.microsoft.com/en-us/library/ms809754.aspx "When a debug event occurs, execution of that process is suspended until the debugger calls the ContinueDebugEvent function. Consequently, all threads in the process are suspended while the debugger is processing the debug event." In fact my patch at: [win32] Fix watchpoint support http://sourceware.org/ml/gdb-patches/2007-11/msg00390.html ... ensures that ContinueDebugEvent is always called last. Cheers, Pedro Alves