From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Fix for Emacs Crash - revisited Date: Mon, 11 Nov 2002 15:26:44 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <20021111150957.BAEB.LEKTU@terra.es> References: <200211111355.gABDtQCB015905@smtp-server1.tampabay.rr.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1037200869 19000 80.91.224.249 (13 Nov 2002 15:21:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Nov 2002 15:21:09 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18BzCk-00048l-00 for ; Wed, 13 Nov 2002 16:13:22 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18BzOh-00066k-00 for ; Wed, 13 Nov 2002 16:25:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BFkV-00029J-00; Mon, 11 Nov 2002 09:41:11 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18BFWj-0008SP-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 09:26:57 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18BFWf-0008Pt-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 09:26:56 -0500 Original-Received: from [62.22.27.141] (helo=mail.peoplecall.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BFWc-0008Nf-00; Mon, 11 Nov 2002 09:26:50 -0500 Original-Received: from [62.22.27.143] (jbarranquero.ofi.peoplecall.com [62.22.27.143]) by mail.peoplecall.com (8.11.6/8.11.6) with ESMTP id gABEQce05604; Mon, 11 Nov 2002 15:26:44 +0100 Original-To: bkey1@tampabay.rr.com In-Reply-To: <200211111355.gABDtQCB015905@smtp-server1.tampabay.rr.com> X-Mailer: Becky! ver. 2.05.06 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9329 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9329 On Mon, 11 Nov 2002 08:55:26 US/Eastern, bkey1@tampabay.rr.com wrote: > For all of the current Windows NT Style OSes, Windows NT 4.0, > Windows 2000, and Windows XP (possibly even Windows NT 3.51), > ossubtype is equal to OS_NT. Yes, I know. > However, if there is a concern that this > may break in a future OS, I could easily change my code to > call GetVersionEx and change the test from > ossubtype==OS_NT > to os_version_info.dwPlatformId==VER_PLATFORM_WIN32_NT. IMHO the test should *exclude* the platforms where you know the call to OpenProcessToken fails, not include the ones where it works, because the first subset is more likely to remain stable than the second one. > While I was debugging these crashes I found that when I set a breakpoint in > the functions syms_of_w32menu or syms_of_w32fns the debugger > failed to stop at the break point. Neither were calls to > OutputDebugString I placed in these functions processed. In > addition, when I set breakpoints in main where these functions > were called, the debugger failed to stop at these break points. > However, I was able to verify that these functions were being > called by setting a global variable to a specific value and > setting a break point in initialize_frame_menubar and verifying > that the global variable had that specific value. I am not > certain what caused this inability to get the debugger to stop > at these breakpoints Usually it means that it consists of dead code, i.e., that no machine code was generated for those source locations... Or there's something I'm missing? > He was probably using MinGW, not MSVC 6.0. AFAIK, Andrew switches between MinGW and MSVC from one release to the next. But you're right, the problem obviously existed before as you found it in etc/PROBLEMS. My mistake. Anyway, it is still interesting trying to determine why it does happens in XP vs. 9x/Me and not, for example, 2K vs 9x/Me. As an aside: According to the Platform SDK, OpenProcessToken only exists in NT 3.1 and later, not in the 9x series... /L/e/k/t/u