GNU bug report logs -
#15962
24.3.50; emacs_backtrace.txt
Previous Next
Full log
Message #46 received at 15962 <at> debbugs.gnu.org (full text, mbox):
> > Sorry, no, it was not M-x but C-h v that I typed. So altogether I did
> > mouse-1 C-h v.
>
> Did the "C-h" prompt in the minibuffer appear or didn't it?
I don't think so, but I can't swear to it. My impression was that Emacs
conked out as soon as I clicked mouse-1 in the frame. But as I did not
see the popup popped up on top (it popped up behind other windows), I
cannot say when the crash really occurred. I clicked mouse-1 and
immediately typed C-h v, automatically. Somewhere between moving the
mouse to the Emacs frame and hitting `v', Emacs bombed out.
> Also, if this happens frequently, perhaps you could take notes of the
> last things you did before the crash (not just the last click/command,
> but also a few before that), and describe the window/frame
> configuration at the time of the crash.
Sure, I will try to. But keep in mind that in this case I had not
used Emacs for quite a while - I was using other Windows apps. Emacs
was just sitting there peacefully, frames open (e.g., not iconified),
but without me interacting with it.
> Note that moving the mouse away from an Emacs frame and/or moving it
> into a frame, as well as clicking on it causes a message to be sent by
> Windows that Emacs processes. That processing could somehow trigger
> the crash. So these details are important parts of the riddle.
Yes, it could have crashed as soon as I moved the mouse over an Emacs
frame. Or when I hit `down-mouse-1'. Or released `mouse-1'. Or hit
`C-h v'. I can at least say that it did not happen when I moved the
mouse away from Emacs, to use other apps. I would have noticed that,
since the frames went blank when the popup popped up (behind other
windows).
This bug report was last modified 11 years and 178 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.