From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Ben Key" Newsgroups: gmane.emacs.devel Subject: Fix for Emacs Crash - revisited Date: Sun, 10 Nov 2002 03:45:34 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <000001c28895$897a8d50$6501a8c0@GODDESS> Reply-To: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C2886B.A0AA9FD0" X-Trace: main.gmane.org 1036918863 15553 80.91.224.249 (10 Nov 2002 09:01:03 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 10 Nov 2002 09:01:03 +0000 (UTC) Cc: Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18Anxl-00042S-00 for ; Sun, 10 Nov 2002 10:01:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18Ao87-0007ZU-00 for ; Sun, 10 Nov 2002 10:11: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 18Anwm-00077p-00; Sun, 10 Nov 2002 04:00:00 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18Aniw-0003vN-00 for emacs-devel@gnu.org; Sun, 10 Nov 2002 03:45:42 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Anis-0003t1-00 for emacs-devel@gnu.org; Sun, 10 Nov 2002 03:45:41 -0500 Original-Received: from smtp-server2.tampabay.rr.com ([65.32.1.39]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Anio-0003sZ-00; Sun, 10 Nov 2002 03:45:34 -0500 Original-Received: from GODDESS (6535194hfc48.tampabay.rr.com [65.35.194.48]) by smtp-server2.tampabay.rr.com (8.12.2/8.12.2) with SMTP id gAA8jVfC013104; Sun, 10 Nov 2002 03:45:31 -0500 (EST) Original-To: "Emacs-Devel \(E-mail\)" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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:9301 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9301 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C2886B.A0AA9FD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The patch attached to this message fixes to following entry in etc/PROBLEMS: * Emacs built on Windows 9x/ME crashes at startup on Windows XP, or Emacs built on XP crashes at startup on Windows 9x/ME. The following changes are made by this patch: 1. init_user_info in w32.c has been modified so that OpenProcessToken is no longer called on systems running Windows 9x. Although OpenProcessToken exists in the version of advapi32.dll that is found in Windows 9x, it apparently generates an exception if called on Windows 9x. This exception, if not handled causes Emacs to crash. 2. I modified w32_wnd_proc in w32fns.c so that the function pointer track_mouse_event_fn is reinitialized in the WM_SETFOCUS handler. I found that even though track_mouse_event_fn was being initialized in syms_of_w32fns which is called from main, the function pointer obtained in syms_of_w32fns was invalid. Because of this, Emacs was crashing the first time a WM_MOUSEMOVE message was received. I did not want to reinitialize this function pointer every time a WM_MOUSEMOVE message is received but I wanted to make certain that the function pointer got reinitialized as soon after the creation of the Emacs window as possible. That is why I chose WM_SETFOCUS. 3. I modified initialize_frame_menubar in w32menu.c to reinitialize the function pointers get_menu_item_info and set_menu_item_info. I found that even though these function pointers were being initialized in syms_of_w32menu which is called from main, the function pointers obtained in syms_of_w32menu were invalid. This was causing Emacs to crash the first time either of these function pointers were used. This happened to be in add_menu_item (which is why I initially came to my earlier conclusions, discussed in my earlier message "Fix for Emacs Crash"). I chose to reinitialize these function pointers here because I did not want to have to do it every time the function pointers were used and it seemed that initialize_frame_menubar was the entry point for all menu creation. I have been trying to determine why these function pointers needed to be reinitialized. At first I thought that it might have something to do will DLL relocation, but I no longer think that after discussing my ideas with Glen Gordan, one of my coworkers. He told me that when Windows determine that DLL relocation needs to occur, it happens before main gets called, not after. I am uncomfortable in situations where I cannot determine why a change that fixes a problem is necessary. For this reason I have tested my fix very throughly. I tested a build done on Windows XP using MSVC 6.0 both on Windows 98 and on Windows ME. I also tested a build done on Windows XP using MinGW 2.0 / MSYS 1.08 on Windows ME. And just to make certain I was covering all of my bases, I tested a build done on Windows ME using MinGW 2.0 / MSYS 1.08 on Windows XP. In all of these test situations, Emacs worked without a problem. ------=_NextPart_000_0001_01C2886B.A0AA9FD0 Content-Type: application/octet-stream; name="dopatch21_3.sh" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dopatch21_3.sh" #!/bin/sh if [ -f emacs-21.3.50-w32-play-sound.diff ] then echo "Applying patch emacs-21.3.50-w32-play-sound.diff" patch --unified --quiet --strip=3D1 = --input=3Demacs-21.3.50-w32-play-sound.diff fi if [ -f emacs-21.3.50-w32menu.c.diff ] then echo "Applying patch emacs-21.3.50-windows-crash-fix.diff" patch --unified --quiet --strip=3D1 = --input=3Demacs-21.3.50-windows-crash-fix.diff fi ------=_NextPart_000_0001_01C2886B.A0AA9FD0 Content-Type: application/octet-stream; name="emacs-21.3.50-windows-crash-fix.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="emacs-21.3.50-windows-crash-fix.diff" --- _21.3/src/w32.c 2002-07-14 20:00:37.000000000 -0400=0A= +++ 21.3/src/w32.c 2002-11-09 23:31:19.000000000 -0500=0A= @@ -254,11 +254,22 @@=0A= HANDLE token =3D NULL;=0A= SID_NAME_USE user_type;=0A= =0A= - if (OpenProcessToken (GetCurrentProcess (), TOKEN_QUERY, &token)=0A= - && GetTokenInformation (token, TokenUser,=0A= + if (=0A= + /*=0A= + the test for os_subtype was added here to prevent a=0A= + crash that occurs when OpenProcessToken is called and=0A= + Emacs is running on Windows 9x when it was built on=0A= + Windows NT.=0A= + */=0A= + os_subtype =3D=3D OS_NT=0A= + && OpenProcessToken (GetCurrentProcess (), TOKEN_QUERY, &token)=0A= + && GetTokenInformation (=0A= + token, TokenUser,=0A= (PVOID) user_sid, sizeof (user_sid), &trash)=0A= - && LookupAccountSid (NULL, *((PSID *) user_sid), name, &length,=0A= - domain, &dlength, &user_type))=0A= + && LookupAccountSid (=0A= + NULL, *((PSID *) user_sid), name, &length,=0A= + domain, &dlength, &user_type)=0A= + )=0A= {=0A= strcpy (the_passwd.pw_name, name);=0A= /* Determine a reasonable uid value. */=0A= --- _21.3/src/w32.h 2002-05-03 16:41:03.000000000 -0400=0A= +++ 21.3/src/w32.h 2002-11-09 23:31:19.000000000 -0500=0A= @@ -124,5 +124,10 @@=0A= =0A= extern void init_ntproc ();=0A= extern void term_ntproc ();=0A= +extern void syms_of_w32term ();=0A= +extern void syms_of_w32fns ();=0A= +extern void syms_of_w32select ();=0A= +extern void syms_of_w32menu ();=0A= +extern void syms_of_fontset ();=0A= =0A= #endif /* EMACS_W32_H */=0A= --- _21.3/src/w32fns.c 2002-10-23 12:55:07.000000000 -0400=0A= +++ 21.3/src/w32fns.c 2002-11-09 23:31:19.000000000 -0500=0A= @@ -283,7 +283,12 @@=0A= =0A= /* Window that is tracking the mouse. */=0A= static HWND track_mouse_window;=0A= -FARPROC track_mouse_event_fn;=0A= +=0A= +typedef BOOL (WINAPI * TrackMouseEvent_Proc) (=0A= + IN OUT LPTRACKMOUSEEVENT lpEventTrack=0A= + );=0A= +=0A= +TrackMouseEvent_Proc track_mouse_event_fn=3DNULL;=0A= =0A= /* W95 mousewheel handler */=0A= unsigned int msh_mousewheel =3D 0;=0A= @@ -4929,6 +4934,30 @@=0A= goto dflt;=0A= =0A= case WM_SETFOCUS:=0A= + /*=0A= + Reinitialize the function pointer track_mouse_event_fn here.=0A= + This is required even though it is initialized in syms_of_w32fns=0A= + which is called in main (emacs.c).=0A= + Reinitialize the function pointer track_mouse_event_fn here.=0A= + Even though this function pointer is initialized in=0A= + syms_of_w32fns which is called from main (emacs.c),=0A= + we need to initialize it again here in order to prevent=0A= + a crash that occurs in Windows 9x (possibly only when Emacs=0A= + was built on Windows NT / 2000 / XP?) when handling the=0A= + WM_MOUSEMOVE message.=0A= + The crash occurs when attempting to call the Win32 API=0A= + function TrackMouseEvent through the function pointer.=0A= + It appears as if the function pointer that is obtained when=0A= + syms_of_w32fns is called from main is no longer valid=0A= + (possibly due to DLL relocation?).=0A= + To resolve this issue, I have placed a call to reinitialize=0A= + this function pointer here because this message gets received=0A= + when the Emacs window gains focus. =0A= + */=0A= + track_mouse_event_fn =3D=0A= + (TrackMouseEvent_Proc) GetProcAddress (=0A= + GetModuleHandle ("user32.dll"),=0A= + "TrackMouseEvent");=0A= dpyinfo->faked_key =3D 0;=0A= reset_modifiers ();=0A= register_hot_keys (hwnd);=0A= @@ -14801,7 +14830,7 @@=0A= =0A= /* TrackMouseEvent not available in all versions of Windows, so must = load=0A= it dynamically. Do it once, here, instead of every time it is = used. */=0A= - track_mouse_event_fn =3D GetProcAddress (user32_lib, = "TrackMouseEvent");=0A= + track_mouse_event_fn =3D (TrackMouseEvent_Proc) GetProcAddress = (user32_lib, "TrackMouseEvent");=0A= track_mouse_window =3D NULL;=0A= =0A= w32_visible_system_caret_hwnd =3D NULL;=0A= --- _21.3/src/w32menu.c 2002-08-05 12:33:44.000000000 -0400=0A= +++ 21.3/src/w32menu.c 2002-11-09 23:31:19.000000000 -0500=0A= @@ -129,8 +129,23 @@=0A= =0A= static HMENU current_popup_menu;=0A= =0A= -FARPROC get_menu_item_info;=0A= -FARPROC set_menu_item_info;=0A= +void syms_of_w32menu ();=0A= +=0A= +typedef BOOL (WINAPI * GetMenuItemInfoA_Proc) (=0A= + IN HMENU,=0A= + IN UINT,=0A= + IN BOOL,=0A= + IN OUT LPMENUITEMINFOA=0A= + );=0A= +typedef BOOL (WINAPI * SetMenuItemInfoA_Proc) (=0A= + IN HMENU,=0A= + IN UINT,=0A= + IN BOOL,=0A= + IN LPCMENUITEMINFOA=0A= + );=0A= +=0A= +GetMenuItemInfoA_Proc get_menu_item_info=3DNULL;=0A= +SetMenuItemInfoA_Proc set_menu_item_info=3DNULL;=0A= =0A= Lisp_Object Vmenu_updating_frame;=0A= =0A= @@ -1591,6 +1606,26 @@=0A= initialize_frame_menubar (f)=0A= FRAME_PTR f;=0A= {=0A= + HMODULE user32 =3D GetModuleHandle ("user32.dll");=0A= + /*=0A= + Reinitialize the function pointers set_menu_item_info and=0A= + get_menu_item_info here.=0A= + Even though these function pointers are initialized in=0A= + syms_of_w32menu which is called from main (emacs.c),=0A= + we need to initialize them again here in order to prevent=0A= + a crash that occurs in Windows 9x (possibly only when Emacs=0A= + was built on Windows NT / 2000 / XP?) in add_menu_item.=0A= + The crash occurs when attempting to call the Win32 API=0A= + function SetMenuItemInfo through the function pointer.=0A= + It appears as if the function pointer that is obtained when=0A= + syms_of_w32menu is called from main is no longer valid=0A= + (possibly due to DLL relocation?).=0A= + To resolve this issue, I have placed calls to reinitialize=0A= + these function pointers here because this function is the=0A= + entry point for menu creation.=0A= + */=0A= + get_menu_item_info =3D (GetMenuItemInfoA_Proc) GetProcAddress = (user32, "GetMenuItemInfoA");=0A= + set_menu_item_info =3D (SetMenuItemInfoA_Proc) GetProcAddress = (user32, "SetMenuItemInfoA");=0A= /* This function is called before the first chance to redisplay=0A= the frame. It has to be, so the frame will have the right size. = */=0A= FRAME_MENU_BAR_ITEMS (f) =3D menu_bar_items (FRAME_MENU_BAR_ITEMS = (f));=0A= @@ -2355,13 +2390,12 @@=0A= =0A= #endif /* HAVE_MENUS */=0A= =0A= -=0C=0A= -syms_of_w32menu ()=0A= +void syms_of_w32menu ()=0A= {=0A= /* See if Get/SetMenuItemInfo functions are available. */=0A= HMODULE user32 =3D GetModuleHandle ("user32.dll");=0A= - get_menu_item_info =3D GetProcAddress (user32, "GetMenuItemInfoA");=0A= - set_menu_item_info =3D GetProcAddress (user32, "SetMenuItemInfoA");=0A= + get_menu_item_info =3D (GetMenuItemInfoA_Proc) GetProcAddress = (user32, "GetMenuItemInfoA");=0A= + set_menu_item_info =3D (SetMenuItemInfoA_Proc) GetProcAddress = (user32, "SetMenuItemInfoA");=0A= =0A= staticpro (&menu_items);=0A= menu_items =3D Qnil;=0A= ------=_NextPart_000_0001_01C2886B.A0AA9FD0--