Emacs 21.4a - Solaris 10 x86, Fatal error (11) on exit

Emacs 21.4a - Solaris 10 x86, Fatal error (11) on exit

[Andy Heaps]

Hello Bugs,
        I've compiled emacs21.4a on a Solaris 10 x86 box and get a 
strange "Fatal error (11).Segmentation Fault" on exit of the emacs 
program.  Emacs seems to work okay apart from this exit error.
Any ideas what the problem might be?


gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure 
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as 
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ 
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

Compile error:
--------------
./emacs -q -batch -f list-load-path-shadows
Fatal error (11).*** Signal 11 (ignored)

gdb output:
------------------
(gdb) run
Starting program: /home/andy/emacs-21.4/src/emacs

Program received signal SIGSEGV, Segmentation fault.
0x0808315d in __do_global_dtors_aux ()
(gdb) bt
#0  0x0808315d in __do_global_dtors_aux ()
#1  0x081b3235 in _fini ()
#2  0xfea7f04d in _exithandle () from /lib/libc.so.1
#3  0xfea71c92 in exit () from /lib/libc.so.1
#4  0x0810d2ab in Fkill_emacs (arg=405593092) at emacs.c:1830
#5  0x0816a2b4 in Ffuncall (nargs=1, args=0x80472d0) at eval.c:2662
#6  0x08195ee2 in Fbyte_code (bytestr=405593092, vector=0, 
maxdepth=134509392)
     at bytecode.c:716
#7  0x08169cfa in funcall_lambda (fun=1210387300, nargs=1, 
arg_vector=0x80474e4)
     at eval.c:2851
#8  0x0816a0c9 in Ffuncall (nargs=2, args=0x80474e0) at eval.c:2716
#9  0x0816763a in Fcall_interactively (function=405955612, 
record_flag=405593092,
     keys=1210978304) at callint.c:797
#10 0x08112e5b in Fcommand_execute (cmd=405955612, 
record_flag=405593092, keys=405593092,
     special=405593092) at keyboard.c:9250
#11 0x0811aa4e in command_loop_1 () at keyboard.c:1661
#12 0x0816827d in internal_condition_case (bfun=0x811a680 <command_loop_1>,
     handlers=405715164, hfun=0x811391c <cmd_error>) at eval.c:1267
#13 0x0810f0d2 in command_loop_2 () at keyboard.c:1245
#14 0x081681c1 in internal_catch (tag=0, func=0x810f0b4 
<command_loop_2>, arg=405593092)
     at eval.c:1030
#15 0x0810eecc in command_loop () at keyboard.c:1224
#16 0x0810ef6d in recursive_edit_1 () at keyboard.c:950
#17 0x0810f09d in Frecursive_edit () at keyboard.c:1006
#18 0x0810e3d8 in main (argc=1, argv=0x80479e0, envp=0x80479e8) at 
emacs.c:1547
(gdb)


			Cheers
			   Andy


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andy Heaps
NCAS Centre for Global Atmospheric Modelling,
Meteorology Department,
Reading University,
Earley Gate,
PO Box 243,
Reading RG6 6BB,
U.K.

tel: 0118 378 7840
fax: 0118 378 8316
e-mail: a.j.heaps@rdg.ac.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: Emacs 21.4a - Solaris 10 x86, Fatal error (11) on exit

[Kevin Rodgers]

Andy Heaps wrote:
 >        I've compiled emacs21.4a on a Solaris 10 x86 box and get a
 > strange "Fatal error (11).Segmentation Fault" on exit of the emacs
 > program.  Emacs seems to work okay apart from this exit error.
 > Any ideas what the problem might be?

1. The -batch command line option implies -q (aka -no-init-file); try

	./emacs -no-site-file -batch -f list-load-path-shadows

2. Why would the -f list-load-path-shadows command line option cause
    Fcommand_execute and Fcall_interactively to be called?

 > gcc -v
 > Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
 > Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
 > --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
 > --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
 > --enable-shared
 > Thread model: posix
 > gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
 >
 > Compile error:
 > --------------
 > ./emacs -q -batch -f list-load-path-shadows
 > Fatal error (11).*** Signal 11 (ignored)
 >
 > gdb output:
 > ------------------
 > (gdb) run
 > Starting program: /home/andy/emacs-21.4/src/emacs
 >
 > Program received signal SIGSEGV, Segmentation fault.
 > 0x0808315d in __do_global_dtors_aux ()
 > (gdb) bt
 > #0  0x0808315d in __do_global_dtors_aux ()
 > #1  0x081b3235 in _fini ()
 > #2  0xfea7f04d in _exithandle () from /lib/libc.so.1
 > #3  0xfea71c92 in exit () from /lib/libc.so.1
 > #4  0x0810d2ab in Fkill_emacs (arg=405593092) at emacs.c:1830
 > #5  0x0816a2b4 in Ffuncall (nargs=1, args=0x80472d0) at eval.c:2662
 > #6  0x08195ee2 in Fbyte_code (bytestr=405593092, vector=0,
 > maxdepth=134509392)
 >     at bytecode.c:716
 > #7  0x08169cfa in funcall_lambda (fun=1210387300, nargs=1,
 > arg_vector=0x80474e4)
 >     at eval.c:2851
 > #8  0x0816a0c9 in Ffuncall (nargs=2, args=0x80474e0) at eval.c:2716
 > #9  0x0816763a in Fcall_interactively (function=405955612,
 > record_flag=405593092,
 >     keys=1210978304) at callint.c:797
 > #10 0x08112e5b in Fcommand_execute (cmd=405955612,
 > record_flag=405593092, keys=405593092,
 >     special=405593092) at keyboard.c:9250
 > #11 0x0811aa4e in command_loop_1 () at keyboard.c:1661
 > #12 0x0816827d in internal_condition_case (bfun=0x811a680 
<command_loop_1>,
 >     handlers=405715164, hfun=0x811391c <cmd_error>) at eval.c:1267
 > #13 0x0810f0d2 in command_loop_2 () at keyboard.c:1245
 > #14 0x081681c1 in internal_catch (tag=0, func=0x810f0b4
 > <command_loop_2>, arg=405593092)
 >     at eval.c:1030
 > #15 0x0810eecc in command_loop () at keyboard.c:1224
 > #16 0x0810ef6d in recursive_edit_1 () at keyboard.c:950
 > #17 0x0810f09d in Frecursive_edit () at keyboard.c:1006
 > #18 0x0810e3d8 in main (argc=1, argv=0x80479e0, envp=0x80479e8) at
 > emacs.c:1547
 > (gdb)

-- 
Kevin Rodgers

Re: Emacs 21.4a - Solaris 10 x86, Fatal error (11) on exit

[Jeff Blaine]

 >        I've compiled emacs21.4a on a Solaris 10 x86 box and get a
 > strange "Fatal error (11).Segmentation Fault" on exit of the emacs
 > program.  Emacs seems to work okay apart from this exit error.
 > Any ideas what the problem might be?

Kevin Rodgers commented:

         1. The -batch command line option implies
            -q (aka -no-init-file); try

            ./emacs -no-site-file -batch -f list-load-path-shadows

Kevin, I think this is missing the main problem.

% ./emacs -no-site-file -batch -f list-load-path-shadows
Fatal error (11).Segmentation Fault (core dumped)
%

This is on Solaris 10 for SPARC in my case, not x86.  The
problem exists back in 21.3 under Solaris 10 as well FWIW.

Note, however, that as Andy Heaps mentioned above, emacs
does in fact run (./emacs), then segfaults at exit time.

Curious how there's no Emacs 21.x up on sunfreeware.com yet
after the OS has been out for over a year now.

Any ideas?  I have tried both with GNU ld/as as part of
binutils and also /usr/ccs/bin/ld (and as).  Same problem

Re: Emacs 21.4a - Solaris 10 x86, Fatal error (11) on exit

[Kevin Rodgers]

Jeff Blaine wrote:
 >  >        I've compiled emacs21.4a on a Solaris 10 x86 box and get a
 >  > strange "Fatal error (11).Segmentation Fault" on exit of the emacs
 >  > program.  Emacs seems to work okay apart from this exit error.
 >  > Any ideas what the problem might be?
 >
 > Kevin Rodgers commented:
 >
 >         1. The -batch command line option implies
 >            -q (aka -no-init-file); try
 >
 >            ./emacs -no-site-file -batch -f list-load-path-shadows
 >
 > Kevin, I think this is missing the main problem.

I was just pointing out that there was no need to specify -q, and that
omitting -no-site-file left open the possibility that some local
configuration was triggering the error.  Not to blame such a
configuration, but just to see whether the C crash could be traced back
to a particular piece of Lisp.

 > % ./emacs -no-site-file -batch -f list-load-path-shadows
 > Fatal error (11).Segmentation Fault (core dumped)
 > %
 >
 > This is on Solaris 10 for SPARC in my case, not x86.  The
 > problem exists back in 21.3 under Solaris 10 as well FWIW.
 >
 > Note, however, that as Andy Heaps mentioned above, emacs
 > does in fact run (./emacs), then segfaults at exit time.
 >
 > Curious how there's no Emacs 21.x up on sunfreeware.com yet
 > after the OS has been out for over a year now.

The CSW (Community SoftWare) site at http://www.blastwave.org/ provides
21.3 binaries for Solaris 8 through 11 on both SPARC and x86, all built
on Solaris 8, from the stable respository.  It also provides 21.4
binaries for those platforms from the unstable repository, also built on
version 8.  See first the pkg-get site at
http://www.bolthole.com/solaris/pkg-get.html

 > Any ideas?  I have tried both with GNU ld/as as part of
 > binutils and also /usr/ccs/bin/ld (and as).  Same problem

What does ldd report for the emacs executable?  Do you have
LD_LIBRARY_PATH set?

-- 
Kevin Rodgers

Re: Emacs 21.4a - Solaris 10 x86, Fatal error (11) on exit

[Jeff Blaine]

FWIW, this is solved with 21.3 by getting the CVS version
of src/unexelf.c and src/unexsol.c as of 12/15/2005 at
least.

How to get the files:

cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/emacs \
co emacs

I would be surprised if the same did not work for 21.4

Works for SPARC and x86 Solaris 10 with GCC 3.4 (and I
bet others).

Jeff Blaine wrote:
>  >        I've compiled emacs21.4a on a Solaris 10 x86 box and get a
>  > strange "Fatal error (11).Segmentation Fault" on exit of the emacs
>  > program.  Emacs seems to work okay apart from this exit error.
>  > Any ideas what the problem might be?
> 
> Kevin Rodgers commented:
> 
>         1. The -batch command line option implies
>            -q (aka -no-init-file); try
> 
>            ./emacs -no-site-file -batch -f list-load-path-shadows
> 
> Kevin, I think this is missing the main problem.
> 
> % ./emacs -no-site-file -batch -f list-load-path-shadows
> Fatal error (11).Segmentation Fault (core dumped)
> %
> 
> This is on Solaris 10 for SPARC in my case, not x86.  The
> problem exists back in 21.3 under Solaris 10 as well FWIW.
> 
> Note, however, that as Andy Heaps mentioned above, emacs
> does in fact run (./emacs), then segfaults at exit time.
> 
> Curious how there's no Emacs 21.x up on sunfreeware.com yet
> after the OS has been out for over a year now.
> 
> Any ideas?  I have tried both with GNU ld/as as part of
> binutils and also /usr/ccs/bin/ld (and as).  Same problem
> 
>