Killing a frame sometimes kills emacs

Killing a frame sometimes kills emacs

[Tassilo Horn]

Hi all,

since lately, I have a really annoying problem with the current emacs
trunk.  My current emacs is about 4 days old, but I've hit that problem
already when I came back from holiday three weeks ago.

The problem is that frequently, killing an emacs X11 frame kills the
complete emacs instance.  It doesn't crash or so, but it's just like if
I had called `kill-emacs'.

The usual steps are:

  1. Start emacs (the server is activated from my .emacs)
  2. Work for several hours without issues
  3. emacsclient -c [maybe-a-file.txt]
  4. kill the client frame with C-x 5 0, C-x #, or the X knob at the
     window decoration ==> BANG! Emacs is gone...

My problem is that I'm totally unable to reproduce the issue.  I've just
tried to activate and use all packages/modes I usually work with (Gnus,
Org, SLIME/Clojure, Elisp, AUCTeX, rcirc) step by step, but still
creating and killing frames works as it's supposed to do.

Do you have any suggestions on how to debug this issue?

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[joakim]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Hi all,
>
> since lately, I have a really annoying problem with the current emacs
> trunk.  My current emacs is about 4 days old, but I've hit that problem
> already when I came back from holiday three weeks ago.
>
> The problem is that frequently, killing an emacs X11 frame kills the
> complete emacs instance.  It doesn't crash or so, but it's just like if
> I had called `kill-emacs'.
>
> The usual steps are:
>
>   1. Start emacs (the server is activated from my .emacs)
>   2. Work for several hours without issues
>   3. emacsclient -c [maybe-a-file.txt]
>   4. kill the client frame with C-x 5 0, C-x #, or the X knob at the
>      window decoration ==> BANG! Emacs is gone...
>
> My problem is that I'm totally unable to reproduce the issue.  I've just
> tried to activate and use all packages/modes I usually work with (Gnus,
> Org, SLIME/Clojure, Elisp, AUCTeX, rcirc) step by step, but still
> creating and killing frames works as it's supposed to do.
>
> Do you have any suggestions on how to debug this issue?
>
> Bye,
> Tassilo

Not much help, but I use the below bash script to run Emacs.
That way I can get a backtrace most of the time which helps.

(I'm also suffering from some weirdo heisenbug. Lately it has been
something involving overlays and pop_it at xdisp.c:5492. It might be
something local though)

#!/bin/sh
#cd to src dir to load emacs gdb macros
cd ~/build_myprojs/emacsnew/emacs.bzr/xwidget/src/
xterm -e gdb -ex run  emacs

-- 
Joakim Verona

Re: Killing a frame sometimes kills emacs

[chad]

Do you have a non-nill confirm-kill-emacs?  If not, try setting it.  If so,
have you tried (debug-on-entry 'kill-emacs)?

Hope that helps,
*Chad

On Aug 31, 2011, at 1:16 PM, Tassilo Horn wrote:

> Do you have any suggestions on how to debug this issue?

Re: Killing a frame sometimes kills emacs

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Date: Wed, 31 Aug 2011 22:16:55 +0200
> 
> Do you have any suggestions on how to debug this issue?

Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
this happens again, tell use who called it by showing the backtrace.

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Date: Wed, 31 Aug 2011 22:16:55 +0200
>> 
>> Do you have any suggestions on how to debug this issue?
>
> Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
> this happens again, tell use who called it by showing the backtrace.

Ok, breakpoint is set.  Let's see what happens...

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> From: Tassilo Horn <tassilo@member.fsf.org>
>> Date: Wed, 31 Aug 2011 22:16:55 +0200
>> 
>> Do you have any suggestions on how to debug this issue?
>
> Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
> this happens again, tell use who called it by showing the backtrace.

It turned out to be a crash, not something calling Fkill_emacs.  Here's
the backtrace:

--8<---------------cut here---------------start------------->8---
Breakpoint 1 at 0x4f23dd: file emacs.c, line 1985.
Starting program: /usr/bin/emacs-24 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 31725)]
[New Thread 0x7fffe667f700 (LWP 31726)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0  0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1  0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3  0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5  0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7  0x00000000004e157c in xg_display_close (dpy=0x6ca0020) at gtkutil.c:182
        gdpy = 0xd682e0
#8  0x00000000004afc49 in x_delete_terminal (terminal=<optimized out>)
    at xterm.c:10607
        dpyinfo = 0x698d3e0
#9  0x00000000004a40f2 in Fdelete_terminal (terminal=107998581, 
    force=<optimized out>) at terminal.c:345
        t = 0x66fed70
#10 0x00000000004235cc in delete_frame (frame=99991829, force=<optimized out>)
    at frame.c:1379
        tmp = <optimized out>
        terminal = <optimized out>
        f = 0x5f5c110
        sf = 0x121b7e0
        kb = 0x0
        minibuffer_selected = 0
        tooltip_frame = 0
#11 0x000000000042382a in Fdelete_frame (frame=<optimized out>, 
    force=<optimized out>) at frame.c:1516
No locals.
#12 0x000000000055d81f in Ffuncall (nargs=3, args=0x7fffffffc9f0)
    at eval.c:2993
        fun = <optimized out>
        original_fun = <optimized out>
        funcar = <optimized out>
        numargs = <optimized out>
        lisp_numargs = <optimized out>
        val = <optimized out>
        backtrace = {next = 0x7fffffffcb70, function = 0x7fffffffc9f0, 
          args = 0x7fffffffc9f8, nargs = 2, debug_on_exit = 0}
        internal_args = 0x7fffffffc9f8
        i = <optimized out>
#13 0x000000000058fafe in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, args_template=11782610, 
    nargs=<optimized out>, args=<optimized out>) at bytecode.c:785
        count = 5
        op = <optimized out>
        vectorp = 0x932cd0
        stack = {pc = 0xa52aa6 "\202I", byte_string = 9645217, 
          byte_string_start = 0xa52a62 "\b\211\030:\203\r", 
          constants = 9645253, next = 0x0}
        top = 0x7fffffffc9f0
        result = <optimized out>
#14 0x000000000055d53b in funcall_lambda (fun=9645157, nargs=1, 
    arg_vector=0x7fffffffcc38) at eval.c:3221
        val = <optimized out>
        syms_left = <optimized out>
        next = <optimized out>
        lexenv = 11782610
        i = <optimized out>
        optional = <optimized out>
        rest = <optimized out>
#15 0x000000000055d927 in Ffuncall (nargs=2, args=0x7fffffffcc30)
    at eval.c:3039
        fun = <optimized out>
        original_fun = 12164530
        funcar = <optimized out>
        numargs = <optimized out>
        lisp_numargs = <optimized out>
        val = <optimized out>
        backtrace = {next = 0x7fffffffce20, function = 0x7fffffffcc30, 
          args = 0x7fffffffcc38, nargs = 1, debug_on_exit = 0}
        internal_args = <optimized out>
        i = <optimized out>
#16 0x000000000055ae47 in Fcall_interactively (function=12164530, 
    record_flag=11782610, keys=1) at callint.c:857
        val = <optimized out>
        args = 0x7fffffffcc30
        visargs = 0x7fffffffcc10
        specs = <optimized out>
        filter_specs = <optimized out>
        teml = <optimized out>
        up_event = 11782610
        enable = 113302176
        next_event = <optimized out>
        prefix_arg = 11782610
        string = <optimized out>
        tem = <optimized out>
        varies = 0x7fffffffcbf0 ""
        i = <optimized out>
        nargs = <optimized out>
        foo = <optimized out>
        prompt1 = '\000' <repeats 99 times>
        tem1 = <optimized out>
        arg_from_tty = <optimized out>
        key_count = 1
        record_then_fail = 0
        save_this_command = 11782610
        save_last_command = 12672082
        save_this_original_command = 11782610
        save_real_this_command = 11782610
#17 0x000000000055d837 in Ffuncall (nargs=4, args=0x7fffffffce90)
    at eval.c:2997
        fun = <optimized out>
        original_fun = <optimized out>
        funcar = <optimized out>
        numargs = <optimized out>
        lisp_numargs = <optimized out>
        val = <optimized out>
        backtrace = {next = 0x0, function = 0x7fffffffce90, 
          args = 0x7fffffffce98, nargs = 3, debug_on_exit = 0}
        internal_args = 0x7fffffffce98
        i = <optimized out>
#18 0x000000000055db17 in call3 (fn=<optimized out>, arg1=<optimized out>, 
    arg2=<optimized out>, arg3=<optimized out>) at eval.c:2790
        ret_ungc_val = 14066416
        args = {11988402, 12164530, 11782610, 113302181}
#19 0x00000000004f4349 in Fcommand_execute (cmd=12164530, 
    record_flag=11782610, keys=113302181, special=<optimized out>)
    at keyboard.c:10271
        final = <optimized out>
        tem = <optimized out>
        prefixarg = 11782610
#20 0x00000000004ff15f in read_char (commandflag=1, nmaps=6, 
    maps=0x7fffffffd2a0, prev_event=11782610, used_mouse_menu=0x7fffffffd41c, 
    end_time=0x0) at keyboard.c:2885
        prev_buffer = 0x5b2eed0
        c = 111001606
        local_getcjmp = {{__jmpbuf = {28823509, 4398587453124662626, 11782610, 
              11782610, 111002422, 15938864, -4398585942129486494, 
              4398585288136217954}, __mask_was_saved = 0, __saved_mask = {
              __val = {18446744073709551615, 4294967297, 66, 0, 0, 0, 0, 0, 0, 
                0, 0, 95612629, 5932106, 0, 0, 95612624}}}}
        save_jump = {{__jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, 
            __mask_was_saved = 0, __saved_mask = {__val = {
                0 <repeats 16 times>}}}}
        key_already_recorded = 0
        tem = 12164530
        save = <optimized out>
        previous_echo_area_message = 11782610
        also_record = 11782610
        reread = 0
        polling_stopped_here = 0
        orig_kboard = 0xf33530
#21 0x0000000000500202 in read_key_sequence (keybuf=0x7fffffffd510, 
    bufsize=30, prompt=11782610, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9280
        interrupted_kboard = 0xf33530
        interrupted_frame = 0x121b7e0
        key = <optimized out>
        used_mouse_menu = 0
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        local_first_binding = 0
        from_string = 11782610
        count = 2
        t = 0
        echo_start = 0
        keys_start = 0
        nmaps = <optimized out>
        nmaps_allocated = 6
        defs = 0x7fffffffd260
        submaps = 0x7fffffffd2a0
        orig_local_map = 38705910
        orig_keymap = 11782610
        localized_local_map = 0
        first_binding = 0
        first_unbound = 31
        mock_input = 0
        fkey = {parent = 17464630, map = 17464630, start = 0, end = 0}
        keytran = {parent = 11762086, map = 11762086, start = 0, end = 0}
        indec = {parent = 17464614, map = 17464614, start = 0, end = 0}
        shift_translated = 0
        delayed_switch_frame = 11782610
        original_uppercase = 0
        original_uppercase_position = -1
        dummyflag = 0
        starting_buffer = 0x5b2eed0
        fake_prefixed_keys = 11782610
#22 0x0000000000501e6a in command_loop_1 () at keyboard.c:1445
        cmd = <optimized out>
        keybuf = {96, 76, 0, 11782610, 11782658, 11782610, 11834802, 66165345, 
          140737488344496, 5738643, 7237112172834486626, -155, 
          140737488344496, 5738306, 11782610, 92448534, 92448534, 11782610, 0, 
          -1, 140737488344544, 5206430, 11782610, 11782610, 92448534, 5206735, 
          0, 12347184, 11782610, 0}
        i = <optimized out>
        prev_modiff = 3409
        prev_buffer = 0x5b2eed0
#23 0x000000000055bddc in internal_condition_case (
    bfun=0x501b7d <command_loop_1>, handlers=11834802, 
    hfun=0x4f71bf <cmd_error>) at eval.c:1491
        val = <optimized out>
        c = {tag = 11782610, val = 11782610, next = 0x7fffffffd7d0, 
          gcpro = 0x0, jmp = {{__jmpbuf = {12347184, 4398587353752950114, 
                12347184, 11782610, 0, -1, -4398585942355978910, 
                4398585508186576226}, __mask_was_saved = 0, __saved_mask = {
                __val = {0, 0, 18446744073709551615, 0, 140737351956354, 1, 0, 
                  0, 140737257920136, 0, 12347184, 12347216, 12347184, 
                  11782610, 140737351980821, 0}}}}, backlist = 0x0, 
          handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, 
          poll_suppress_count = 1, interrupt_input_blocked = 0, 
          byte_stack = 0x0}
        h = {handler = 11834802, var = 11782610, chosen_clause = 11782658, 
          tag = 0x7fffffffd690, next = 0x0}
#24 0x00000000004f6951 in command_loop_2 (ignore=<optimized out>)
    at keyboard.c:1156
        val = 14066416
#25 0x000000000055bcb5 in internal_catch (tag=
Cannot access memory at address 0xffffffffffffffe0
) at eval.c:1248
        c = {tag = 11830594, val = 11782610, next = 0x0, gcpro = 0x0, jmp = {{
              __jmpbuf = {12347184, 4398587353752950114, 12347184, 11782610, 
                0, -1, -4398585942406310558, 4398585508193260898}, 
              __mask_was_saved = 0, __saved_mask = {__val = {11782610, 
                  11810656, 0, 1, 5559583, 140737261559512, 0, 0, 12075264, 
                  12075266, 11782610, 11782610, 0, 18446744073709551615, 
                  5632154, 140737488345352}}}}, backlist = 0x0, 
          handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, 
          poll_suppress_count = 1, interrupt_input_blocked = 0, 
          byte_stack = 0x0}
#26 0x00000000004f6ce7 in command_loop () at keyboard.c:1135
No locals.
#27 recursive_edit_1 () at keyboard.c:756
        val = 12347184
#28 0x00000000004f7017 in Frecursive_edit () at keyboard.c:820
        buffer = 11782610
#29 0x00000000004f3cb5 in main (argc=<optimized out>, argv=0x7fffffffdd28)
    at emacs.c:1698
        dummy = 140737353841976
        stack_bottom_variable = 0 '\000'
        skip_args = 0
        rlim = {rlim_cur = 8720000, rlim_max = 18446744073709551615}
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x100000000 <Address 0x100000000 out of bounds>
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff2466737 in kill () from /lib64/libc.so.6
A debugging session is active.

	Inferior 1 [process 31722] will be killed.

Quit anyway? (y or n) 
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Sep 2011 12:09:30 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Hi Eli,
> 
> >> From: Tassilo Horn <tassilo@member.fsf.org>
> >> Date: Wed, 31 Aug 2011 22:16:55 +0200
> >> 
> >> Do you have any suggestions on how to debug this issue?
> >
> > Run Emacs under a debugger, put a breakpoint on Fkill_emacs, and when
> > this happens again, tell use who called it by showing the backtrace.
> 
> It turned out to be a crash, not something calling Fkill_emacs.  Here's
> the backtrace:

What about the Lisp backtrace?  And since this is an optimized build,
the backtrace is almost useless anyway.  Can you try reproducing this
in an unoptimized build?

> #7  0x00000000004e157c in xg_display_close (dpy=0x6ca0020) at gtkutil.c:182
>         gdpy = 0xd682e0
> #8  0x00000000004afc49 in x_delete_terminal (terminal=<optimized out>)
>     at xterm.c:10607
>         dpyinfo = 0x698d3e0
> #9  0x00000000004a40f2 in Fdelete_terminal (terminal=107998581, 
>     force=<optimized out>) at terminal.c:345
>         t = 0x66fed70
> #10 0x00000000004235cc in delete_frame (frame=99991829, force=<optimized out>)
>     at frame.c:1379
>         tmp = <optimized out>
>         terminal = <optimized out>
>         f = 0x5f5c110
>         sf = 0x121b7e0
>         kb = 0x0
>         minibuffer_selected = 0
>         tooltip_frame = 0
> #11 0x000000000042382a in Fdelete_frame (frame=<optimized out>, 
>     force=<optimized out>) at frame.c:1516

This part does look as if Emacs was going to close the X display where
the frame was displayed.  Were all other frames in that session on
other displays?  If not, how come Emacs is about to delete the
terminal?  Here's the relevant code:

    if (terminal->reference_count == 0)
      {
	Lisp_Object tmp;
	XSETTERMINAL (tmp, terminal);

        kb = NULL;
	Fdelete_terminal (tmp, NILP (force) ? Qt : force);
      }

Can you look at the value of terminal->reference_count?

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> It turned out to be a crash, not something calling Fkill_emacs.  Here's
>> the backtrace:
>
> What about the Lisp backtrace?

That would have been xbacktrace, right?  Next time...

> And since this is an optimized build, the backtrace is almost useless
> anyway.  Can you try reproducing this in an unoptimized build?

That emacs was compiled with

  CFLAGS="-mtune=native -O1 -pipe -g -ggdb"

and I'll try with -O0 the next time.

>> #7  0x00000000004e157c in xg_display_close (dpy=0x6ca0020) at gtkutil.c:182
>>         gdpy = 0xd682e0
>> #8  0x00000000004afc49 in x_delete_terminal (terminal=<optimized out>)
>>     at xterm.c:10607
>>         dpyinfo = 0x698d3e0
>> #9  0x00000000004a40f2 in Fdelete_terminal (terminal=107998581, 
>>     force=<optimized out>) at terminal.c:345
>>         t = 0x66fed70
>> #10 0x00000000004235cc in delete_frame (frame=99991829, force=<optimized out>)
>>     at frame.c:1379
>>         tmp = <optimized out>
>>         terminal = <optimized out>
>>         f = 0x5f5c110
>>         sf = 0x121b7e0
>>         kb = 0x0
>>         minibuffer_selected = 0
>>         tooltip_frame = 0
>> #11 0x000000000042382a in Fdelete_frame (frame=<optimized out>, 
>>     force=<optimized out>) at frame.c:1516
>
> This part does look as if Emacs was going to close the X display where
> the frame was displayed.  Were all other frames in that session on
> other displays?

No, there was exactly one single frame on the current display, and no
TTY frames.  Then I clicked some link to a txt file in the chromium
browser, which fired up "emacsclient -c file.txt".  So then I had
exactly 2 X11 frames.  Then I clicked the X knob of the frame brought up
by the client, and that made emacs crash.

> If not, how come Emacs is about to delete the terminal?  Here's the
> relevant code:
>
>     if (terminal->reference_count == 0)
>       {
> 	Lisp_Object tmp;
> 	XSETTERMINAL (tmp, terminal);
>
>         kb = NULL;
> 	Fdelete_terminal (tmp, NILP (force) ? Qt : force);
>       }
>
> Can you look at the value of terminal->reference_count?

In an unoptimized build, that should be in the backtrace, right?

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Eli Zaretskii]

> From: Tassilo Horn <tassilo@member.fsf.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Sep 2011 12:42:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It turned out to be a crash, not something calling Fkill_emacs.  Here's
> >> the backtrace:
> >
> > What about the Lisp backtrace?
> 
> That would have been xbacktrace, right?

Yes.  But if you start GDB from the src directory, xbacktrace is
automatically executed as part of backtrace.

> > This part does look as if Emacs was going to close the X display where
> > the frame was displayed.  Were all other frames in that session on
> > other displays?
> 
> No, there was exactly one single frame on the current display, and no
> TTY frames.  Then I clicked some link to a txt file in the chromium
> browser, which fired up "emacsclient -c file.txt".  So then I had
> exactly 2 X11 frames.  Then I clicked the X knob of the frame brought up
> by the client, and that made emacs crash.

I think the crash is not the real problem here.  The real problem here
is that Emacs "thinks" there's only one frame on that display, so it
is about to close the only display it has.  Even if that doesn't
segfault, it will kill the session.

That is, if we can believe the backtrace.

Btw, if it segfaulted in all the previous times, you should be able to
see a message to that effect in your /var/log/messages (assuming this
is GNU/Linux).  If you don't see there any such message, I'd very much
doubt that it segfaulted, but rather would think it indeed exited,
because the only display was closed and its terminal deleted --
exactly what we see in the backtrace you posted.

> > Can you look at the value of terminal->reference_count?
> 
> In an unoptimized build, that should be in the backtrace, right?

You should be able to get to the stack frame where delete_frame calls
Fdelete_terminal (frame #10 in this case, but could be something else
next time), and print the value, yes.

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> I think the crash is not the real problem here.  The real problem here
> is that Emacs "thinks" there's only one frame on that display, so it
> is about to close the only display it has.

I'm happy to announce that now I'm able to reproduce the crash.  It
happens only if an emacs frame is opened for a file by the chromium web
browser.

For example, clicking "Export to BibTeX..." at

  http://www.citeulike.org/bibtex_options/user/azwinkau/article/6095606

will download some *.bib text file, and because emacsclient -c is set as
default command for most text mime types, it will be invoked "somehow".

When I invoke emacsclient from a terminal, or double-click a file in
GNOME3's Nautilus, deleting that frame won't crash emacs.  And neither
does "gvfs-open some-file.txt".  So it seems, chromium is doing
something very special here...

Attached are some backtraces from different crashes, all with
unoptimized builds.  I've produced one for each possibility to delete a
frame (X knob, C-x #, C-x 5 0).

Bye,
Tassilo


[-- Attachment #2: gdb-X-knob.txt --]
[-- Type: text/plain, Size: 12521 bytes --]

Starting program: /usr/bin/emacs-24 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 30461)]
[New Thread 0x7fffe667f700 (LWP 30462)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0  0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1  0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3  0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5  0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7  0x0000000000538909 in xg_display_close (dpy=0x47cf7c0) at gtkutil.c:182
        gdpy = 0xf912e0
#8  0x000000000050a260 in x_delete_terminal (terminal=0x2861c90) at xterm.c:10607
        dpyinfo = 0x13b2000
#9  0x00000000004e88a2 in Fdelete_terminal (terminal=42343573, force=12671490) at terminal.c:345
        t = 0x2861c90
#10 0x00000000004271cb in delete_frame (frame=140736951987109, force=12671490) at frame.c:1379
        tmp = 42343573
        terminal = 0x2861c90
        f = 0x7fffe007aba0
        sf = 0x12f7090
        kb = 0x0
        minibuffer_selected = 0
        tooltip_frame = 0
#11 0x0000000000427519 in Fdelete_frame (frame=140736951987109, force=12671490) at frame.c:1516
No locals.
#12 0x00000000005fe06f in Ffuncall (nargs=3, args=0x7fffffffc1a0) at eval.c:2993
        fun = 9343565
        original_fun = 12713650
        funcar = 0
        numargs = 2
        lisp_numargs = 4
        val = 140737488339344
        backtrace = {
          next = 0x7fffffffc5f0, 
          function = 0x7fffffffc1a0, 
          args = 0x7fffffffc1a8, 
          nargs = 2, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffc1a8
        i = 0
#13 0x0000000000649b21 in exec_byte_code (bytestr=10534465, vector=10534501, maxdepth=20, 
    args_template=12671442, nargs=0, args=0x0) at bytecode.c:785
        count = 5
        op = 2
        vectorp = 0xa0be70
        stack = {
          pc = 0xb2bc46 "\202I", 
          byte_string = 10534465, 
          byte_string_start = 0xb2bc02 "\b\211\030:\203\r", 
          constants = 10534501, 
          next = 0x0
        }
        top = 0x7fffffffc1a0
        result = 0
#14 0x00000000005feab3 in funcall_lambda (fun=10534405, nargs=1, arg_vector=0xa0be65) at eval.c:3221
        val = 6168715
        syms_left = 12671442
        next = 13293682
        lexenv = 12671442
        count = 4
        i = 1
        optional = 0
        rest = 0
#15 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffc6d0) at eval.c:3039
        fun = 10534405
        original_fun = 13053362
        funcar = 140737488340592
        numargs = 1
        lisp_numargs = 6287324
        val = 140737488340592
        backtrace = {
          next = 0x7fffffffc9c0, 
          function = 0x7fffffffc6d0, 
          args = 0x7fffffffc6d8, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0xb7c900
        i = 5642295
#16 0x00000000005f8104 in Fcall_interactively (function=13053362, record_flag=12671442, keys=72506901)
    at callint.c:857
        val = 0
        args = 0x7fffffffc6d0
        visargs = 0x7fffffffc6b0
        specs = 9582913
        filter_specs = 9582913
        teml = 140737258374800
        up_event = 12671442
        enable = 12671442
        speccount = 2
        next_event = 1
        prefix_arg = 12671442
        string = 0x7fffffffc6f0 "e"
        tem = 0x6b2ffc ""
        varies = 0x7fffffffc690 ""
        i = 2
        nargs = 2
        foo = 0
        prompt1 = '\000' <repeats 99 times>
        tem1 = 0x0
        arg_from_tty = 0
        gcpro1 = {
          next = 0x7fffffffcae0, 
          var = 0x56cb4b, 
          nvars = 0
        }
        gcpro2 = {
          next = 0x0, 
          var = 0xc159d2, 
          nvars = -4294967295
        }
        gcpro3 = {
          next = 0x7fffffffcae0, 
          var = 0x65555c, 
          nvars = 2
        }
        gcpro4 = {
          next = 0x0, 
          var = 0xc159d2, 
          nvars = 2
        }
        gcpro5 = {
          next = 0x7fffffffc770, 
          var = 0x5687b7, 
          nvars = 140737488340832
        }
        key_count = 1
        record_then_fail = 0
        save_this_command = 12671442
        save_last_command = 25642514
        save_this_original_command = 12671442
        save_real_this_command = 12671442
#17 0x00000000005fe09e in Ffuncall (nargs=4, args=0x7fffffffca70) at eval.c:2997
        fun = 12101389
        original_fun = 12877234
        funcar = 0
        numargs = 3
        lisp_numargs = 100000000
        val = 0
        backtrace = {
          next = 0x0, 
          function = 0x7fffffffca70, 
          args = 0x7fffffffca78, 
          nargs = 3, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffca78
        i = 0
#18 0x00000000005fd856 in call3 (fn=12877234, arg1=13053362, arg2=12671442, arg3=72506901) at eval.c:2790
        ret_ungc_val = 12671442
        gcpro1 = {
          next = 0x7fffffffcab0, 
          var = 0xa0be05, 
          nvars = 4
        }
        args = {12877234, 13053362, 12671442, 72506901}
#19 0x0000000000573e51 in Fcommand_execute (cmd=13053362, record_flag=12671442, keys=72506901, special=12671490)
    at keyboard.c:10271
        final = 13053362
        tem = 12671442
        prefixarg = 12671442
#20 0x0000000000565342 in read_char (commandflag=1, nmaps=6, maps=0x7fffffffcf30, prev_event=12671442, 
    used_mouse_menu=0x7fffffffd154, end_time=0x0) at keyboard.c:2885
        prev_buffer = 0x4310630
        c = 63237174
        jmpcount = 2
        local_getcjmp = {{
            __jmpbuf = {12671442, 6303929696820967229, 4286624, 140737488346352, 0, 0, 6303929696751761213, 
              -6303928989598435523}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {2532, 140737488342784, 6202213, 0, 12125936, 0, 0, 0, 70321712, 0, 12705522, 
                140737488342528, 6730481, 12671442, 14544838, 12671442}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        key_already_recorded = 0
        tem = 13053362
        save = 12671442
        previous_echo_area_message = 12671442
        also_record = 12671442
        reread = 0
        gcpro1 = {
          next = 0x7fffffffdcf0, 
          var = 0x0, 
          nvars = 12671442
        }
        gcpro2 = {
          next = 0x1ffffcbd0, 
          var = 0x3c37f96, 
          nvars = 12705522
        }
        polling_stopped_here = 0
        orig_kboard = 0x10092a0
#21 0x0000000000571a84 in read_key_sequence (keybuf=0x7fffffffd3c0, bufsize=30, prompt=12671442, 
    dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9280
        interrupted_kboard = 0x10092a0
        interrupted_frame = 0x7fffe007aba0
        key = 70321717
        used_mouse_menu = 0
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        local_first_binding = 0
        from_string = 12671442
        count = 2
        t = 0
        echo_start = 0
        keys_start = 0
        nmaps = 6
        nmaps_allocated = 9
        defs = 0x7fffffffced0
        submaps = 0x7fffffffcf30
        orig_local_map = 39941542
        orig_keymap = 12671442
        localized_local_map = 0
        first_binding = 0
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = 19442342, 
          map = 19442342, 
          start = 0, 
          end = 0
        }
        keytran = {
          parent = 12650918, 
          map = 12650918, 
          start = 0, 
          end = 0
        }
        indec = {
          parent = 19442326, 
          map = 19442326, 
          start = 0, 
          end = 0
        }
        shift_translated = 0
        delayed_switch_frame = 12671442
        original_uppercase = 140737488343920
        original_uppercase_position = -1
        dummyflag = 0
        starting_buffer = 0x4310630
        fake_prefixed_keys = 12671442
        outer_gcpro1 = {
          next = 0x7fffffffd190, 
          var = 0x5e1ada, 
          nvars = 46480416
        }
#22 0x0000000000562385 in command_loop_1 () at keyboard.c:1445
        cmd = 25642514
        keybuf = {460, 76, 1316582004, 12671490, 140737488344192, 6428371, 38373794, 140737488344288, 12671490, 
          46702790, 12698763, 0, 140737488344128, 5229317, 4294956208, 12723634, 140737488344000, 39840065, 1, 
          12671442, 12671442, 43719457, 140737488344192, 12671490, 140737488344256, 5643180, 140737488344288, 
          46702758, 4286624, 19886224}
        i = 1
        prev_modiff = 374
        prev_buffer = 0x2c53c20
        already_adjusted = 0
#23 0x00000000005fac48 in internal_condition_case (bfun=0x561f9e <command_loop_1>, handlers=12723634, 
    hfun=0x56189d <cmd_error>) at eval.c:1491
        val = 0
        c = {
          tag = 12671442, 
          val = 12671442, 
          next = 0x7fffffffd710, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {0, 6303929697089402685, 4286624, 140737488346352, 0, 0, 6303929697087305533, 
                -6303929074269112515}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {12142814999440439101, 0, 4294967295, 5691303, 1, 9335432, 0, 0, 0, 0, 140737351956354, 
                  1, 0, 1, 140737257920136, 0}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 12723634, 
          var = 12671442, 
          chosen_clause = 12671490, 
          tag = 0x7fffffffd590, 
          next = 0x0
        }
#24 0x0000000000561c96 in command_loop_2 (ignore=12671442) at keyboard.c:1156
        val = 0
#25 0x00000000005fa5d4 in internal_catch (tag=12719426, func=0x561c70 <command_loop_2>, arg=12671442)
    at eval.c:1248
        c = {
          tag = 12719426, 
          val = 12671442, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {1, 6303929697175385917, 4286624, 140737488346352, 0, 0, 6303929697097791293, 
                -6303929074484594883}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {6168715, 112, 4301647972, 140737261559512, 12671442, 12125984, 12699488, 14, 1, 
                  140737488345072, 12964096, 140737488345136, 12671442, 4286624, 140737488346352, 
                  140737488345152}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#26 0x0000000000561c49 in command_loop () at keyboard.c:1135
No locals.
#27 0x00000000005613ed in recursive_edit_1 () at keyboard.c:756
        count = 1
        val = 12671442
#28 0x0000000000561588 in Frecursive_edit () at keyboard.c:820
        count = 0
        buffer = 12671442
#29 0x000000000055f749 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1698
        dummy = 140737353921744
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x7ffff7fc3358 "@\344\377\367\377\177"

Lisp Backtrace:
"delete-frame" (0xffffc1a8)
"handle-delete-frame" (0xffffc6d8)
"call-interactively" (0xffffca78)
"delete-frame" (0xffffc1a8)
"handle-delete-frame" (0xffffc6d8)
"call-interactively" (0xffffca78)
A debugging session is active.

	Inferior 1 [process 30456] will be killed.

Quit anyway? (y or n) 

[-- Attachment #3: gdb-C-#.txt --]
[-- Type: text/plain, Size: 13839 bytes --]

Starting program: /usr/bin/emacs-24 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 30603)]
[New Thread 0x7fffe667f700 (LWP 30604)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0  0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1  0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3  0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5  0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7  0x0000000000538909 in xg_display_close (dpy=0x47c9690) at gtkutil.c:182
        gdpy = 0xf912e0
#8  0x000000000050a260 in x_delete_terminal (terminal=0x4b7dae0) at xterm.c:10607
        dpyinfo = 0x480b400
#9  0x00000000004e88a2 in Fdelete_terminal (terminal=79157989, force=12671490) at terminal.c:345
        t = 0x4b7dae0
#10 0x00000000004271cb in delete_frame (frame=44243013, force=12671442) at frame.c:1379
        tmp = 79157989
        terminal = 0x4b7dae0
        f = 0x2a31840
        sf = 0x12f7110
        kb = 0x0
        minibuffer_selected = 0
        tooltip_frame = 0
#11 0x0000000000427519 in Fdelete_frame (frame=44243013, force=12671442) at frame.c:1516
No locals.
#12 0x00000000005fe06f in Ffuncall (nargs=2, args=0x7fffffffbb48) at eval.c:2993
        fun = 9343565
        original_fun = 12713650
        funcar = 12671442
        numargs = 1
        lisp_numargs = 70368677
        val = 12671442
        backtrace = {
          next = 0x7fffffffbfb0, 
          function = 0x7fffffffbb48, 
          args = 0x7fffffffbb50, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffba60
        i = 2
#13 0x0000000000649b21 in exec_byte_code (bytestr=30136353, vector=30613061, maxdepth=56, args_template=2052, 
    nargs=1, args=0x7fffffffc088) at bytecode.c:785
        count = 5
        op = 1
        vectorp = 0x1d31e50
        stack = {
          pc = 0x1bcd055 "\210\001A\266\202\202o", 
          byte_string = 30136353, 
          byte_string_start = 0x1bccfc8 "\304\305\002\205\a", 
          constants = 30613061, 
          next = 0x7fffffffc0e0
        }
        top = 0x7fffffffbb48
        result = 12671442
#14 0x00000000005fe787 in funcall_lambda (fun=29742661, nargs=1, arg_vector=0x7fffffffc080) at eval.c:3155
        val = 52943670
        syms_left = 2052
        next = 12862258
        lexenv = 12671442
        count = 5
        i = 3
        optional = 0
        rest = 0
#15 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffc078) at eval.c:3039
        fun = 29742661
        original_fun = 31058706
        funcar = 12909218
        numargs = 1
        lisp_numargs = 12671394
        val = 12671442
        backtrace = {
          next = 0x7fffffffc4c0, 
          function = 0x7fffffffc078, 
          args = 0x7fffffffc080, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffc558
        i = 53123014
#16 0x0000000000649b21 in exec_byte_code (bytestr=28579745, vector=29925013, maxdepth=48, args_template=2052, 
    nargs=1, args=0x7fffffffc560) at bytecode.c:785
        count = 5
        op = 1
        vectorp = 0x1c89ea0
        stack = {
          pc = 0x1d3b2f4 "\210\210\001A\266\202\202\003", 
          byte_string = 28579745, 
          byte_string_start = 0x1d3b290 "ʼn\b\211\203m", 
          constants = 29925013, 
          next = 0x7fffffffc5b0
        }
        top = 0x7fffffffc078
        result = 12671442
#17 0x00000000005fe787 in funcall_lambda (fun=29925413, nargs=1, arg_vector=0x7fffffffc558) at eval.c:3155
        val = 6283336
        syms_left = 2052
        next = 180388626432
        lexenv = 140737488340112
        count = 5
        i = 0
        optional = 0
        rest = 0
#18 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffc550) at eval.c:3039
        fun = 29925413
        original_fun = 29710274
        funcar = 54089590
        numargs = 1
        lisp_numargs = 30383554
        val = 12671442
        backtrace = {
          next = 0x7fffffffc990, 
          function = 0x7fffffffc550, 
          args = 0x7fffffffc558, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffca40
        i = 1
#19 0x0000000000649b21 in exec_byte_code (bytestr=28574065, vector=29925957, maxdepth=16, args_template=0, 
    nargs=0, args=0x7fffffffca40) at bytecode.c:785
        count = 5
        op = 1
        vectorp = 0x1c8a250
        stack = {
          pc = 0x1d3b3f4 "\207", 
          byte_string = 28574065, 
          byte_string_start = 0x1d3b3c8 "\b\205,", 
          constants = 29925957, 
          next = 0x7fffffffca80
        }
        top = 0x7fffffffc550
        result = 12671442
#20 0x00000000005fe787 in funcall_lambda (fun=29926277, nargs=0, arg_vector=0x7fffffffca40) at eval.c:3155
        val = 6607736
        syms_left = 0
        next = 75015221
        lexenv = 12671442
        count = 5
        i = 140737488341552
        optional = -1
        rest = -1
#21 0x00000000005fe25a in Ffuncall (nargs=1, args=0x7fffffffca38) at eval.c:3039
        fun = 29926277
        original_fun = 29710322
        funcar = 44243008
        numargs = 0
        lisp_numargs = 44243013
        val = 12906178
        backtrace = {
          next = 0x7fffffffce60, 
          function = 0x7fffffffca38, 
          args = 0x7fffffffca40, 
          nargs = 0, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffcf48
        i = 12671442
#22 0x0000000000649b21 in exec_byte_code (bytestr=28557265, vector=29927637, maxdepth=16, args_template=1024, 
    nargs=1, args=0x7fffffffcf50) at bytecode.c:785
        count = 5
        op = 0
        vectorp = 0x1c8a8e0
        stack = {
          pc = 0x1d3b564 "\"\207\311\312!\207", 
          byte_string = 28557265, 
          byte_string_start = 0x1d3b548 "\211\204\020", 
          constants = 29927637, 
          next = 0x0
        }
        top = 0x7fffffffca38
        result = 42799397
#23 0x00000000005fe787 in funcall_lambda (fun=29927957, nargs=1, arg_vector=0x7fffffffcf48) at eval.c:3155
        val = 6168715
        syms_left = 1024
        next = 12671394
        lexenv = 12671442
        count = 5
        i = 8589921872
        optional = 0
        rest = 5705370
#24 0x00000000005fe25a in Ffuncall (nargs=2, args=0x7fffffffcf40) at eval.c:3039
        fun = 29927957
        original_fun = 29710370
        funcar = 140737488342752
        numargs = 1
        lisp_numargs = 6287324
        val = 140737488342752
        backtrace = {
          next = 0x7fffffffd230, 
          function = 0x7fffffffcf40, 
          args = 0x7fffffffcf48, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x1d3b5a0
        i = 5642295
#25 0x00000000005f8104 in Fcall_interactively (function=29710370, record_flag=12671442, keys=12717765)
    at callint.c:857
        val = 0
        args = 0x7fffffffcf40
        visargs = 0x7fffffffcf20
        specs = 28556033
        filter_specs = 28556033
        teml = 0
        up_event = 12671442
        enable = 12671442
        speccount = 3
        next_event = 2
        prefix_arg = 12671442
        string = 0x7fffffffcf60 "P"
        tem = 0x6b2ffc ""
        varies = 0x7fffffffcf00 ""
        i = 2
        nargs = 2
        foo = 0
        prompt1 = '\000' <repeats 99 times>
        tem1 = 0x0
        arg_from_tty = 0
        gcpro1 = {
          next = 0x7fffffffd090, 
          var = 0x7ffff24cc5da, 
          nvars = 140737488343120
        }
        gcpro2 = {
          next = 0x7fffffffd020, 
          var = 0x7ffff7ffb8ad, 
          nvars = 140737488343760
        }
        gcpro3 = {
          next = 0xc159d2, 
          var = 0x7ffff7ffb639, 
          nvars = 2
        }
        gcpro4 = {
          next = 0x1c55822, 
          var = 0x12773c2, 
          nvars = 2
        }
        gcpro5 = {
          next = 0x7fffffffd020, 
          var = 0x5feac8, 
          nvars = 0
        }
        key_count = 2
        record_then_fail = 0
        save_this_command = 29710370
        save_last_command = 36428754
        save_this_original_command = 29710370
        save_real_this_command = 29710370
#26 0x00000000005fe09e in Ffuncall (nargs=4, args=0x7fffffffd2e0) at eval.c:2997
        fun = 12101389
        original_fun = 12877234
        funcar = 0
        numargs = 3
        lisp_numargs = 0
        val = 0
        backtrace = {
          next = 0x0, 
          function = 0x7fffffffd2e0, 
          args = 0x7fffffffd2e8, 
          nargs = 3, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffd2e8
        i = 0
#27 0x00000000005fd856 in call3 (fn=12877234, arg1=29710370, arg2=12671442, arg3=12671442) at eval.c:2790
        ret_ungc_val = 12671442
        gcpro1 = {
          next = 0x7fffffffd320, 
          var = 0x1c8aa15, 
          nvars = 4
        }
        args = {12877234, 29710370, 12671442, 12671442}
#28 0x0000000000573e51 in Fcommand_execute (cmd=29710370, record_flag=12671442, keys=12671442, special=12671442)
    at keyboard.c:10271
        final = 29710370
        tem = 12671442
        prefixarg = 12671442
#29 0x0000000000562844 in command_loop_1 () at keyboard.c:1572
        scount = 2
        cmd = 29710370
        keybuf = {96, 140, 4286624, 140737488346352, 140737488344080, 6167415, 140737488344160, 12671442, 
          276967387, 1, 140737488344160, 6169746, 12671442, 12859474, 140737488344240, 6168715, 12507328, 
          8589923456, 0, 12859472, 140737488344320, 6287904, 12981974, 8589934593, 12859474, 12671442, 0, 0, 
          4286624, 140737488346352}
        i = 2
        prev_modiff = 27
        prev_buffer = 0x478a430
        already_adjusted = 0
#30 0x00000000005fac48 in internal_condition_case (bfun=0x561f9e <command_loop_1>, handlers=12723634, 
    hfun=0x56189d <cmd_error>) at eval.c:1491
        val = 0
        c = {
          tag = 12671442, 
          val = 12671442, 
          next = 0x7fffffffd710, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {1, -5948150678907524226, 4286624, 140737488346352, 0, 0, -5948150678813152386, 
                5948150339555683198}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {5948150339555683198, 0, 4294967295, 5691303, 1, 9335432, 0, 0, 0, 0, 140737351956354, 
                  1, 0, 1, 140737257920136, 0}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 12723634, 
          var = 12671442, 
          chosen_clause = 12723634, 
          tag = 0x7fffffffd590, 
          next = 0x0
        }
#31 0x0000000000561c96 in command_loop_2 (ignore=12671442) at keyboard.c:1156
        val = 1
#32 0x00000000005fa5d4 in internal_catch (tag=12719426, func=0x561c70 <command_loop_2>, arg=12671442)
    at eval.c:1248
        c = {
          tag = 12719426, 
          val = 12671442, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {1, -5948150678456636546, 4286624, 140737488346352, 0, 0, -5948150678899135618, 
                5948150339209128830}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {6168715, 112, 4301647972, 140737261559512, 12671442, 12125984, 12699488, 14, 1, 
                  140737488345072, 12964096, 140737488345136, 12671442, 4286624, 140737488346352, 
                  140737488345152}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#33 0x0000000000561c49 in command_loop () at keyboard.c:1135
No locals.
#34 0x00000000005613ed in recursive_edit_1 () at keyboard.c:756
        count = 1
        val = 12671442
#35 0x0000000000561588 in Frecursive_edit () at keyboard.c:820
        count = 0
        buffer = 12671442
#36 0x000000000055f749 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1698
        dummy = 140737353921744
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x7ffff7fc3358 "@\344\377\367\377\177"

Lisp Backtrace:
"delete-frame" (0xffffbb50)
"server-delete-client" (0xffffc080)
"server-buffer-done" (0xffffc558)
"server-done" (0xffffca40)
"server-edit" (0xffffcf48)
"call-interactively" (0xffffd2e8)
A debugging session is active.

	Inferior 1 [process 30598] will be killed.

Quit anyway? (y or n) 

[-- Attachment #4: gdb-C-x-5-0.txt --]
[-- Type: text/plain, Size: 8459 bytes --]

Starting program: /usr/bin/emacs-24 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6e80700 (LWP 30710)]
[New Thread 0x7fffe667f700 (LWP 30711)]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
#0  0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
No symbol table info available.
#1  0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#3  0x00007ffff7599f0e in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#4  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5  0x00007ffff758c5d6 in ?? () from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#6  0x00007ffff65c1274 in g_object_unref () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7  0x0000000000538909 in xg_display_close (dpy=0x2a339b0) at gtkutil.c:182
        gdpy = 0xf912e0
#8  0x000000000050a260 in x_delete_terminal (terminal=0x2a45400) at xterm.c:10607
        dpyinfo = 0x2a47400
#9  0x00000000004e88a2 in Fdelete_terminal (terminal=44323845, force=12671490) at terminal.c:345
        t = 0x2a45400
#10 0x00000000004271cb in delete_frame (frame=44346293, force=12671442) at frame.c:1379
        tmp = 44323845
        terminal = 0x2a45400
        f = 0x2a4abb0
        sf = 0x1311e90
        kb = 0x0
        minibuffer_selected = 0
        tooltip_frame = 0
#11 0x0000000000427519 in Fdelete_frame (frame=12671442, force=12671442) at frame.c:1516
No locals.
#12 0x00000000005fe06f in Ffuncall (nargs=1, args=0x7fffffffcf50) at eval.c:2993
        fun = 9343565
        original_fun = 12713650
        funcar = 140737488342784
        numargs = 0
        lisp_numargs = 6287324
        val = 9379585
        backtrace = {
          next = 0x7fffffffd230, 
          function = 0x7fffffffcf50, 
          args = 0x7fffffffcf58, 
          nargs = 0, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffce50
        i = 2
#13 0x00000000005f8104 in Fcall_interactively (function=12713650, record_flag=12671442, keys=12717765)
    at callint.c:857
        val = 0
        args = 0x7fffffffcf50
        visargs = 0x7fffffffcf30
        specs = 9379585
        filter_specs = 9379585
        teml = 0
        up_event = 12671442
        enable = 12671442
        speccount = 3
        next_event = 3
        prefix_arg = 12671442
        string = 0x7fffffffcf70 ""
        tem = 0x7fffffffcf70 ""
        varies = 0x7fffffffcf20 ""
        i = 1
        nargs = 1
        foo = 0
        prompt1 = '\000' <repeats 24 times>, "<B\017", '\000' <repeats 13 times>, "<B\017\000\000\000\000\000\301d_N\000\000\000\000\372\323\n\000\000\000\000\000\320\322\377\377\377\177\000\000\320\322\377\377\377\177\000\000p\323\377\377\377\177\000\000\276\063f\000\000\000\000\000\000 \000"
        tem1 = 0x0
        arg_from_tty = 0
        gcpro1 = {
          next = 0x7fffffffd090, 
          var = 0x7ffff24cc5da, 
          nvars = 140737488343120
        }
        gcpro2 = {
          next = 0x7fffffffd020, 
          var = 0x7ffff7ffb8ad, 
          nvars = 140737488343760
        }
        gcpro3 = {
          next = 0xc159d2, 
          var = 0x7ffff7ffb639, 
          nvars = 1
        }
        gcpro4 = {
          next = 0xc1feb2, 
          var = 0x12773c2, 
          nvars = 1
        }
        gcpro5 = {
          next = 0x7fffffffd020, 
          var = 0x5feac8, 
          nvars = 0
        }
        key_count = 3
        record_then_fail = 0
        save_this_command = 12713650
        save_last_command = 19208866
        save_this_original_command = 12713650
        save_real_this_command = 12713650
#14 0x00000000005fe09e in Ffuncall (nargs=4, args=0x7fffffffd2e0) at eval.c:2997
        fun = 12101389
        original_fun = 12877234
        funcar = 0
        numargs = 3
        lisp_numargs = 0
        val = 0
        backtrace = {
          next = 0x0, 
          function = 0x7fffffffd2e0, 
          args = 0x7fffffffd2e8, 
          nargs = 3, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffd2e8
        i = 0
#15 0x00000000005fd856 in call3 (fn=12877234, arg1=12713650, arg2=12671442, arg3=12671442) at eval.c:2790
        ret_ungc_val = 12671442
        gcpro1 = {
          next = 0x7fffffffd320, 
          var = 0x8e924d, 
          nvars = 4
        }
        args = {12877234, 12713650, 12671442, 12671442}
#16 0x0000000000573e51 in Fcommand_execute (cmd=12713650, record_flag=12671442, keys=12671442, special=12671442)
    at keyboard.c:10271
        final = 12713650
        tem = 12671442
        prefixarg = 12671442
#17 0x0000000000562844 in command_loop_1 () at keyboard.c:1572
        scount = 2
        cmd = 12713650
        keybuf = {96, 212, 192, 140737488346352, 140737488344080, 6167415, 140737488344160, 12671442, 276967387, 
          1, 140737488344160, 6169746, 12671442, 12859474, 140737488344240, 6168715, 12507328, 8589923456, 0, 
          12859472, 140737488344320, 6287904, 12981974, 8589934593, 12859474, 12671442, 0, 0, 4286624, 
          140737488346352}
        i = 3
        prev_modiff = 27
        prev_buffer = 0x2ebf030
        already_adjusted = 0
#18 0x00000000005fac48 in internal_condition_case (bfun=0x561f9e <command_loop_1>, handlers=12723634, 
    hfun=0x56189d <cmd_error>) at eval.c:1491
        val = 0
        c = {
          tag = 12671442, 
          val = 12671442, 
          next = 0x7fffffffd710, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {1, 5498248946679664099, 4286624, 140737488346352, 0, 0, 5498248946761453027, 
                -5498249689761067549}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {12948494383948484067, 0, 4294967295, 5691303, 1, 9335432, 0, 0, 0, 0, 140737351956354, 
                  1, 0, 1, 140737257920136, 0}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 12723634, 
          var = 12671442, 
          chosen_clause = 12723634, 
          tag = 0x7fffffffd590, 
          next = 0x0
        }
#19 0x0000000000561c96 in command_loop_2 (ignore=12671442) at keyboard.c:1156
        val = 1
#20 0x00000000005fa5d4 in internal_catch (tag=12719426, func=0x561c70 <command_loop_2>, arg=12671442)
    at eval.c:1248
        c = {
          tag = 12719426, 
          val = 12671442, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {1, 5498248946329439715, 4286624, 140737488346352, 0, 0, 5498248946671275491, 
                -5498249689287635485}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {6168715, 112, 4301647972, 140737261559512, 12671442, 12125984, 12699488, 14, 1, 
                  140737488345072, 12964096, 140737488345136, 12671442, 4286624, 140737488346352, 
                  140737488345152}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#21 0x0000000000561c49 in command_loop () at keyboard.c:1135
No locals.
#22 0x00000000005613ed in recursive_edit_1 () at keyboard.c:756
        count = 1
        val = 12671442
#23 0x0000000000561588 in Frecursive_edit () at keyboard.c:820
        count = 0
        buffer = 12671442
#24 0x000000000055f749 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1698
        dummy = 140737353921744
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
        ch_to_dir = 0x7ffff7fc3358 "@\344\377\367\377\177"

Lisp Backtrace:
"delete-frame" (0xffffcf58)
"call-interactively" (0xffffd2e8)
A debugging session is active.

	Inferior 1 [process 30705] will be killed.

Quit anyway? (y or n) 

Re: Killing a frame sometimes kills emacs

[Andreas Schwab]

Tassilo Horn <tassilo@member.fsf.org> writes:

> It turned out to be a crash, not something calling Fkill_emacs.  Here's
> the backtrace:
>
> Breakpoint 1 at 0x4f23dd: file emacs.c, line 1985.
> Starting program: /usr/bin/emacs-24 
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7fffe6e80700 (LWP 31725)]
> [New Thread 0x7fffe667f700 (LWP 31726)]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
> #0  0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
> No symbol table info available.
> #1  0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0

Isn't that the known gtk bug with multiple displays?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Tassilo Horn <tassilo@member.fsf.org> writes:
>
>> It turned out to be a crash, not something calling Fkill_emacs.  Here's
>> the backtrace:
>>
>> Breakpoint 1 at 0x4f23dd: file emacs.c, line 1985.
>> Starting program: /usr/bin/emacs-24 
>> [Thread debugging using libthread_db enabled]
>> [New Thread 0x7fffe6e80700 (LWP 31725)]
>> [New Thread 0x7fffe667f700 (LWP 31726)]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
>> #0  0x00007ffff4dd1ecc in XFreeColormap () from /usr/lib64/libX11.so.6
>> No symbol table info available.
>> #1  0x00007ffff759c93a in ?? () from /usr/lib64/libgdk-3.so.0
>
> Isn't that the known gtk bug with multiple displays?

As said in the reply to Eli, I don't have multiple displays.  There's
only one X instance in which emacs runs with exactly one X11 frame.
Then I invoked "emacsclient -c" to get another X11 frame, and closing
that made emacs crash.

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Jan D.]

Tassilo Horn skrev 2011-09-01 12:45:
> Andreas Schwab<schwab@linux-m68k.org>  writes:
>
>> Isn't that the known gtk bug with multiple displays?
>
> As said in the reply to Eli, I don't have multiple displays.  There's
> only one X instance in which emacs runs with exactly one X11 frame.
> Then I invoked "emacsclient -c" to get another X11 frame, and closing
> that made emacs crash.

 From Emacs point of view, localhost:0 and unix:0 and :0 are three 
different displays, even if they physically are the same.

Try doing the same and after you clicked the link in chromium, evaluate 
(x-display-list).  If you have more than one entry, it is the Gtk+ problem.

	Jan D.

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

"Jan D." <jan.h.d@swipnet.se> writes:

>>> Isn't that the known gtk bug with multiple displays?
>>
>> As said in the reply to Eli, I don't have multiple displays.  There's
>> only one X instance in which emacs runs with exactly one X11 frame.
>> Then I invoked "emacsclient -c" to get another X11 frame, and closing
>> that made emacs crash.
>
> From Emacs point of view, localhost:0 and unix:0 and :0 are three
> different displays, even if they physically are the same.
>
> Try doing the same and after you clicked the link in chromium, evaluate
> (x-display-list).  If you have more than one entry, it is the Gtk+ problem.

Indeed, after opening a new emacs frame from chromium, I have two
entries: (":0.0" ":0").  Before that, it was only (":0.0").

But still, since all other apps somehow spawning new emacs frames don't
create this problem, I wonder if chromium does something special.  I've
checked its sources, and eventually it'll call something like

  XDGUtil("xdg-open", "path/to/file.txt");

You can check that function here:

  http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/chrome/browser/platform_util_linux.cc&l=17

That in turn calls LaunchProcess()

  http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/base/process_util_posix.cc&l=531

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Eli Zaretskii]

> Date: Thu, 01 Sep 2011 14:47:09 +0200
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>, 
>  emacs-devel@gnu.org
> 
>  From Emacs point of view, localhost:0 and unix:0 and :0 are three 
> different displays, even if they physically are the same.

Can't we do something in Emacs so it understood that they are on the
same display?  That won't fix the GTK problem, but at least it will
work around it in this particular use case.  And I think it's a Good
Thing in general, no?

Re: Killing a frame sometimes kills emacs

[Ken Raeburn]

On Sep 1, 2011, at 11:29, Eli Zaretskii wrote:

>> Date: Thu, 01 Sep 2011 14:47:09 +0200
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>, 
>> emacs-devel@gnu.org
>> 
>> From Emacs point of view, localhost:0 and unix:0 and :0 are three 
>> different displays, even if they physically are the same.
> 
> Can't we do something in Emacs so it understood that they are on the
> same display?  That won't fix the GTK problem, but at least it will
> work around it in this particular use case.  And I think it's a Good
> Thing in general, no?
> 

If that's the intent of the X code... I've actually seen cases where the hostname "unix" gets looked up, so maybe the rule is "unix means the local host if you don't have a machine named unix".  I'm not sure if that was X11 software or something else trying to interpret $DISPLAY, though; I was looking at DNS packet traces.

In this case, ":0.0" vs ":0" is even more straightforward.  According to the X man page I just looked up, at least, the default screen number is zero if omitted (not some changeable per-display default screen number), so counting those two as the same should be easy.

Ken

Re: Killing a frame sometimes kills emacs

[Andreas Schwab]

Ken Raeburn <raeburn@raeburn.org> writes:

> If that's the intent of the X code... I've actually seen cases where the
> hostname "unix" gets looked up, so maybe the rule is "unix means the local
> host if you don't have a machine named unix".

At least libxcb (the X transport layer) recognizes unix:N specially.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 01 Sep 2011 14:47:09 +0200
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: Andreas Schwab <schwab@linux-m68k.org>, Eli Zaretskii <eliz@gnu.org>, 
>>  emacs-devel@gnu.org
>> 
>>  From Emacs point of view, localhost:0 and unix:0 and :0 are three 
>> different displays, even if they physically are the same.
>
> Can't we do something in Emacs so it understood that they are on the
> same display?  That won't fix the GTK problem, but at least it will
> work around it in this particular use case.  And I think it's a Good
> Thing in general, no?

Any news on that front?  I'm still accidentally killing emacs at least
twice a day.  And I'm already trying hard not to fire up an emacsclient
X11 frame form external GTK apps, which is really really annoying.  For
example, when I click on a textfile link in a browser, I have to be sure
to save it and then open it from inside emacs, instead of simply letting
the browser invoke emacsclient after which I would have a frame that
would kill emacs when being deleted...

With resepect to the Emacs 24 release, it's very likely that a lot of
users will suffer from this issue, so although it's a gtk bug, there
should be some workaround (probably enabled by default).

For me and I guess for most users, localhost:0, unix:0 (*), :0.0, and :0
are all the same in practice, only localhost:1 or :2 actually mean other
displays.  So I'd simply strip localhost and unix before the colon and
dot-zeros.  (Maybe there should be an option for that, or some lisp
function that would be called to transform the display name if it is
defined...)

Bye,
Tassilo

(*) I'm not too sure with unix:0.  I know such an entry only from
    xorg.conf to tell the xserver where the font server is running.

Re: Killing a frame sometimes kills emacs

[Stefan Monnier]

> With resepect to the Emacs 24 release, it's very likely that a lot of
> users will suffer from this issue, so although it's a gtk bug, there
> should be some workaround (probably enabled by default).

I can't imagine why "a lot of users" would run Emacs with different (but
equivalent) values of $DISPLAY.


        Stefan

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>> With resepect to the Emacs 24 release, it's very likely that a lot of
>> users will suffer from this issue, so although it's a gtk bug, there
>> should be some workaround (probably enabled by default).
>
> I can't imagine why "a lot of users" would run Emacs with different
> (but equivalent) values of $DISPLAY.

They don't do that intentionally, it's a bug in GTK:

  https://bugzilla.gnome.org/show_bug.cgi?id=85715#c55

[Ulrich, I added you to Cc because you commented on the report above, so
you probably know a bit better about what's going wrong there.]

The problem in my usecase is that when I fire up emacs or emacsclient -c
from the GNOME3 application menu or the run command dialog, it says it
is on DISPLAY :0, i.e., (x-display-list) returns (":0").

In contrast, when I start emacs or emacsclient -c from a GNOME terminal
or the file manager or web browser fire up an emacsclient -c, because
I've set that up as default application for text files, the DISPLAY is
:0.0.

So as soon as I mix these two invocation styles, (x-display-list)
returns (":0" ":0.0").  Those displays are different, and when I delete
the last frame on one of the (equivalent) displays, emacs (including the
original frames on the other displays) are killed.

Not sure who kills emacs.  Reading the bug report above, it seems that
GTK deletes the display, and then emacs crashes because its display is
gone.

Maybe a workaround could be to initially tell GTK that emacs runs on
both :0 and :0.0, so that GTK never thinks the last frame is going to be
deleted.

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[James Cloos]

>>>>> "TH" == Tassilo Horn <tassilo@member.fsf.org> writes:

TH> So as soon as I mix these two invocation styles, (x-display-list)
TH> returns (":0" ":0.0").  Those displays are different, and when I
TH> delete the last frame on one of the (equivalent) displays, emacs
TH> (including the original frames on the other displays) are killed.

It seems, then, that emacs needs to canonicalize the DISPLAY strings
before comparing them.

I thought that I remembered some some code in libX11 and/or xtrans
which does that, but a quick grep(1) did not illuminate any.

(Apologies for the pun.  Err, was that another one?)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

James Cloos <cloos@jhcloos.com> writes:

> TH> So as soon as I mix these two invocation styles, (x-display-list)
> TH> returns (":0" ":0.0").  Those displays are different, and when I
> TH> delete the last frame on one of the (equivalent) displays, emacs
> TH> (including the original frames on the other displays) are killed.
>
> It seems, then, that emacs needs to canonicalize the DISPLAY strings
> before comparing them.

It's not that emacs kills itself.  It segfaults probably because gtk
deletes/frees the display while emacs is still using it.  (Well, or
something like that...)

Oh, checking the backtrace I've posted at the beginning of this thread,
I've found this code in gtkutil.c:

--8<---------------cut here---------------start------------->8---
#if GTK_MAJOR_VERSION == 2 && GTK_MINOR_VERSION < 10
  /* GTK 2.2-2.8 has a bug that makes gdk_display_close crash (bug
     http://bugzilla.gnome.org/show_bug.cgi?id=85715).  This way we
     can continue running, but there will be memory leaks.  */
  g_object_run_dispose (G_OBJECT (gdpy));
#else
  /* This seems to be fixed in GTK 2.10. */
  gdk_display_close (gdpy);
#endif
}
--8<---------------cut here---------------end--------------->8---

That's already the right workaround, isn't it?  The only thing is that
this bug is *not* fixed in GTK 2.10 but instead still exists (or exists
again) in GTK 3.2.0.

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Oh, checking the backtrace I've posted at the beginning of this thread,
> I've found this code in gtkutil.c:
>
> #if GTK_MAJOR_VERSION == 2 && GTK_MINOR_VERSION < 10
>   /* GTK 2.2-2.8 has a bug that makes gdk_display_close crash (bug
>      http://bugzilla.gnome.org/show_bug.cgi?id=85715).  This way we
>      can continue running, but there will be memory leaks.  */
>   g_object_run_dispose (G_OBJECT (gdpy));
> #else
>   /* This seems to be fixed in GTK 2.10. */
>   gdk_display_close (gdpy);
> #endif
> }
>
> That's already the right workaround, isn't it?  The only thing is that
> this bug is *not* fixed in GTK 2.10 but instead still exists (or
> exists again) in GTK 3.2.0.

I've just commented the line in the #else and recompiled emacs and
reproduced the issue, i.e., started emacs using the application menu
(resulting in a frame on display :0) and then opened another frame using
emacsclient -c in a gnome terminal, so that in the end (x-display-list)
returned (":0" ":0.0").

Then I deleted the frame created by emacsclient -c using C-x 5 0.  The
result is that the frame is still there but not functional.  I can't
even see the mouse pointer when hovering over it.  From my perspective,
that's an improvement. :-)

(x-display-list) returns (":0") again.

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Chong Yidong]

James Cloos <cloos@jhcloos.com> writes:

> It seems, then, that emacs needs to canonicalize the DISPLAY strings
> before comparing them.
>
> I thought that I remembered some some code in libX11 and/or xtrans
> which does that, but a quick grep(1) did not illuminate any.

I'm not sure that can be made to work reliably.

Perhaps what we should do, instead, is to avoid deleting terminals in
delete_frame if Emacs is compiled with GTK.  The original intention was
for Emacs to close remote X connections when we're done with them.  But
if GTK responds to an X connection closing by crashing, maybe we should
just not close those X connections at all.

Tassilo, could you experiment with commenting out the terminal deletion
code in frame.c:1362, and see what the behavior is like?

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Chong Yidong <cyd@stupidchicken.com> writes:

> James Cloos <cloos@jhcloos.com> writes:
>
>> It seems, then, that emacs needs to canonicalize the DISPLAY strings
>> before comparing them.
>>
>> I thought that I remembered some some code in libX11 and/or xtrans
>> which does that, but a quick grep(1) did not illuminate any.
>
> I'm not sure that can be made to work reliably.
>
> Perhaps what we should do, instead, is to avoid deleting terminals in
> delete_frame if Emacs is compiled with GTK.  The original intention was
> for Emacs to close remote X connections when we're done with them.  But
> if GTK responds to an X connection closing by crashing, maybe we should
> just not close those X connections at all.
>
> Tassilo, could you experiment with commenting out the terminal deletion
> code in frame.c:1362, and see what the behavior is like?

I commente 3 lines as indicated below:

--8<---------------cut here---------------start------------->8---
    /* If needed, delete the terminal that this frame was on.
       (This must be done after the frame is killed.) */
    terminal->reference_count--;
    if (terminal->reference_count == 0)
      {
	// Lisp_Object tmp;
	// XSETTERMINAL (tmp, terminal);

        kb = NULL;
	// Fdelete_terminal (tmp, NILP (force) ? Qt : force);
      }
    else
      kb = terminal->kboard;
--8<---------------cut here---------------end--------------->8---

I'm not sure if keeping the "kb = NULL;" was correct, though.  If you
want, I can try again with the complete then block commented.

Ok, at first, it seemed to work fine.  I could create and delete frames
without crashing emacs, although (x-display-list) returned (":0"
":0.0").  However, after the n-th cycle in my create/delete random
frames test, emacs eventually crashed.  This is the backtrace:

--8<---------------cut here---------------start------------->8---
% gdb /usr/bin/emacs-24 
GNU gdb (Gentoo 7.3.1 p1) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /usr/bin/emacs-24...done.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = :0.0
TERM = xterm-256color
Breakpoint 1 at 0x55eebb: file emacs.c, line 386.
Temporary breakpoint 2 at 0x5831a4: file sysdep.c, line 858.
(gdb) run
Starting program: /usr/bin/emacs-24 
[Thread debugging using libthread_db enabled]
[New Thread 0x7fffe6b98700 (LWP 1695)]
[New Thread 0x7fffe6396700 (LWP 1696)]

(emacs-24:1692): Gtk-CRITICAL **: gtk_style_context_get: assertion `priv->widget_path != NULL' failed

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6ce6fa5 in cairo_pattern_reference () from /usr/lib64/libcairo.so.2
(gdb) bt full
#0  0x00007ffff6ce6fa5 in cairo_pattern_reference ()
   from /usr/lib64/libcairo.so.2
No symbol table info available.
#1  0x00007ffff75364bb in gdk_window_set_background_pattern ()
   from /usr/lib64/libgdk-3.so.0
No symbol table info available.
#2  0x00007ffff795f600 in gtk_style_context_set_background ()
   from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#3  0x00007ffff7a1fb4d in ?? () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#4  0x00007ffff65656a5 in g_closure_invoke ()
   from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#5  0x00007ffff65775b2 in ?? () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#6  0x00007ffff65810b4 in g_signal_emit_valist ()
   from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#7  0x00007ffff6581243 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#8  0x00007ffff7a1aaa2 in ?? () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#9  0x00007ffff65656a5 in g_closure_invoke ()
   from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#10 0x00007ffff6577dc1 in ?? () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#11 0x00007ffff65810b4 in g_signal_emit_valist ()
   from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#12 0x00007ffff6581243 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#13 0x00007ffff795f081 in gtk_style_context_invalidate ()
   from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#14 0x00007ffff7a1f1e7 in gtk_widget_get_style_context ()
   from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#15 0x00007ffff789b497 in ?? () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#16 0x00007ffff65656a5 in g_closure_invoke ()
   from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#17 0x00007ffff65775b2 in ?? () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#18 0x00007ffff65810b4 in g_signal_emit_valist ()
   from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#19 0x00007ffff6581243 in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0
No symbol table info available.
#20 0x00007ffff7a1cd18 in gtk_widget_realize () from /usr/lib64/libgtk-3.so.0
No symbol table info available.
#21 0x000000000053beac in xg_create_frame_widgets (f=0x27852d0)
    at gtkutil.c:1186
        wtop = 0x15fd730
        wvbox = 0x12d70c0
        whbox = 0x1615a70
        wfixed = 0x12d7df0
        title = 0x12e4200 "emacs-24@thinkpad.tsdh.de"
#22 0x0000000000510454 in x_window (f=0x27852d0) at xfns.c:2612
No locals.
#23 0x0000000000512259 in Fx_create_frame (parms=40860694) at xfns.c:3359
        f = 0x27852d0
        frame = 41439957
        tem = 12741026
        name = 12741026
        minibuffer_only = 0
        window_prompting = 0
---Type <return> to continue, or q <return> to quit---
        width = 0
        height = 12741074
        count = 20
        gcpro1 = {
          next = 0xc269d2, 
          var = 0x5daca4, 
          nvars = 140737488323976
        }
        gcpro2 = {
          next = 0x29b2ff6, 
          var = 0x4b, 
          nvars = 40862230
        }
        gcpro3 = {
          next = 0x0, 
          var = 0x0, 
          nvars = 12
        }
        gcpro4 = {
          next = 0x26f8216, 
          var = 0x16012e3993, 
          nvars = 12866354
        }
---Type <return> to continue, or q <return> to quit---
        display = 40495777
        dpyinfo = 0x10a9940
        parent = 12741074
        kb = 0x1091c00
#24 0x00000000005ffa39 in Ffuncall (nargs=2, args=0x7fffffff8a60)
    at eval.c:2974
        fun = 9368773
        original_fun = 13048258
        funcar = 12741074
        numargs = 1
        lisp_numargs = 40840886
        val = 40862230
        backtrace = {
          next = 0x7fffffff8ea0, 
          function = 0x7fffffff8a60, 
          args = 0x7fffffff8a68, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffff8a68
        i = 13375296
#25 0x000000000064b475 in exec_byte_code (bytestr=9908065, vector=9908101, 
    maxdepth=16, args_template=12741074, nargs=0, args=0x0) at bytecode.c:785
---Type <return> to continue, or q <return> to quit---
        count = 15
        op = 1
        vectorp = 0x972f90
        stack = {
          pc = 0xb6224c "\024Ύ\317\f!\210\320\f\b\"\210\321\f\322\"\210\323\f\b\"\210\n\204W", 
          byte_string = 9908065, 
          byte_string_start = 0xb62216 "\306\b!\020\307\b!\031\310\b\236\032\311\033ʉ\034\035\v\312\036\026\211\036\027\203\060", 
          constants = 9908101, 
          next = 0x7fffffff8fa0
        }
        top = 0x7fffffff8a60
        result = 0
#26 0x00000000006004a4 in funcall_lambda (fun=9907997, nargs=1, 
    arg_vector=0x972f85) at eval.c:3205
        val = 1
        syms_left = 12741074
        next = 13559378
        lexenv = 12741074
        count = 14
        i = 1
        optional = 1
---Type <return> to continue, or q <return> to quit---
        rest = 0
#27 0x00000000005ffc4b in Ffuncall (nargs=2, args=0x7fffffff8f30)
    at eval.c:3023
        fun = 9907997
        original_fun = 13375106
        funcar = 19806420
        numargs = 1
        lisp_numargs = 12923922
        val = 12741074
        backtrace = {
          next = 0x7fffffff9380, 
          function = 0x7fffffff8f30, 
          args = 0x7fffffff8f38, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x200
        i = 18695024
#28 0x000000000064b475 in exec_byte_code (bytestr=10554729, vector=10554765, 
    maxdepth=20, args_template=12741074, nargs=0, args=0x0) at bytecode.c:785
        count = 9
        op = 1
        vectorp = 0xa10d98
---Type <return> to continue, or q <return> to quit---
        stack = {
          pc = 0xb2cfcf "\026\027\320\016\027!\210\016\035\311\036\036\211\036\037\203", <incomplete sequence \354>, 
          byte_string = 10554729, 
          byte_string_start = 0xb2cf1f "\306\b\236\203,", 
          constants = 10554765, 
          next = 0x7fffffff9470
        }
        top = 0x7fffffff8f30
        result = 29
#29 0x00000000006004a4 in funcall_lambda (fun=10554669, nargs=1, 
    arg_vector=0xa10d8d) at eval.c:3205
        val = 10552905
        syms_left = 12741074
        next = 13559378
        lexenv = 12741074
        count = 8
        i = 1
        optional = 1
        rest = 0
#30 0x00000000005ffc4b in Ffuncall (nargs=2, args=0x7fffffff9410)
    at eval.c:3023
        fun = 10554669
---Type <return> to continue, or q <return> to quit---
        original_fun = 13811954
        funcar = 140737488327680
        numargs = 1
        lisp_numargs = 6293965
        val = 40862342
        backtrace = {
          next = 0x7fffffff9850, 
          function = 0x7fffffff9410, 
          args = 0x7fffffff9418, 
          nargs = 1, 
          debug_on_exit = 0
        }
        internal_args = 0x180
        i = 12741074
#31 0x000000000064b475 in exec_byte_code (bytestr=10552641, vector=10552677, 
    maxdepth=16, args_template=12741074, nargs=0, args=0x0) at bytecode.c:785
        count = 8
        op = 1
        vectorp = 0xa10570
        stack = {
          pc = 0xb2d227 "\207", 
          byte_string = 10552641, 
          byte_string_start = 0xb2d1cb "\306\307!\203\037", 
---Type <return> to continue, or q <return> to quit---
          constants = 10552677, 
          next = 0x7fffffff9990
        }
        top = 0x7fffffff9410
        result = 40862598
#32 0x00000000006004a4 in funcall_lambda (fun=10552565, nargs=2, 
    arg_vector=0xa10565) at eval.c:3205
        val = 40862598
        syms_left = 12741074
        next = 13559378
        lexenv = 12741074
        count = 6
        i = 2
        optional = 1
        rest = 0
#33 0x00000000005ffc4b in Ffuncall (nargs=3, args=0x7fffffff9920)
    at eval.c:3023
        fun = 10552565
        original_fun = 15996290
        funcar = 0
        numargs = 2
        lisp_numargs = 0
        val = 40862390
---Type <return> to continue, or q <return> to quit---
        backtrace = {
          next = 0x7fffffff9d70, 
          function = 0x7fffffff9920, 
          args = 0x7fffffff9928, 
          nargs = 2, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffff9e90
        i = 12903362
#34 0x000000000064b475 in exec_byte_code (bytestr=30250433, vector=30253029, 
    maxdepth=52, args_template=5136, nargs=5, args=0x7fffffff9eb8)
    at bytecode.c:785
        count = 6
        op = 2
        vectorp = 0x1cd9ff0
        stack = {
          pc = 0x1c24d5a "\262\001\305\326\327\003\"\006\a\"\210\330\001!\210\331\006\006\332\003#\210\331\006\006\333\334\004!#\210\335\336\337!\340\"\210\207", 
          byte_string = 30250433, 
          byte_string_start = 0x1c24d08 "\300\301\302\"\210\303\304!\204\027", 
          constants = 30253029, 
          next = 0x7fffffff9f40
---Type <return> to continue, or q <return> to quit---
        }
        top = 0x7fffffff9920
        result = 12741074
#35 0x0000000000600178 in funcall_lambda (fun=30253509, nargs=5, 
    arg_vector=0x7fffffff9e90) at eval.c:3139
        val = 12741074
        syms_left = 5136
        next = 4294967296
        lexenv = 2
        count = 6
        i = 140737488325488
        optional = 0
        rest = 4000
#36 0x00000000005ffc4b in Ffuncall (nargs=6, args=0x7fffffff9e88)
    at eval.c:3023
        fun = 30253509
        original_fun = 30227618
        funcar = 12741074
        numargs = 5
        lisp_numargs = 30261057
        val = 12741074
        backtrace = {
          next = 0x7fffffffa320, 
---Type <return> to continue, or q <return> to quit---
          function = 0x7fffffff9e88, 
          args = 0x7fffffff9e90, 
          nargs = 5, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffa3c8
        i = 4
#37 0x000000000064b475 in exec_byte_code (bytestr=30257729, vector=31398373, 
    maxdepth=128, args_template=0, nargs=0, args=0x7fffffffa3c8)
    at bytecode.c:785
        count = 6
        op = 5
        vectorp = 0x1df19f0
        stack = {
          pc = 0x1c25512 "\202\024\003\005@\205\024\003\201O", 
          byte_string = 30257729, 
          byte_string_start = 0x1c25210 "\305\300!\210\306\300\307\310\311 !\312Q\"\210\313\312\301@\"\204&", 
          constants = 31398373, 
          next = 0x7fffffffa760
        }
        top = 0x7fffffff9e88
        result = 12741074
---Type <return> to continue, or q <return> to quit---
#38 0x0000000000600178 in funcall_lambda (fun=41183989, nargs=0, 
    arg_vector=0x7fffffffa3c8) at eval.c:3139
        val = 17179869184
        syms_left = 0
        next = 4294967295
        lexenv = 48
        count = 6
        i = 14
        optional = 0
        rest = 0
#39 0x00000000005ffc4b in Ffuncall (nargs=1, args=0x7fffffffa3c0)
    at eval.c:3023
        fun = 41183989
        original_fun = 41183989
        funcar = 2
        numargs = 0
        lisp_numargs = 6136368
        val = 140737488331728
        backtrace = {
          next = 0x7fffffffa490, 
          function = 0x7fffffffa3c0, 
          args = 0x7fffffffa3c8, 
          nargs = 0, 
---Type <return> to continue, or q <return> to quit---
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffa3c0
        i = 41091136
#40 0x00000000005fe29d in eval_sub (form=40798342) at eval.c:2294
        vals = 0x7fffffffa3c0
        argnum = 1
        sa_count = 6
        sa_must_free = 0
        numargs = 4
        args_left = 12741074
        i = -23616
        maxargs = 12741074
        argvals = {4208, 17200861749, 140737488331824, 6144291, 0, 39369040, 
          140737261112960, 48}
        fun = 12111453
        val = 140737488332112
        original_fun = 12865122
        original_args = 40798358
        funcar = 140737488332560
        backtrace = {
          next = 0x7fffffffab40, 
          function = 0x7fffffffa4c8, 
---Type <return> to continue, or q <return> to quit---
          args = 0x7fffffffa3c0, 
          nargs = 1, 
          debug_on_exit = 0
        }
        gcpro1 = {
          next = 0x5, 
          var = 0x5da230, 
          nvars = 80
        }
        gcpro2 = {
          next = 0x2730040, 
          var = 0x258b950, 
          nvars = 140737488331936
        }
        gcpro3 = {
          next = 0x5, 
          var = 0x7fffffffa3c0, 
          nvars = 1
        }
#41 0x00000000005fc55c in internal_lisp_condition_case (var=30257938, 
    bodyform=40798342, handlers=40798246) at eval.c:1453
        val = 12741074
        c = {
---Type <return> to continue, or q <return> to quit---
          tag = 12741074, 
          val = 12741074, 
          next = 0x7fffffffad90, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {140737488333800, -1323075187161163761, 12741074, 
                30227042, 0, 0, -1323075187112929265, 1323074641310652431}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {12741074, 140737488332480, 6289701, 140737488332080, 
                  0, 140737488332528, 6, 140737488333632, 140737488332528, 
                  140737488332536, 5, 0, 140737488332512, 40798310, 12865122, 
                  12806098}
              }
            }}, 
          backlist = 0x7fffffffab40, 
          handlerlist = 0x7fffffffb510, 
          lisp_eval_depth = 3, 
          pdlcount = 6, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x7fffffffa760
        }
---Type <return> to continue, or q <return> to quit---
        h = {
          handler = 40798246, 
          var = 30257938, 
          chosen_clause = 140737488332240, 
          tag = 0x7fffffffa5a0, 
          next = 0x7fffffffb510
        }
#42 0x000000000064c12e in exec_byte_code (bytestr=30256865, vector=20979829, 
    maxdepth=40, args_template=0, nargs=0, args=0x7fffffffabe8)
    at bytecode.c:981
        handlers = 40798246
        body = 40798342
        count = 6
        op = 143
        vectorp = 0x1402080
        stack = {
          pc = 0x1c25147 "\207", 
          byte_string = 30256865, 
          byte_string_start = 0x1c250b8 "\302\303\301@P\300\"\210\304\300\305\"\204V", 
          constants = 20979829, 
          next = 0x7fffffffaf50
        }
---Type <return> to continue, or q <return> to quit---
        top = 0x7fffffffa6d0
        result = 0
#43 0x0000000000600178 in funcall_lambda (fun=23586533, nargs=0, 
    arg_vector=0x7fffffffabe8) at eval.c:3139
        val = 12741074
        syms_left = 0
        next = 17179869184
        lexenv = 48
        count = 6
        i = 140737261112960
        optional = 0
        rest = 20979824
#44 0x00000000005ffc4b in Ffuncall (nargs=1, args=0x7fffffffabe0)
    at eval.c:3023
        fun = 23586533
        original_fun = 23586533
        funcar = 40
        numargs = 0
        lisp_numargs = 30077512146
        val = 2
        backtrace = {
          next = 0x7fffffffacb0, 
          function = 0x7fffffffabe0, 
---Type <return> to continue, or q <return> to quit---
          args = 0x7fffffffabe8, 
          nargs = 0, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffabe0
        i = 100000000
#45 0x00000000005fe29d in eval_sub (form=40798374) at eval.c:2294
        vals = 0x7fffffffabe0
        argnum = 1
        sa_count = 6
        sa_must_free = 0
        numargs = 4
        args_left = 12741074
        i = -21536
        maxargs = 12741074
        argvals = {5, 0, 0, 140737257928336, 20979824, 23586528, 
          140737488333952, 12741074}
        fun = 12111453
        val = 4294946656
        original_fun = 12865122
        original_args = 40798390
        funcar = 152
        backtrace = {
---Type <return> to continue, or q <return> to quit---
          next = 0x7fffffffb330, 
          function = 0x7ffffffface8, 
          args = 0x7fffffffabe0, 
          nargs = 1, 
          debug_on_exit = 0
        }
        gcpro1 = {
          next = 0x5, 
          var = 0x700000000, 
          nvars = 23586584
        }
        gcpro2 = {
          next = 0x27ef4a0, 
          var = 0x167e6e0, 
          nvars = 140737488334032
        }
        gcpro3 = {
          next = 0x5, 
          var = 0x7fffffffabe0, 
          nvars = 1
        }
#46 0x00000000005fc050 in internal_catch (tag=30227906, 
    func=0x5fdd25 <eval_sub>, arg=40798374) at eval.c:1256
---Type <return> to continue, or q <return> to quit---
        c = {
          tag = 30227906, 
          val = 12741074, 
          next = 0x7fffffffb540, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {140737488335816, -1323075187417016305, 12741074, 
                30227042, 0, 0, -1323075187377170417, 1323074641464530959}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {6289701, 0, 0, 140737488334552, 6, 140737488335664, 
                  140737488334552, 140737488334560, 5, 12741074, 12741074, 
                  140737488334544, 6175427, 12806098, 0, 5}
              }
            }}, 
          backlist = 0x7fffffffb330, 
          handlerlist = 0x7fffffffb510, 
          lisp_eval_depth = 1, 
          pdlcount = 6, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x7fffffffaf50
        }
---Type <return> to continue, or q <return> to quit---
#47 0x000000000064c0be in exec_byte_code (bytestr=30255249, vector=30289701, 
    maxdepth=48, args_template=2056, nargs=2, args=0x7fffffffb3d8)
    at bytecode.c:966
        v1 = 40798374
        count = 6
        op = 141
        vectorp = 0x1ce2f30
        stack = {
          pc = 0x1c2507d "\207", 
          byte_string = 30255249, 
          byte_string_start = 0x1c25068 "\211C\300\301\302\303\304\305\306\006\t\006\b\"\307\"\310\311%D\215\207", 
          constants = 30289701, 
          next = 0x0
        }
        top = 0x7fffffffaec8
        result = 40777526
#48 0x0000000000600178 in funcall_lambda (fun=30290005, nargs=2, 
    arg_vector=0x7fffffffb3c8) at eval.c:3139
        val = 1
        syms_left = 2056
        next = 6597069770240
        lexenv = 1116504333322
---Type <return> to continue, or q <return> to quit---
        count = 6
        i = 268435456
        optional = 0
        rest = 12563984
#49 0x00000000005ffc4b in Ffuncall (nargs=3, args=0x7fffffffb3c0)
    at eval.c:3023
        fun = 30290005
        original_fun = 30227042
        funcar = 140737488335760
        numargs = 2
        lisp_numargs = 6173970
        val = 140737488335808
        backtrace = {
          next = 0x0, 
          function = 0x7fffffffb3c0, 
          args = 0x7fffffffb3c8, 
          nargs = 2, 
          debug_on_exit = 0
        }
        internal_args = 0x7fffffffb3c0
        i = 12906096
#50 0x00000000005febe6 in Fapply (nargs=2, args=0x7fffffffb480) at eval.c:2479
        i = 3
---Type <return> to continue, or q <return> to quit---
        numargs = 2
        spread_arg = 12741074
        funcall_args = 0x7fffffffb3c0
        fun = 30290005
        retval = 4973694
        gcpro1 = {
          next = 0x7fffffffb410, 
          var = 0x589c32, 
          nvars = 3
        }
        sa_count = 6
        sa_must_free = 0
#51 0x00000000005ff133 in apply1 (fn=30227042, arg=40798438) at eval.c:2717
        ret_ungc_val = 13414437
        args = {30227042, 40798438}
        gcpro1 = {
          next = 0x4be3f9, 
          var = 0x7fffffffb480, 
          nvars = 2
        }
#52 0x0000000000656f98 in read_process_output_call (fun_and_args=40798422)
    at process.c:4967
No locals.
---Type <return> to continue, or q <return> to quit---
#53 0x00000000005fc83d in internal_condition_case_1 (
    bfun=0x656f6a <read_process_output_call>, arg=40798422, handlers=12793266, 
    hfun=0x656f9a <read_process_output_error_handler>) at eval.c:1537
        val = 12793266
        c = {
          tag = 12741074, 
          val = 12741074, 
          next = 0x7fffffffd590, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {12793266, -1323075186603321329, 67, 30227042, 0, 0, 
                -1323075186555086833, 1323074641215363087}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {4300774963, 12741074, 12769125, 12552544, 12769120, 
                  12741074, 43479120, 140737488336400, 12789760, 5807616, 
                  13997941, 12741074, 67, 67, 25776097741, 12741122}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x7fffffffd560, 
          lisp_eval_depth = 0, 
          pdlcount = 6, 
---Type <return> to continue, or q <return> to quit---
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 12793266, 
          var = 12741074, 
          chosen_clause = 0, 
          tag = 0x7fffffffb540, 
          next = 0x7fffffffd560
        }
#54 0x0000000000657632 in read_process_output (proc=43479125, channel=67)
    at process.c:5167
        text = 41193569
        outer_running_asynch_code = 0
        waiting = -1
        nbytes = 67
        chars = 0x7fffffffb680 ":0.0 -window-system -file /home/horn/Protokoll-Westerwaldbank.txt \nare/man:/usr/share/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.21.1/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.3/man:/etc"...
        outstream = 30227042
        p = 0xc335b2
        opoint = 30227042
---Type <return> to continue, or q <return> to quit---
        coding = 0x15a7400
        carryover = 0
        readmax = 4096
        count = 3
        odeactivate = 12741074
#55 0x00000000006568d6 in wait_reading_process_output (time_limit=30, 
    microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=12741074, 
    wait_proc=0x0, just_wait_proc=0) at process.c:4804
        nread = 0
        timeout_reduced_for_timers = 1
        channel = 20
        nfds = 1
        Available = {
          fds_bits = {1048576, 0 <repeats 15 times>}
        }
        Writeok = {
          fds_bits = {0 <repeats 16 times>}
        }
        check_write = 1
        check_delay = 1
        no_avail = 0
        xerrno = 11
        proc = 43479125
---Type <return> to continue, or q <return> to quit---
        timeout = {
          tv_sec = 0, 
          tv_usec = 59875
        }
        end_time = {
          tv_sec = 1318401682, 
          tv_usec = 489297
        }
        wait_channel = -1
        got_some_input = 1
        count = 2
#56 0x0000000000423225 in sit_for (timeout=120, reading=1, do_display=1)
    at dispnew.c:5971
        sec = 30
        usec = 0
#57 0x0000000000565f2c in read_char (commandflag=1, nmaps=9, 
    maps=0x7fffffffcf40, prev_event=12741074, used_mouse_menu=0x7fffffffd164, 
    end_time=0x0) at keyboard.c:2687
        tem0 = 0
        timeout = 30
        delay_level = 4
        buffer_size = 1
        c = 12741074
---Type <return> to continue, or q <return> to quit---
        jmpcount = 2
        local_getcjmp = {{
            __jmpbuf = {9, -1323075188503341041, 4286720, 140737488346352, 0, 
              0, -1323075188387997681, 1323074723291076623}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {780, 140737488342800, 6208925, 0, 0, 0, 0, 0, 12769120, 
                0, 12775154, 140737488342544, 6737913, 0, 5, 8589934627}
            }
          }}
        save_jump = {{
            __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, 
            __mask_was_saved = 0, 
            __saved_mask = {
              __val = {0 <repeats 16 times>}
            }
          }}
        key_already_recorded = 0
        tem = 5754146
        save = 140737488343400
        previous_echo_area_message = 12741074
        also_record = 12741074
        reread = 0
---Type <return> to continue, or q <return> to quit---
        gcpro1 = {
          next = 0x7fffffffcc10, 
          var = 0x66cdb7, 
          nvars = 140737488342064
        }
        gcpro2 = {
          next = 0xffffcbe0, 
          var = 0x7fffffffcc38, 
          nvars = 12741074
        }
        polling_stopped_here = 0
        orig_kboard = 0x1091c00
#58 0x0000000000572e19 in read_key_sequence (keybuf=0x7fffffffd3d0, 
    bufsize=30, prompt=12741074, dont_downcase_last=0, 
    can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9282
        interrupted_kboard = 0x1091c00
        interrupted_frame = 0x1452e00
        key = 12769125
        used_mouse_menu = 0
        echo_local_start = 0
        last_real_key_start = 0
        keys_local_start = 0
        local_first_binding = 0
---Type <return> to continue, or q <return> to quit---
        from_string = 12741074
        count = 2
        t = 0
        echo_start = 0
        keys_start = 0
        nmaps = 9
        nmaps_allocated = 9
        defs = 0x7fffffffcee0
        submaps = 0x7fffffffcf40
        orig_local_map = 15860886
        orig_keymap = 12741074
        localized_local_map = 0
        first_binding = 0
        first_unbound = 31
        mock_input = 0
        fkey = {
          parent = 18142822, 
          map = 18142822, 
          start = 0, 
          end = 0
        }
        keytran = {
          parent = 12720550, 
---Type <return> to continue, or q <return> to quit---
          map = 12720550, 
          start = 0, 
          end = 0
        }
        indec = {
          parent = 18142806, 
          map = 18142806, 
          start = 0, 
          end = 0
        }
        shift_translated = 0
        delayed_switch_frame = 12741074
        original_uppercase = 196
        original_uppercase_position = -1
        dummyflag = 0
        starting_buffer = 0xc2d760
        fake_prefixed_keys = 12741074
        outer_gcpro1 = {
          next = 0x7fffffffd1a0, 
          var = 0x5e3512, 
          nvars = 21268741
        }
#59 0x0000000000563692 in command_loop_1 () at keyboard.c:1447
---Type <return> to continue, or q <return> to quit---
        cmd = 14035666
        keybuf = {536871144, 212, 192, 6174127, 140737488344160, 12741074, 
          276967387, 1, 140737488344160, 6176458, 12741074, 12863618, 
          140737488344240, 6175427, 12578912, 8589923456, 0, 12863616, 
          140737488344320, 6294545, 12985638, 8589934593, 12863618, 12741074, 
          0, 0, 4286720, 140737488346352, 140737488344320, 6293965}
        i = 1
        prev_modiff = 15
        prev_buffer = 0xc2d760
        already_adjusted = 0
#60 0x00000000005fc6c4 in internal_condition_case (
    bfun=0x5632a9 <command_loop_1>, handlers=12793266, 
    hfun=0x562b99 <cmd_error>) at eval.c:1499
        val = 0
        c = {
          tag = 12741074, 
          val = 12741074, 
          next = 0x7fffffffd710, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {1, -1323075187687548913, 4286720, 140737488346352, 
                0, 0, -1323075187647703025, 1323074641263728655}, 
              __mask_was_saved = 0, 
---Type <return> to continue, or q <return> to quit---
              __saved_mask = {
                __val = {1323074641263728655, 0, 4294967295, 5696316, 1, 
                  9343624, 0, 0, 0, 0, 140737351956354, 1, 0, 1, 
                  140737257473672, 0}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
        h = {
          handler = 12793266, 
          var = 12741074, 
          chosen_clause = 12793266, 
          tag = 0x7fffffffd590, 
          next = 0x0
        }
#61 0x0000000000562f99 in command_loop_2 (ignore=12741074) at keyboard.c:1158
        val = 1
---Type <return> to continue, or q <return> to quit---
#62 0x00000000005fc050 in internal_catch (tag=12789058, 
    func=0x562f73 <command_loop_2>, arg=12741074) at eval.c:1256
        c = {
          tag = 12789058, 
          val = 12741074, 
          next = 0x0, 
          gcpro = 0x0, 
          jmp = {{
              __jmpbuf = {1, -1323075187735783409, 4286720, 140737488346352, 
                0, 0, -1323075187695937521, 1323074641464530959}, 
              __mask_was_saved = 0, 
              __saved_mask = {
                __val = {6175427, 112, 4301654456, 140737261113048, 12741074, 
                  12134176, 12769120, 14, 1, 140737488345072, 12968192, 
                  140737488345136, 12741074, 4286720, 140737488346352, 
                  140737488345152}
              }
            }}, 
          backlist = 0x0, 
          handlerlist = 0x0, 
          lisp_eval_depth = 0, 
          pdlcount = 2, 
          poll_suppress_count = 1, 
---Type <return> to continue, or q <return> to quit---
          interrupt_input_blocked = 0, 
          byte_stack = 0x0
        }
#63 0x0000000000562f4c in command_loop () at keyboard.c:1137
No locals.
#64 0x00000000005626df in recursive_edit_1 () at keyboard.c:757
        count = 1
        val = 12741074
#65 0x0000000000562881 in Frecursive_edit () at keyboard.c:821
        count = 0
        buffer = 12741074
#66 0x00000000005609f5 in main (argc=1, argv=0x7fffffffdcf8) at emacs.c:1706
        dummy = 140737353901264
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = 1
        skip_args = 0
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = 0
        junk = 0x0
        dname_arg = 0x0
---Type <return> to continue, or q <return> to quit---
        ch_to_dir = 0x7ffff7fbfea0 "@\344\377\367\377\177"

Lisp Backtrace:
"x-create-frame" (0xffff8a68)
"x-create-frame-with-faces" (0xffff8f38)
"make-frame" (0xffff9418)
"make-frame-on-display" (0xffff9928)
"server-create-window-system-frame" (0xffff9e90)
0x2746af0 PVEC_COMPILED
"funcall" (0xffffa3c0)
0x167e6e0 PVEC_COMPILED
"funcall" (0xffffabe0)
"server-process-filter" (0xffffb3c8)
(gdb)
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: Killing a frame sometimes kills emacs

[Stefan Monnier]

> I commente 3 lines as indicated below:

> --8<---------------cut here---------------start------------->8---
>     /* If needed, delete the terminal that this frame was on.
>        (This must be done after the frame is killed.) */
>     terminal->reference_count--;
>     if (terminal->reference_count == 0)
>       {
> 	// Lisp_Object tmp;
> 	// XSETTERMINAL (tmp, terminal);

>         kb = NULL;
> 	// Fdelete_terminal (tmp, NILP (force) ? Qt : force);
>       }
>     else
>       kb = terminal->kboard;
> --8<---------------cut here---------------end--------------->8---

> I'm not sure if keeping the "kb = NULL;" was correct, though.  If you
> want, I can try again with the complete then block commented.

I'd suggest to only comment out the "terminal->reference_count--;".


        Stefan

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>> I commente 3 lines as indicated below:
>
>> --8<---------------cut here---------------start------------->8---
>>     /* If needed, delete the terminal that this frame was on.
>>        (This must be done after the frame is killed.) */
>>     terminal->reference_count--;
>>     if (terminal->reference_count == 0)
>>       {
>> 	// Lisp_Object tmp;
>> 	// XSETTERMINAL (tmp, terminal);
>
>>         kb = NULL;
>> 	// Fdelete_terminal (tmp, NILP (force) ? Qt : force);
>>       }
>>     else
>>       kb = terminal->kboard;
>> --8<---------------cut here---------------end--------------->8---
>
>> I'm not sure if keeping the "kb = NULL;" was correct, though.  If you
>> want, I can try again with the complete then block commented.
>
> I'd suggest to only comment out the "terminal->reference_count--;".

I did that by using the patch below for about one month.  Since then,
the crashes I had are gone, and working with multiple emacs X frames is
fun again.  Should I go ahead and commit?

--8<---------------cut here---------------start------------->8---
=== modified file 'src/frame.c'
--- src/frame.c 2011-11-17 09:09:20 +0000
+++ src/frame.c 2011-11-17 10:05:11 +0000
@@ -1358,7 +1358,11 @@
 
     /* If needed, delete the terminal that this frame was on.
        (This must be done after the frame is killed.) */
-    terminal->reference_count--;
+
+    // FIXME: Deleting the terminal crashes emacs because of a GTK
+    // bug.  See the thread starting with <87d3flnxoo.fsf@thinkpad.tsdh.de>
+    // on emacs-devel.
+    // terminal->reference_count--;
     if (terminal->reference_count == 0)
       {
        Lisp_Object tmp;
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo
-- 
(What the world needs (I think) is not
      (a Lisp (with fewer parentheses))
      but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf

Re: Killing a frame sometimes kills emacs

[Chong Yidong]

Tassilo Horn <tassilo@member.fsf.org> writes:

> I did that by using the patch below for about one month.  Since then,
> the crashes I had are gone, and working with multiple emacs X frames is
> fun again.  Should I go ahead and commit?

Fine by me, but the code should probably be something like

#ifdef USE_GTK
    /* ... (Use C-style not C++ style comments) ... */
    if (terminal->type != output_x_window)
#endif
    terminal->reference_count--;

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Chong Yidong <cyd@gnu.org> writes:

>> I did that by using the patch below for about one month.  Since then,
>> the crashes I had are gone, and working with multiple emacs X frames
>> is fun again.  Should I go ahead and commit?
>
> Fine by me, but the code should probably be something like
>
> #ifdef USE_GTK
>     /* ... (Use C-style not C++ style comments) ... */
>     if (terminal->type != output_x_window)
> #endif
>     terminal->reference_count--;

So the one below is fine, right?  What about the indentation of the line
after the #endif?  Emacs' <tab> wants it to be correct in the USE_GTK
case, while you have it correct in the other case.

--8<---------------cut here---------------start------------->8---
=== modified file 'src/frame.c'
--- src/frame.c 2011-11-17 09:09:20 +0000
+++ src/frame.c 2011-11-17 13:40:27 +0000
@@ -1358,7 +1358,14 @@
 
     /* If needed, delete the terminal that this frame was on.
        (This must be done after the frame is killed.) */
-    terminal->reference_count--;
+
+#ifdef USE_GTK
+    /* FIXME: Deleting the terminal crashes emacs because of a GTK
+       bug.  See the thread starting with
+       <87d3flnxoo.fsf@thinkpad.tsdh.de> on emacs-devel.  */
+    if (terminal->type != output_x_window)
+#endif /* USE_GTK */
+      terminal->reference_count--;
     if (terminal->reference_count == 0)
       {
        Lisp_Object tmp;
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo
-- 
(What the world needs (I think) is not
      (a Lisp (with fewer parentheses))
      but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf

Re: Killing a frame sometimes kills emacs

[Paul Eggert]

On 11/17/11 05:45, Tassilo Horn wrote:
> +#ifdef USE_GTK
> +    /* FIXME: Deleting the terminal crashes emacs because of a GTK
> +       bug.  See the thread starting with
> +       <87d3flnxoo.fsf@thinkpad.tsdh.de> on emacs-devel.  */
> +    if (terminal->type != output_x_window)
> +#endif /* USE_GTK */
> +      terminal->reference_count--;

Could you please use a URL rather than a Message-ID?  The latter
is hard for a random reader to follow.  Perhaps the URL
<http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00363.html>
is what is meant?  (Sorry, I can't easily tell.)

Also, this code would be easier to read:

    if (! (use_gtk && terminal->type == output_x_window))
      terminal->reference_count--;

with something like this near the start of the file:

   #ifdef USE_GTK
    enum { use_gtk = 1 };
   #else
    enum { use_gtk = 0 };
   #endif

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Paul Eggert <eggert@cs.ucla.edu> writes:

Hi Paul,

> On 11/17/11 05:45, Tassilo Horn wrote:
>> +#ifdef USE_GTK
>> +    /* FIXME: Deleting the terminal crashes emacs because of a GTK
>> +       bug.  See the thread starting with
>> +       <87d3flnxoo.fsf@thinkpad.tsdh.de> on emacs-devel.  */
>> +    if (terminal->type != output_x_window)
>> +#endif /* USE_GTK */
>> +      terminal->reference_count--;
>
> Could you please use a URL rather than a Message-ID?  The latter is
> hard for a random reader to follow.  Perhaps the URL
> <http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00363.html>
> is what is meant?  (Sorry, I can't easily tell.)

Yes, the Message-ID was the top-level message of that thread, but the
link you cite is actually where the important information drops in.

> Also, this code would be easier to read:
>
>     if (! (use_gtk && terminal->type == output_x_window))
>       terminal->reference_count--;
>
> with something like this near the start of the file:
>
>    #ifdef USE_GTK
>     enum { use_gtk = 1 };
>    #else
>     enum { use_gtk = 0 };
>    #endif

In my opinion, it's better to keep temporary workarounds for buggy
external libs as local as possible.  But I don't really care, as long as
it fixes the crashes.

Bye,
Tassilo
-- 
(What the world needs (I think) is not
      (a Lisp (with fewer parentheses))
      but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf

Re: Killing a frame sometimes kills emacs

[Chong Yidong]

Paul Eggert <eggert@cs.ucla.edu> writes:

> Also, this code would be easier to read:
>
>     if (! (use_gtk && terminal->type == output_x_window))
>       terminal->reference_count--;
>
> with something like this near the start of the file:
>
>    #ifdef USE_GTK
>     enum { use_gtk = 1 };
>    #else
>     enum { use_gtk = 0 };
>    #endif

We don't follow this practice elsewhere in Emacs; let's not start now.

Re: Killing a frame sometimes kills emacs

[Stefan Monnier]

> I did that by using the patch below for about one month.  Since then,
> the crashes I had are gone, and working with multiple emacs X frames is
> fun again.  Should I go ahead and commit?

Good news, thanks.

> --8<---------------cut here---------------start------------->8---
> === modified file 'src/frame.c'
> --- src/frame.c 2011-11-17 09:09:20 +0000
> +++ src/frame.c 2011-11-17 10:05:11 +0000
> @@ -1358,7 +1358,11 @@
 
>      /* If needed, delete the terminal that this frame was on.
>         (This must be done after the frame is killed.) */
> -    terminal->reference_count--;
> +
> +    // FIXME: Deleting the terminal crashes emacs because of a GTK
> +    // bug.  See the thread starting with <87d3flnxoo.fsf@thinkpad.tsdh.de>
> +    // on emacs-devel.
> +    // terminal->reference_count--;
>      if (terminal->reference_count == 0)
>        {
>         Lisp_Object tmp;
> --8<---------------cut here---------------end--------------->8---

To avoid the risk of reaching 0 via wrap-around (yes, I know that
creating a billion frames in the life of a single session is unlikely,
but still), you could do:

     /* If needed, delete the terminal that this frame was on.
        (This must be done after the frame is killed.) */
     terminal->reference_count--;
#ifdef USE_GTK
    /* ... (Use C-style not C++ style comments) ... */
    if (terminal->reference_count == 0 && terminal->type == output_x_window)
      terminal->reference_count = 1;
#endif
     if (terminal->reference_count == 0)
       {
        Lisp_Object tmp;

Alternatively you could get the same result by changing the code that
initializes terminal->reference_count so that it starts at 1 rather than
at 0.


        Stefan

Re: Killing a frame sometimes kills emacs

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

> To avoid the risk of reaching 0 via wrap-around (yes, I know that
> creating a billion frames in the life of a single session is unlikely,
> but still), you could do:
>
>      /* If needed, delete the terminal that this frame was on.
>         (This must be done after the frame is killed.) */
>      terminal->reference_count--;
> #ifdef USE_GTK
>     /* ... (Use C-style not C++ style comments) ... */
>     if (terminal->reference_count == 0 && terminal->type == output_x_window)
>       terminal->reference_count = 1;
> #endif
>      if (terminal->reference_count == 0)
>        {
>         Lisp_Object tmp;

I liked this version best and it's committed now.

Bye,
Tassilo
-- 
(What the world needs (I think) is not
      (a Lisp (with fewer parentheses))
      but (an English (with more.)))
Brian Hayes, http://tinyurl.com/3y9l2kf

Re: Killing a frame sometimes kills emacs

[andres.ramirez]

Hi.

I have revno 106895. And this problem still persist.

emacs is configured as follows:
In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
 of 2012-01-20 on wari
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib' '--mandir=/usr/share/man/emacs-24' '--without-sound' '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24' '--with-x-toolkit=gtk3' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''

Regards

At Fri, 18 Nov 2011 10:38:39 +0100,
Tassilo Horn wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> Hi Stefan,
> 
> > To avoid the risk of reaching 0 via wrap-around (yes, I know that
> > creating a billion frames in the life of a single session is unlikely,
> > but still), you could do:
> >
> >      /* If needed, delete the terminal that this frame was on.
> >         (This must be done after the frame is killed.) */
> >      terminal->reference_count--;
> > #ifdef USE_GTK
> >     /* ... (Use C-style not C++ style comments) ... */
> >     if (terminal->reference_count == 0 && terminal->type == output_x_window)
> >       terminal->reference_count = 1;
> > #endif
> >      if (terminal->reference_count == 0)
> >        {
> >         Lisp_Object tmp;
> 
> I liked this version best and it's committed now.
> 
> Bye,
> Tassilo
> -- 
> (What the world needs (I think) is not
>       (a Lisp (with fewer parentheses))
>       but (an English (with more.)))
> Brian Hayes, http://tinyurl.com/3y9l2kf
> 
> 

Re: Killing a frame sometimes kills emacs

[Glenn Morris]

andres.ramirez wrote:

> I have revno 106895. And this problem still persist.
>
> emacs is configured as follows:
> In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
>  of 2012-01-20 on wari

If you have that revision, why is your version number not 24.0.92?

Re: Killing a frame sometimes kills emacs

[andres.ramirez]

Hi Glenn.

the problem was my emacs-build directory, after removing it I got 

In GNU Emacs 24.0.92.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
 of 2012-01-20 on wari
Windowing system distributor `The X.Org Foundation', version
 11.0.11103000
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc'
 '--localstatedir=/var' '--libexecdir=/usr/lib'
 '--mandir=/usr/share/man/emacs-24' '--without-sound'
 '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24'
 '--with-x-toolkit=gtk3' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe
 -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''

And also the problem is GONE, sorry for bothering

Regards
At Fri, 20 Jan 2012 19:34:02 -0500,
Glenn Morris wrote:
> 
> andres.ramirez wrote:
> 
> > I have revno 106895. And this problem still persist.
> >
> > emacs is configured as follows:
> > In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
> >  of 2012-01-20 on wari
> 
> If you have that revision, why is your version number not 24.0.92?
> 
> 

Re: Killing a frame sometimes kills emacs

[andres.ramirez]

Hi.

I have revno 106895. And this problem still persist.

emacs is configured as follows:
In GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 3.2.3)
 of 2012-01-20 on wari
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
configured using `configure  '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' '--libexecdir=/usr/lib' '--mandir=/usr/share/man/emacs-24' '--without-sound' '--program-suffix=-emacs-24' '--infodir=/usr/share/info/emacs-24' '--with-x-toolkit=gtk3' 'CFLAGS=-march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu''

Regards

At Fri, 18 Nov 2011 10:38:39 +0100,
Tassilo Horn wrote:
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> Hi Stefan,
> 
> > To avoid the risk of reaching 0 via wrap-around (yes, I know that
> > creating a billion frames in the life of a single session is unlikely,
> > but still), you could do:
> >
> >      /* If needed, delete the terminal that this frame was on.
> >         (This must be done after the frame is killed.) */
> >      terminal->reference_count--;
> > #ifdef USE_GTK
> >     /* ... (Use C-style not C++ style comments) ... */
> >     if (terminal->reference_count == 0 && terminal->type == output_x_window)
> >       terminal->reference_count = 1;
> > #endif
> >      if (terminal->reference_count == 0)
> >        {
> >         Lisp_Object tmp;
> 
> I liked this version best and it's committed now.
> 
> Bye,
> Tassilo
> -- 
> (What the world needs (I think) is not
>       (a Lisp (with fewer parentheses))
>       but (an English (with more.)))
> Brian Hayes, http://tinyurl.com/3y9l2kf
> 
> 

Re: Killing a frame sometimes kills emacs

[Jan Djärv]

Tassilo Horn skrev 2011-10-11 08:46:

> For me and I guess for most users, localhost:0, unix:0 (*), :0.0, and :0
> are all the same in practice, only localhost:1 or :2 actually mean other
> displays.  So I'd simply strip localhost and unix before the colon and
> dot-zeros.  (Maybe there should be an option for that, or some lisp
> function that would be called to transform the display name if it is
> defined...)
>

It is probably better to use some heruistics to see if two displays are really 
the same.  If the root window id and the default visual id are the same, they 
probably are the same display.  You can throw in protocol version, vendor 
string, screen dimension checks also.

	Jan D.