emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: 21.1 on Solaris 2.5.1 (sparc), on terminal, core dum


From: Harald . Maier . BW
Subject: Re: address@hidden: 21.1 on Solaris 2.5.1 (sparc), on terminal, core dump]
Date: 01 Dec 2001 14:58:31 +0000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Richard Stallman <address@hidden> writes:

> Is there a Solaris user that can take a look at this problem?

I tested this as described below and the test case happened on a
Solaris 2.5.1 system. It happened _not_ with the same emacs executable
on a Solaris 2.6 or on a Solaris 2.8 system. It did also not happen
with my X compiled emacs under 2.5.1. But currently I am not sure if
this is compiled with gcc or the SUN compiler.

Harald

Configured for `sparc-sun-solaris2.5.1'.

  Where should the build process find the source code?    /home/maierhar/build/e
macs-21.1
  What operating system and machine description files should Emacs use?
        `s/sol2-5.h' and `m/sparc.h'
  What compiler should emacs be built with?               gcc -g
  Should Emacs use the GNU version of malloc?             yes
  Should Emacs use a relocating allocator for buffers?    yes
  Should Emacs use mmap(2) for buffer allocation?         no
  What window system should Emacs use?                    none
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                NONE
  Where do we find X Windows libraries?                   NONE
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   no
  Does Emacs use -ljpeg?                                  no
  Does Emacs use -ltiff?                                  no
  Does Emacs use -lungif?                                 no
  Does Emacs use -lpng?                                   no
  Does Emacs use X toolkit scroll bars?                   no

> 
> From: Koji Hino <address@hidden>
> Subject: 21.1 on Solaris 2.5.1 (sparc), on terminal, core dump
> To: address@hidden
> Date: Thu, 29 Nov 2001 17:52:59 -0800 (PST)
> Organization: C&C Research Laboratories (CCRL), NEC USA, Inc.
> 
> Hi,
> 
> # I am not on this list, so please CC to me if you want to contact me.
> 
> I found that Emacs 21.1 on terminal (not w/ X) dumps core when using
> subprocess...
> 
> Emacs source: plain emacs-21.1.tar.gz with leim-21.1.tar.gz
> Platform: Solaris 2.5.1 on sparc (Ultra5) with recent Sun's recommended 
> patches
>         NAME: Solaris 2.5.1 Recommended Patch Cluster
>         DATE: Nov/15/01
> Configure: env CFLAGS="-O -g" ../emacs-21.1/configure  --prefix=/usr/Local 
> --without-x
> CC: gcc version 2.95.3 20010315 (release)
> 
> Note that same bug arise with X compiled-in binary (no --without-x
> switch to configure), if it runs under terminal with 'emacs -q -nw'.
> 
> How to coredump:
> 
> % ./src/emacs -q [ret]
> 
> C-g
>  -> Bell rings, 'Quit' printed on mini buffer. good.
> 
> M-x shell [ret]
> C-g
> Fatal error (11).Segmentation fault
> 
> gdb backtrace:
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  <signal handler called>
> #2  0xef5bce0c in poll () from /usr/lib/libc.so.1
> #3  0xef5da404 in select () from /usr/lib/libc.so.1
> #4  0x0010bd04 in wait_reading_process_input (time_limit=30, microsecs=0,
>     read_kbd=268435455, do_display=1)
>     at /hirosige/src/emacs/emacs-21.1/src/process.c:2596
> #5  0x0001b9bc in sit_for (sec=30, usec=0, reading=1, display=1,
>     initial_display=0) at /hirosige/src/emacs/emacs-21.1/src/dispnew.c:6243
> #6  0x0006f2b8 in read_char (commandflag=1, nmaps=2, maps=0xefffee20,
>     prev_event=270769156, used_mouse_menu=0xefffee48)
>     at /hirosige/src/emacs/emacs-21.1/src/keyboard.c:2491
> #7  0x00075cd8 in read_key_sequence (keybuf=0xefffef80, bufsize=30,
>     prompt=270769156, dont_downcase_last=0, can_return_switch_frame=1,
>     fix_current_buffer=1) at 
> /hirosige/src/emacs/emacs-21.1/src/keyboard.c:8180
> #8  0x0006d174 in command_loop_1 ()
>     at /hirosige/src/emacs/emacs-21.1/src/keyboard.c:1440
> #9  0x000d2044 in internal_condition_case (bfun=0x6cdc0 <command_loop_1>,
>     handlers=270897228, hfun=0x6c880 <cmd_error>)
>     at /hirosige/src/emacs/emacs-21.1/src/eval.c:1267
> #10 0x0006cbe4 in command_loop_2 ()
>     at /hirosige/src/emacs/emacs-21.1/src/keyboard.c:1245
> #11 0x000d1b74 in internal_catch (tag=270843412,
>     func=0x6cbc0 <command_loop_2>, arg=270769156)
>     at /hirosige/src/emacs/emacs-21.1/src/eval.c:1030
> #12 0x0006cb68 in command_loop ()
>     at /hirosige/src/emacs/emacs-21.1/src/keyboard.c:1224
> #13 0x0006c590 in recursive_edit_1 ()
>     at /hirosige/src/emacs/emacs-21.1/src/keyboard.c:950
> #14 0x0006c70c in Frecursive_edit ()
>     at /hirosige/src/emacs/emacs-21.1/src/keyboard.c:1006
> #15 0x0006b16c in main (argc=2, argv=0xeffff4b4, envp=0x1)
>     at /hirosige/src/emacs/emacs-21.1/src/emacs.c:1547
> ...
> 
> It seems that there are no signal handler for SIGINT, in this case..
> 
> Workaround:
> add
> #define HAVE_VFORK 1
> to src/config.h or src/s/sol2-5.h.
> With HAVE_VFORK enabled, emacs works fine.
> 
> Consideration:
> configure script says this machine has working vfork, but there are no
> #define enabled from this judgement.
> 
> Here is what ./configure said:
> ....
> checking for pid_t... yes
> checking for vfork.h... no
> checking for working vfork... yes
> checking for size_t... yes
> ....
> 
> But, even without vfork, emacs should set signal handler correctly. Is
> this problem come from Solaris 2.5.1's bad behavior?
> 
> Are there anyone who love terminal? :-)
> # I am 'screen' lover, so I have to use Emacs with terminal..
> 
> Koji
> 
> ====================================================================
> Koji HINO(HINO is my family name)
> C&C Research Laboratories, NEC USA, Inc.
> 110 Rio Robles, San Jose, CA 95134, USA
> E-mail: address@hidden
> - ----------
> DISCLAIMER: this message is the author's personal opinion and does not
> constitute the support, opinion, or policy of NEC USA, Inc.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]