Re: Babylon crashes Emacs

["Juanma Barranquero" <lekktu@gmail.com>]

On 6/23/07, Eli Zaretskii <eliz@gnu.org> wrote:

> I don't have Babylon where I'm typing this, so how about if
> you try to see what message(s) Babylon sends us?  For example, using
> Winspector (http://www.windows-spy.com/).

I've been trying for a while, but I don't see anything unusual. In the
last few seconds between the Ctrl+Rbutton and the crash Emacs received
the following messages:

WM_GETTEXTLENGTH            : 52 times
WM_NCHITTEST                : 31
WM_MOUSEMOVE                : 30
WM_SETCURSOR                : 30
WM_USER + 7174 (0x00002006) : 26
WM_GETTEXT                  : 26
WM_USER + 20 (0x00000414)   : 17
WM_NCACTIVATE               :  1
WM_WINDOWPOSCHANGING        :  1
WM_ACTIVATEAPP              :  1
WM_MOUSELEAVE               :  1
WM_WINDOWPOSCHANGED         :  1

(I can send you the XML dump with the timing and parameter/return
value info, if you want.) I don't know what the WM_USER + 7174 is, but
the rest is more or less as expected. (Well, the barrage of
WM_GETTEXT(LENGTH)? messages is unexpected, but I think it's just
Windows trying to make sure it got the window title right.)

Curiously, I don't get always similar info from DrMinGW, though most
of the crashes are like this one:

emacs.exe caused an Access Violation at location 7e3b1690 in module
USER32.dll Writing to location 7e39f7f9.

Registers:
eax=00000001 ebx=00000000 ecx=7e39f7f9 edx=0000000c esi=207ffeec edi=207ffeec
eip=7e3b1690 esp=207ffe54 ebp=7e39f805 iopl=0         nv up ei ng nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286

Call stack:
AddrPC     AddrReturn AddrFrame  AddrStack  Params
7E3B1690   FBFFFFFF   7E39F805   207FFE54   097E3C21   907E3C22
90909090   8B55FF8B
7E3B1690  USER32.dll:7E3B1690  GetOpenClipboardWindow
FBFFFFFF   00000000   FF0010C2   207FFE54   00000000   00000000
00000000   00000000
FBFFFFFF

with the reference to GetOpenClipboardWindow.

> I don't see that my backtrace is more detailed than yours.  Note that
> in your case we are deep inside system DLLs, where debug info is not
> available.

You're right. I don't know what was I thinking...

             Juanma