Creating X frame crash

[Alok G. Singh]

I'm not entirely sure that this is the right place but anyway, here goes. Please let me know the right place to post this if this is the wrong place.

I get a SEGV if I try to create an X frame with the latest emacs-lorentey. I am using your debian packages of 27-06. I have managed to get a gdb backtrace but the error seems to be from Xlib, and I'm not sure how to proceed.

I can create text (emacsclient -t) frames just fine. I am getting the multi-tty package to see if the same error occurs there. I will report it if it does.

The backtrace is:

GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) r -nw
Starting program: /usr/bin/emacs -nw
[Thread debugging using libthread_db enabled]
[New Thread -1214146880 (LWP 923)]
Warning: locale not supported by Xlib, locale set to C

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214146880 (LWP 923)]
0xb7ca074d in XPending () from /usr/lib/libX11.so.6
(gdb) bt
#0 0xb7ca074d in XPending () from /usr/lib/libX11.so.6
#1 0x080cfe62 in XTread_socket (terminal=0x876c188, expected=1,
hold_quit=0xbfb45ea0) at xterm.c:7049
#2 0x080fb53e in read_avail_input (expected=1) at keyboard.c:6837
#3 0x080fb5ea in handle_async_input () at keyboard.c:7047
#4 0x080cfa06 in x_term_init (display_name=141529587, xrm_option=0x0,
resource_name=0x87a82e0 "emacs") at xterm.c:10432
#5 0x080d83a2 in Fx_open_connection (display=141529587, xrm_string=137644233,
must_succeed=137644233) at xfns.c:4052
#6 0x0815d3a1 in Ffuncall (nargs=4, args=0xbfb46030) at eval.c:2910
#7 0x081891b9 in Fbyte_code (bytestr=137252555, vector=137252908, maxdepth=56)
at bytecode.c:694
#8 0x0815ce92 in funcall_lambda (fun=137252524, nargs=0,
arg_vector=0xbfb46164) at eval.c:3091
#9 0x0815d30f in Ffuncall (nargs=1, args=0xbfb46160) at eval.c:2950
#10 0x081891b9 in Fbyte_code (bytestr=136918259, vector=136918316, maxdepth=32)
at bytecode.c:694
#11 0x0815ce92 in funcall_lambda (fun=136918204, nargs=2,
arg_vector=0xbfb46284) at eval.c:3091
#12 0x0815d30f in Ffuncall (nargs=3, args=0xbfb46280) at eval.c:2950
#13 0x081891b9 in Fbyte_code (bytestr=141648523, vector=141488300,
maxdepth=112) at bytecode.c:694
#14 0x0815c7ca in Feval (form=138543493) at eval.c:2250
#15 0x0815ee81 in internal_lisp_condition_case (var=137975273,
bodyform=138543493, handlers=139516061) at eval.c:1421
#16 0x081884ff in Fbyte_code (bytestr=141648571, vector=139421148, maxdepth=40)
at bytecode.c:884
#17 0x0815ce92 in funcall_lambda (fun=140721556, nargs=2,
arg_vector=0xbfb465e4) at eval.c:3091
#18 0x0815d30f in Ffuncall (nargs=3, args=0xbfb465e0) at eval.c:2950
#19 0x0815ea93 in Fapply (nargs=2, args=0xbfb46630) at eval.c:2396
#20 0x0815eb84 in apply1 (fn=141796969, arg=141180109) at eval.c:2660
#21 0x0818bacd in read_process_output_call (fun_and_args=141180101)
at process.c:4916
#22 0x0815baa1 in internal_condition_case_1 (
bfun=0x818bab0 <read_process_output_call>, arg=141180101,
handlers=137709993, hfun=0x818ba60 <read_process_output_error_handler>)
at eval.c:1524
#23 0x0818b36f in read_process_output (proc=140722300,
channel=<value optimized out>) at process.c:5143
#24 0x0818f6e4 in wait_reading_process_output (time_limit=30, microsecs=0,
read_kbd=-1, do_display=1, wait_for_cell=137644233, wait_proc=0x0,
just_wait_proc=0) at process.c:4756
#25 0x080543c6 in sit_for (sec=30, usec=0, reading=1, display=1,
initial_display=0) at dispnew.c:6565
#26 0x081007b7 in read_char (commandflag=1, nmaps=2, maps=0xbfb47dc0,
prev_event=137644233, used_mouse_menu=0xbfb47e58) at keyboard.c:2866
#27 0x081029b1 in read_key_sequence (keybuf=0xbfb47f04, bufsize=30,
prompt=137644233, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:9022
#28 0x08104645 in command_loop_1 () at keyboard.c:1610
#29 0x0815bceb in internal_condition_case (bfun=0x81044b0 <command_loop_1>,
handlers=137709993, hfun=0x80fee30 <cmd_error>) at eval.c:1476
#30 0x080fe0be in command_loop_2 () at keyboard.c:1400
#31 0x0815bdac in internal_catch (tag=137692369,
func=0x80fe090 <command_loop_2>, arg=137644233) at eval.c:1214
#32 0x080feae9 in command_loop () at keyboard.c:1379
#33 0x080feb97 in recursive_edit_1 () at keyboard.c:987
#34 0x080fece2 in Frecursive_edit () at keyboard.c:1049
#35 0x080f4e7d in main (argc=2, argv=0xbfb485f4) at emacs.c:1798

[Alok G. Singh]

Post by Alok G. Singh
I am getting the multi-tty package to see if the same error occurs
there. I will report it if it does.

No problems there. If I toggle-debug-on-error, it complains about the mark begin inactive but opens up the frame nevertheless.

[Károly Lőrentey]

Post by Alok G. Singh

Post by Alok G. Singh
I am getting the multi-tty package to see if the same error occurs
there. I will report it if it does.

No problems there. If I toggle-debug-on-error, it complains about the mark begin inactive but opens up the frame nevertheless.

Hm, I didn't see this myself. Does the latest revision still crash?

[Alok G. Singh]

Post by Károly Lőrentey

Post by Alok G. Singh
No problems there. If I toggle-debug-on-error, it complains about
the mark begin inactive but opens up the frame nevertheless.

Hm, I didn't see this myself. Does the latest revision still crash?

Nope, the latest build seems fine. I have a feeling that the crash was
due to some bad interaction between tmm (transient-mark-mode) and
multi-tty. I have noticed in the past that tmm makes the menubar
inaccessible to clicks and cause some other strange happenings off and
on with CVS Emacs.