Re: Fatal error (11)

Re: Fatal error (11)

[Thien-Thi Nguyen]

Hank Chiang <hankchiang0911@gmail.com> writes:

> Program received signal SIGSEGV, Segmentation fault.
> 0xb777a46b in _XimOffKeysCheck ()
>    from /usr/lib/X11/locale/lib/common/ximcp.so.2

segv is what you get from dereferencing a NULL pointer,
or from accessing memory w/o proper privs or alignment,
or other memory-related problems.  (there is always the
random gamma ray -- unlikely if this is reproducible. :-)

after the message, the first line gives the address 
and function name of the offending code, and the second
in which file (shared object library, here) that code
is to be found.

this particular library seems to be installed as part
of the system, judging from the /usr/lib/X11 prefix,
which means you cannot easily debug it directly unless
you are prepared to build and install (under another
prefix) X11 w/ debugging support.

however, you can debug it from the emacs side.  it
looks like you have found the gdb "continue" command.
now you need to dig into the "bt" command.  for this
command to be useful, you need to build emacs w/
debugging support (normally "gcc -g" suffices).  if
you can't/won't do that, there is no point reading
the rest of this message.

the aim at this stage is to determine whether or not it
is emacs' fault or whether it is the library's fault,
so as to be able to procure a fix yourself, and/or report
the situation to the appropriate maintainers (the latter
called "spreading the joy" by curmudgeons everywhere ;-).

thi

Fatal error (11)

[Hank Chiang]

Hello All,

Fatal error (11) occurs when my emacs is running in X.
Does anyone know what the "Fatal error (11)" means and how to resolve
this problem?

The following is the emacs version infomation and the message with "gdb
emacs".

Emacs versoin:

GNU Emacs 21.4.1 (i686-pc-linux-gnu, Motif Version 2.2.3) of 2005-04-07
on localhost

==============================================================================
hank@localhost hank $ emacs
Fatal error (11).程式記憶體區段錯誤
hank@localhost hank $ gdb emacs
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols
found)
Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /usr/bin/emacs
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0xb777a46b in _XimOffKeysCheck ()
   from /usr/lib/X11/locale/lib/common/ximcp.so.2
(gdb) continue
Continuing.
Fatal error (11).
Program received signal SIGSEGV, Segmentation fault.
0xb7a04c51 in kill () from /lib/libc.so.6
(gdb)
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)


Hank

Re: Fatal error (11)

[Peter Dyballa]

Am 24.04.2005 um 17:00 schrieb Hank Chiang:

> Does anyone know what the "Fatal error (11)" means and how to resolve
> this problem?
>

11 is a signal value. kill -l will tell you. 11 is usually a 
segmentation violation: some pointer was pointing to memory outside 
Emacs' process space when it was accessed. Could be wrong C header 
files?

--
Greetings

   Pete

If you're not confused, you're not paying attention