This could be a bitch to find.... I tried <Alt F><Esc> for a couple of minutes,
and couldn't get it to happen. nedit was one of the apps that I used regularly
while writing the menu stuff, since it does some _really_ interesting stuff
during this.
Is there anyway that you, or someone else that sees this problem, could run
gdb/nedit from another terminal while displaying it on the offending system. If
not, Xnest may be another way, but I'm not sure how it will react to a
breakpoint while the menu grabs are in place. ddd may be yet another option, I
think that it will release the grabs when it stops. Without a stack trace, and
without being able to reproduce this I'm not sure what else we can do. Oh, wait
a minute....."DEBUGSOURCES=all nedit" may show something interesting. Also can
you make it happen if you run "nedit -sync"????
On 15-Jun-00 at 03:09, Jim Lemon ([EMAIL PROTECTED]) wrote:
> Hardware
> Gigabyte GA-5AA mainboard
> AMD-K2 CPU
> 64M RAM
> OS
> RedHat Linux v6.1
> and...
> KDE window manager
> NEdit v5.1.1
> lesstif-0.91.0
>
> Occasionally when accessing the File menu in NEdit with the Alt-F key
> combination, the menu appears briefly (I thought it was blank, but have
> since discovered that the "New" item appears) and NEdit exits. This has
> not happened using the mouse to access the menu(s). I didn't know how
> badly it was exiting until I tried gdb (as suggested on your pages). It
> only took a couple of minutes until I managed to get it to bomb. Things
> hung with the cursor in "file menu" configuration (right-pointing
> arrow), the file menu displayed with only the "New" item showing and no
> response from _anything_. The cursor would move, but did not change in
> response to location, nor did buttons or most keys do anything (I
> finally left X-Windows with Ctrl-Alt-BS and rebooted). I could not
> switch windows, but I could see part of the console on which I had
> started gdb, and peeking out was:
>
> ntation fault
> sr/X11R6/lib/libXt.so.6
>
> Jim
>
>
