* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
@ 2011-01-31 16:59 Peter Dyballa
2011-01-31 22:07 ` Jan Djärv
0 siblings, 1 reply; 22+ messages in thread
From: Peter Dyballa @ 2011-01-31 16:59 UTC (permalink / raw)
To: 7949
Hello!
After installing a series of updates to the X.Org server on my Mac I
cannot launch (any) GNU Emacs version that used Xaw3d as X client. It
works to launch it without windows, or as the NS variant – or with
GTK-2! I reported this to Jeremy Huddleston, an employee of Apple,
presumingly, who develops X11 for Mac OS X. He found some details and
started a thread in the xorg-devel list in which he speculates that
something in the GNU Emacs code might be faulty ("2) emacs' error
handler seems bugged. Is it legal to call XSync() within the error
handler? It certainly seems like it shouldn't. Did we used to actually
support this with the xtrans version of libX11?")
– http://lists.x.org/archives/xorg-devel/2011-January/018750.html.
Interestingly gv, which uses Xaw3d as well, can easily launch...
(Before the updates I could launch all GNU Emacs versions with Xaw3d
toolkit.)
--
Greetings
Pete (:
_ / __ - -
_/ \__/_/ - -
(´`) (´`) - -
`´ `´
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-01-31 16:59 bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client Peter Dyballa
@ 2011-01-31 22:07 ` Jan Djärv
2011-01-31 23:49 ` Peter Dyballa
0 siblings, 1 reply; 22+ messages in thread
From: Jan Djärv @ 2011-01-31 22:07 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
Can you put a breakpoint in the X error handler and see what the error is
about? You must run in synchronous mode for the stack backtrace to be useful:
% emacs -xrm '*synchronous: true'
Does commenting out the XSync in the error handler fix things?
Jan D.
Peter Dyballa skrev 2011-01-31 17.59:
> Hello!
>
> After installing a series of updates to the X.Org server on my Mac I cannot
> launch (any) GNU Emacs version that used Xaw3d as X client. It works to launch
> it without windows, or as the NS variant – or with GTK-2! I reported this to
> Jeremy Huddleston, an employee of Apple, presumingly, who develops X11 for Mac
> OS X. He found some details and started a thread in the xorg-devel list in
> which he speculates that something in the GNU Emacs code might be faulty ("2)
> emacs' error handler seems bugged. Is it legal to call XSync() within the
> error handler? It certainly seems like it shouldn't. Did we used to actually
> support this with the xtrans version of libX11?")
> – http://lists.x.org/archives/xorg-devel/2011-January/018750.html.
>
> Interestingly gv, which uses Xaw3d as well, can easily launch...
>
>
> (Before the updates I could launch all GNU Emacs versions with Xaw3d toolkit.)
>
> --
> Greetings
>
> Pete (:
> _ / __ - -
> _/ \__/_/ - -
> (´`) (´`) - -
> `´ `´
>
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-01-31 22:07 ` Jan Djärv
@ 2011-01-31 23:49 ` Peter Dyballa
2011-02-01 7:20 ` Jan Djärv
0 siblings, 1 reply; 22+ messages in thread
From: Peter Dyballa @ 2011-01-31 23:49 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 31.01.2011 um 23:07 schrieb Jan Djärv:
> Does commenting out the XSync in the error handler fix things?
Which line is it? The first one?
./lwlib/xlwmenu.c:2263: XSync (XtDisplay (mw), False);
./oldXMenu/Activate.c:240: XSync(display, 0);
./oldXMenu/Activate.c:543: XSync(display, 0);
./src/xfns.c:4171: XSync (FRAME_X_DISPLAY (f), False);
./src/xfns.c:4512: XSync (FRAME_X_DISPLAY (f), False);
./src/xselect.c:781: /* 2004-09-10: XSync and UNBLOCK so that
possible protocol errors are
./src/xselect.c:783: XSync (display, False);
./src/xterm.c:5851: XSync (d, False);
./src/xterm.c:7566: XSync (dpy, False);
./src/xterm.c:7585: Check if it is still open before calling
XSync. */
./src/xterm.c:7587: XSync (x_error_message->dpy, False);
./src/xterm.c:7603: XSync (dpy, False);
./src/xterm.c:7621: XSync (dpy, False);
./src/xterm.c:8682: /* In theory, this call to XSync only needs
to happen once, but in
./src/xterm.c:8686: XSync (FRAME_X_DISPLAY (f), False);
./src/xterm.c:9024: XSync (FRAME_X_DISPLAY (f), False);
I'm not that experienced with debugging (or X programming), and I also
think that I never could create a backtrace from gdb... (for Jeremy
Huddleston I used the spindump command while GNU Emacs was trying to
launch)
I could retry to configure GNU Emacs with more exact debug options,
like maximum level and exactly telling to use the native DWARF2 format..
--
Greetings
Pete
Either this man is dead or my watch has stopped.
- Groucho Marx
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-01-31 23:49 ` Peter Dyballa
@ 2011-02-01 7:20 ` Jan Djärv
2011-02-01 10:53 ` Peter Dyballa
` (4 more replies)
0 siblings, 5 replies; 22+ messages in thread
From: Jan Djärv @ 2011-02-01 7:20 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
2011-02-01 00:49, Peter Dyballa skrev:
>
> Am 31.01.2011 um 23:07 schrieb Jan Djärv:
>
>> Does commenting out the XSync in the error handler fix things?
>
> Which line is it? The first one?
>
On Emacs checked out now, it is xterm.c:7566, in function x_catch_errors.
Does Emacs emit any error message when it quits or does it just die?
You could start gdb on emacs (with or without XSync removed):
% gdb emacs
(gdb) b x_connection_closed
(gdb) r -xrm '*synchronous: true'
// error occurs
(gdb) p error_message
(gdb) bt
This is supposing the error handler is invoked. Anyway, if emacs dies when
running in gdb, you will get a gdb prompt. Do
(gdb) bt
if that happens.
Jan D.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-01 7:20 ` Jan Djärv
@ 2011-02-01 10:53 ` Peter Dyballa
2011-02-01 17:23 ` Peter Dyballa
` (3 subsequent siblings)
4 siblings, 0 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-01 10:53 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 01.02.2011 um 08:20 schrieb Jan Djärv:
> Does Emacs emit any error message when it quits or does it just die?
It *never* dies – at least not in the first eight minutes. (Then my
CPU is so hot, in local winter time, that I kill GNU Emacs. And it
dumps a core file. 256 MB.)
--
Greetings
Pete
Specifications are for the weak and timid!
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-01 7:20 ` Jan Djärv
2011-02-01 10:53 ` Peter Dyballa
@ 2011-02-01 17:23 ` Peter Dyballa
2011-02-01 18:02 ` Peter Dyballa
` (2 subsequent siblings)
4 siblings, 0 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-01 17:23 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 01.02.2011 um 08:20 schrieb Jan Djärv:
> % gdb emacs
> (gdb) b x_connection_closed
> (gdb) r -xrm '*synchronous: true'
> // error occurs
> (gdb) p error_message
> (gdb) bt
I did from inside GNU Emacs, with gud-gdb. Here is the contents of the
*gud-emacs* buffer (looks pretty good):
Current directory is .../emacs-24.0.50/src/
GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14
UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols
for shared libraries ........................... done
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x7a58bc0
Breakpoint 2 at 0x1667ec: file sysdep.c, line 838.
(gdb) b x_connection_closed
Breakpoint 3 at 0x1052e4: file xterm.c, line 7688.
(gdb) r -xrm '*synchronous: true'
Starting program: .../emacs-24.0.50/src/emacs -xrm '*synchronous: true'
Reading symbols for shared libraries +++++++++++++++++++++++++
+
...............................................................................................warning
: Could not find object file [for some bzr related things]
.. done
Breakpoint 1 at 0x9134abc0
Breakpoint 3, x_connection_closed (dpy=0x3034e00,
error_message=0xbfffb948 "X protocol error: BadValue (integer
parameter out of range for operation) on protocol request 45") at
xterm.c:433
(gdb) p error_message
$1 = 0xbfffb948 "X protocol error: BadValue (integer parameter out of
range for operation) on protocol request 45"
(gdb) bt
#0 x_connection_closed (dpy=0x3034e00, error_message=0xbfffb948 "X
protocol error: BadValue (integer parameter out of range for
operation) on protocol request 45") at xterm.c:433
#1 0x00105770 in x_error_quitter (display=0x3034e00,
error=0xbfffb948) at xterm.c:7862
#2 0x001057e4 in x_error_handler (display=<value temporarily
unavailable, due to optimizations>, error=<value temporarily
unavailable, due to optimizations>) at xterm.c:7832
#3 0x006d8b38 in _XError ()
#4 0x006d52f8 in handle_error ()
#5 0x006d55e4 in handle_response ()
#6 0x006d60c0 in _XReply ()
#7 0x006b2b74 in _XQueryFont ()
#8 0x006b3dd8 in XLoadQueryFont ()
#9 0x0056692c in XtCvtStringToFontStruct ()
#10 0x00563958 in CallConverter ()
#11 0x00563f2c in _XtConvert ()
#12 0x00582a60 in GetResources ()
#13 0x00583124 in _XtGetResources ()
#14 0x00569b14 in xtCreate ()
#15 0x0056a1cc in _XtCreateWidget ()
#16 0x0056a288 in XtCreateWidget ()
#17 0x00272194 in xlw_create_menubar (instance=0x187fe00) at lwlib-
Xlw.c:151
#18 0x00270568 in allocate_widget_instance [inlined] () at .../
emacs-24.0.50/lwlib/lwlib.c:814
#19 lw_make_widget (id=<value temporarily unavailable, due to
optimizations>, parent=0x1856710, pop_up_p=0 '\0') at .../
emacs-24.0.50/lwlib/lwlib.c:858
#20 0x000772e0 in set_frame_menubar (f=0x184af60, first_time=<value
temporarily unavailable, due to optimizations>, deep_p=1) at xmenu.c:
1213
#21 0x00112d54 in Fx_create_frame (parms=23147686) at xfns.c:3415
#22 0x001e1ae4 in Ffuncall (nargs=<value temporarily unavailable, due
to optimizations>, args=<value temporarily unavailable, due to
optimizations>) at eval.c:2842
#23 0x00233614 in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=<value temporarily unavailable, due to
optimizations>) at bytecode.c:676
#24 0x001e1274 in funcall_lambda (fun=2961272, nargs=2307640,
arg_vector=0x431808) at eval.c:3028
#25 0x001e172c in Ffuncall (nargs=4397064, args=<value temporarily
unavailable, due to optimizations>) at eval.c:2902
#26 0x00233614 in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=<value temporarily unavailable, due to
optimizations>) at bytecode.c:676
#27 0x001e1274 in funcall_lambda (fun=3298960, nargs=2307640,
arg_vector=0x431808) at eval.c:3028
#28 0x001e172c in Ffuncall (nargs=4397064, args=<value temporarily
unavailable, due to optimizations>) at eval.c:2902
#29 0x00233614 in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=<value temporarily unavailable, due to
optimizations>) at bytecode.c:676
#30 0x001e1274 in funcall_lambda (fun=3296296, nargs=2307640,
arg_vector=0x431808) at eval.c:3028
#31 0x001e172c in Ffuncall (nargs=4397064, args=<value temporarily
unavailable, due to optimizations>) at eval.c:2902
#32 0x00233614 in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=<value temporarily unavailable, due to
optimizations>) at bytecode.c:676
#33 0x001e1274 in funcall_lambda (fun=2998368, nargs=2307640,
arg_vector=0x431808) at eval.c:3028
#34 0x001e172c in Ffuncall (nargs=4397064, args=<value temporarily
unavailable, due to optimizations>) at eval.c:2902
#35 0x00233614 in Fbyte_code (bytestr=<value temporarily unavailable,
due to optimizations>, vector=<value temporarily unavailable, due to
optimizations>, maxdepth=<value temporarily unavailable, due to
optimizations>) at bytecode.c:676
#36 0x001e1274 in funcall_lambda (fun=2995792, nargs=2307640,
arg_vector=0x431808) at eval.c:3028
#37 0x001e39e4 in apply_lambda (fun=4659208, args=<value temporarily
unavailable, due to optimizations>, eval_flag=1) at eval.c:2954
#38 0x001e04ec in Feval (form=<value temporarily unavailable, due to
optimizations>) at eval.c:2314
#39 0x001df9ec in internal_condition_case (bfun=0x1435e0
<top_level_2>, handlers=41977714, hfun=0x147910 <cmd_error>) at eval.c:
1408
#40 0x001458cc in top_level_1 (ignore=<value temporarily unavailable,
due to optimizations>) at keyboard.c:1146
#41 0x001dfb50 in internal_catch (tag=<value temporarily unavailable,
due to optimizations>, func=0x145870 <top_level_1>, arg=41949218) at
eval.c:1152
#42 0x00147dd0 in recursive_edit_1 () at keyboard.c:1101
#43 0x00148014 in Frecursive_edit () at keyboard.c:793
#44 0x0013e430 in main (argc=3, argv=0xbffff7bc) at emacs.c:1682
Lisp Backtrace:
"x-create-frame" (0xbfffe214)
"x-create-frame-with-faces" (0xbfffe474)
"make-frame" (0xbfffe6d4)
"frame-initialize" (0xbfffe934)
"command-line" (0xbfffeb94)
"normal-top-level" (0xbfffed40)
(gdb) The program is running. Exit anyway? (y or n) y
Debugger finished
Line #433 is the for statement in this function:
/* Return the struct x_display_info corresponding to DPY. */
struct x_display_info *
x_display_info_for_display (Display *dpy)
{
struct x_display_info *dpyinfo;
for (dpyinfo = x_display_list; dpyinfo; dpyinfo = dpyinfo->next)
if (dpyinfo->display == dpy)
return dpyinfo;
return 0;
}
I'll compile once more with -O0 and line #7566 in xterm.c commented.
--
Greetings
Pete
Only two things are infinite, the universe and human stupidity, and
I'm not sure about the former.
– Albert Einstein
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-01 7:20 ` Jan Djärv
2011-02-01 10:53 ` Peter Dyballa
2011-02-01 17:23 ` Peter Dyballa
@ 2011-02-01 18:02 ` Peter Dyballa
2011-02-02 10:28 ` Peter Dyballa
2011-02-03 10:58 ` Peter Dyballa
4 siblings, 0 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-01 18:02 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 01.02.2011 um 08:20 schrieb Jan Djärv:
> % gdb emacs
> (gdb) b x_connection_closed
> (gdb) r -xrm '*synchronous: true'
> // error occurs
> (gdb) p error_message
> (gdb) bt
In xterm.c I moved " */" by few lines from #7568 to #7571:
/* The display may have been closed before this function is called.
Check if it is still open before calling XSync. */
if (x_display_info_for_display (x_error_message->dpy) != 0)
XSync (x_error_message->dpy, False);
=>
/* The display may have been closed before this function is called.
Check if it is still open before calling XSync.
if (x_display_info_for_display (x_error_message->dpy) != 0)
XSync (x_error_message->dpy, False);
*/
Just commenting the XSync would produce an error. Then I reconfigured
to compile with -O0. This binary now shows this behaviour:
Current directory is .../emacs-24.0.50/src/
GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:15:14
UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols
for shared libraries ........................... done
DISPLAY = :0
TERM = dumb
Breakpoint 1 at 0x7a58bc0
Breakpoint 2 at 0x19e468: file sysdep.c, line 836.
(gdb) b x_connection_closed
Breakpoint 3 at 0x12a198: file xterm.c, line 7688.
(gdb) r -xrm '*synchronous: true'
Starting program: .../emacs-24.0.50/src/emacs -xrm '*synchronous: true'
Reading symbols for shared libraries +++++++++++++++++++++++++
+
...............................................................................................warning
: Could not find object file [for some bzr related things]
.. done
Breakpoint 1 at 0x9134abc0
Breakpoint 3, x_connection_closed (dpy=0x3034a00,
error_message=0xbfffb258 "X protocol error: BadValue (integer
parameter out of range for operation) on protocol request 45") at
xterm.c:7689
(gdb) p error_message
$1 = 0xbfffb258 "X protocol error: BadValue (integer parameter out of
range for operation) on protocol request 45"
(gdb) bt
#0 x_connection_closed (dpy=0x3034a00, error_message=0xbfffb258 "X
protocol error: BadValue (integer parameter out of range for
operation) on protocol request 45") at xterm.c:7689
#1 0x0012a780 in x_error_quitter (display=0x3034a00,
error=0xbfffb468) at xterm.c:7862
#2 0x0012a6c0 in x_error_handler (display=0x3034a00,
error=0xbfffb468) at xterm.c:7832
#3 0x00780b38 in _XError ()
#4 0x0077d2f8 in handle_error ()
#5 0x0077d5e4 in handle_response ()
#6 0x0077e0c0 in _XReply ()
#7 0x0075ab74 in _XQueryFont ()
#8 0x0075bdd8 in XLoadQueryFont ()
#9 0x0060e92c in XtCvtStringToFontStruct ()
#10 0x0060b958 in CallConverter ()
#11 0x0060bf2c in _XtConvert ()
#12 0x0062aa60 in GetResources ()
#13 0x0062b124 in _XtGetResources ()
#14 0x00611b14 in xtCreate ()
#15 0x006121cc in _XtCreateWidget ()
#16 0x00612288 in XtCreateWidget ()
#17 0x00309164 in xlw_create_menubar (instance=0x187fd00) at lwlib-
Xlw.c:151
#18 0x003079d4 in instantiate_widget_instance (instance=0x187fd00)
at .../emacs-24.0.50/lwlib/lwlib.c:814
#19 0x00306494 in allocate_widget_instance (info=0x186cfd0,
parent=0x18568b0, pop_up_p=0 '\0') at .../emacs-24.0.50/lwlib/lwlib.c:
308
#20 0x00307ba8 in lw_make_widget (id=1, parent=0x18568b0, pop_up_p=0
'\0') at .../emacs-24.0.50/lwlib/lwlib.c:858
#21 0x00307c68 in lw_create_widget (type=0x316e70 "menubar",
name=0x316e70 "menubar", id=1, val=0x185c960, parent=0x18568b0,
pop_up_p=0 '\0', pre_activate_cb=0x7fd38 <popup_activate_callback>,
selection_cb=0x7ff1c <menubar_selection_callback>,
post_activate_cb=0x7fd90 <popup_deactivate_callback>,
highlight_cb=0x7fe7c <menu_highlight_callback>) at .../emacs-24.0.50/
lwlib/lwlib.c:874
#22 0x00080fac in set_frame_menubar (f=0x184af10, first_time=1,
deep_p=1) at xmenu.c:1213
#23 0x000811b4 in initialize_frame_menubar (f=0x184af10) at xmenu.c:1280
#24 0x0013b910 in Fx_create_frame (parms=21723694) at xfns.c:3415
#25 0x0024777c in Ffuncall (nargs=2, args=0xbfffdb00) at eval.c:2842
#26 0x002b3e94 in Fbyte_code (bytestr=3579993, vector=3580013,
maxdepth=20) at bytecode.c:676
#27 0x00248464 in funcall_lambda (fun=3579957, nargs=1,
arg_vector=0xbfffde84) at eval.c:3028
#28 0x00247b04 in Ffuncall (nargs=2, args=0xbfffde80) at eval.c:2891
#29 0x002b3e94 in Fbyte_code (bytestr=3917681, vector=3917701,
maxdepth=24) at bytecode.c:676
#30 0x00248464 in funcall_lambda (fun=3917653, nargs=1,
arg_vector=0xbfffe204) at eval.c:3028
#31 0x00247b04 in Ffuncall (nargs=2, args=0xbfffe200) at eval.c:2891
#32 0x002b3e94 in Fbyte_code (bytestr=3915017, vector=3915037,
maxdepth=24) at bytecode.c:676
#33 0x00248464 in funcall_lambda (fun=3914989, nargs=0,
arg_vector=0xbfffe584) at eval.c:3028
#34 0x00247b04 in Ffuncall (nargs=1, args=0xbfffe580) at eval.c:2891
#35 0x002b3e94 in Fbyte_code (bytestr=3617089, vector=3617109,
maxdepth=28) at bytecode.c:676
#36 0x00248464 in funcall_lambda (fun=3617069, nargs=0,
arg_vector=0xbfffe904) at eval.c:3028
#37 0x00247b04 in Ffuncall (nargs=1, args=0xbfffe900) at eval.c:2891
#38 0x002b3e94 in Fbyte_code (bytestr=3614513, vector=3614533,
maxdepth=24) at bytecode.c:676
#39 0x00248464 in funcall_lambda (fun=3614493, nargs=0,
arg_vector=0xbfffebf0) at eval.c:3028
#40 0x00247efc in apply_lambda (fun=3614493, args=41949218,
eval_flag=1) at eval.c:2954
#41 0x00245ef4 in Feval (form=21720750) at eval.c:2296
#42 0x0017236c in top_level_2 () at keyboard.c:1138
#43 0x002435f8 in internal_condition_case (bfun=0x172338
<top_level_2>, handlers=41977714, hfun=0x171c98 <cmd_error>) at eval.c:
1408
#44 0x001723f4 in top_level_1 (ignore=41949218) at keyboard.c:1146
#45 0x00242d40 in internal_catch (tag=41975810, func=0x17238c
<top_level_1>, arg=41949218) at eval.c:1152
#46 0x00172224 in command_loop () at keyboard.c:1101
#47 0x0017144c in recursive_edit_1 () at keyboard.c:731
#48 0x00171740 in Frecursive_edit () at keyboard.c:793
#49 0x0016ed48 in main (argc=3, argv=0xbffff7bc) at emacs.c:1682
Lisp Backtrace:
"x-create-frame" (0xbfffdb04)
"x-create-frame-with-faces" (0xbfffde84)
"make-frame" (0xbfffe204)
"frame-initialize" (0xbfffe584)
"command-line" (0xbfffe904)
"normal-top-level" (0xbfffebf0)
(gdb)
Line #7689 in xterm.c is the dpyinfo declaration:
static SIGTYPE
x_connection_closed (Display *dpy, const char *error_message)
{
struct x_display_info *dpyinfo = x_display_info_for_display (dpy);
Lisp_Object frame, tail;
int index = SPECPDL_INDEX ();
error_msg = (char *) alloca (strlen (error_message) + 1);
strcpy (error_msg, error_message);
handling_signal = 0;
/* Prevent being called recursively because of an error condition
below. Otherwise, we might end up with printing ``can't find per
display information'' in the recursive call instead of printing
the original message here. */
x_catch_errors (dpy);
--
Greetings
Pete
Reisen bildet - vor allem Staus auf Autobahnen.
(Michael Schiff)
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-01 7:20 ` Jan Djärv
` (2 preceding siblings ...)
2011-02-01 18:02 ` Peter Dyballa
@ 2011-02-02 10:28 ` Peter Dyballa
2011-02-02 19:36 ` Jan Djärv
2011-02-03 10:58 ` Peter Dyballa
4 siblings, 1 reply; 22+ messages in thread
From: Peter Dyballa @ 2011-02-02 10:28 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 01.02.2011 um 08:20 schrieb Jan Djärv:
> On Emacs checked out now, it is xterm.c:7566, in function
> x_catch_errors.
I forgot to mention that this first commenting did not change the
behaviour of the Xaw3d variant of the X client: GNU Emacs still stays
invisible and does not appear, not even after minutes of waiting.
--
Greetings
Pete
»¿ʇı̣ əsnqɐ ʇ,uɐɔ noʎ ɟı̣
ɓuı̣ɥʇʎuɐ sı̣ pooɓ ʇɐɥʍ«
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-02 10:28 ` Peter Dyballa
@ 2011-02-02 19:36 ` Jan Djärv
2011-02-02 22:41 ` Peter Dyballa
0 siblings, 1 reply; 22+ messages in thread
From: Jan Djärv @ 2011-02-02 19:36 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
Peter Dyballa skrev 2011-02-02 11.28:
>
> Am 01.02.2011 um 08:20 schrieb Jan Djärv:
>
>> On Emacs checked out now, it is xterm.c:7566, in function
>> x_catch_errors.
>
>
> I forgot to mention that this first commenting did not change the behaviour
> of the Xaw3d variant of the X client: GNU Emacs still stays invisible and
> does not appear, not even after minutes of waiting.
>
This means we can rule out XSync in the error handler.
As you are the one seeing this, I suggest you try to follw the advice in
etc/DEBUG about debugging infinite loops.
> Breakpoint 3, x_connection_closed (dpy=0x3034a00, error_message=0xbfffb258
> "X protocol error: BadValue (integer parameter out of range for operation)
> on protocol request 45") at xterm.c:7689
45 is X_OpenFont. The font the menu bar tries to open is
-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1
What happens if you do
% xterm -fn '-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1'
or
% xfd -fn '-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1'
?
Jan D.
Jan D.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-02 19:36 ` Jan Djärv
@ 2011-02-02 22:41 ` Peter Dyballa
0 siblings, 0 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-02 22:41 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 02.02.2011 um 20:36 schrieb Jan Djärv:
> 45 is X_OpenFont. The font the menu bar tries to open is
> -*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1
>
> What happens if you do
> % xterm -fn '-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1'
> or
> % xfd -fn '-*-helvetica-medium-r-*--*-120-*-*-*-*-iso8859-1'
> ?
With these fonts, and also in iso10646-1 encoding (LANG and LC_CTYPE
have UTF-8), it's all OK. But I found that the font from this X resource
Emacs*pane.menubar.font: -linotype-optima-black-*-*-*-10-*-*-*-*-*-*-*
makes problems. Xfd and xterm report (their windows don't appear on
screen):
X Error of failed request: BadValue (integer parameter out of range
for operation)
Major opcode of failed request: 45 (X_OpenFont)
Value in failed request: 0x1400014
Serial number of failed request: 37
Current serial number in output stream: 38
When I select it in xfontsel manually, xfontsel disappears from screen
with a similar report (major opcode is the same). Removing the
resource lets all Xaw3d Emacsen launch again...
Either
Emacs*pane.menubar.font: -linotype-optima-black-*-*-*-10-*-*-*-*-*-*-*
took precedence over
Emacs.pane.menubar.faceName: Libris ADF Std-9:style=Bold
after the X server upgrade or the X server cannot use
/sw/lib/X11/fonts/applettf/OptimaBold.ttf
/sw/lib/X11/fonts/applettf/OptimaBoldItalic.ttf
/sw/lib/X11/fonts/applettf/OptimaExtraBlack.ttf
/sw/lib/X11/fonts/applettf/OptimaItalic.ttf
/sw/lib/X11/fonts/applettf/OptimaRegular.ttf
anymore, which were created from Apple's /Library/Fonts/Optima.dfont
with fondu. FontForge has no problem with all five TT fonts and
Apple's fonts package as well.
In fontconfig I have a configuration mistake because fc-list shows
that family names come from the DFONT *and* the TTF files. Could this
cause the failure, could GNU Emacs switch from X server as "fonts
provider" to libfontconfig when the name is given as XLFD?
'-linotype-optima-black-*-*-*-10-*-*-*-*-*-*-*' once worked! Otherwise
I would not have chosen it; I first try to see that the X resource
setting actually works and does what I want to have as effect.
Jan, thank you for guiding me to this detection!
--
Greetings
Pete
Well begun is half done.
– Optimist.
Half done is well begun.
– Realist.
Half begun is well done.
– Australian.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-01 7:20 ` Jan Djärv
` (3 preceding siblings ...)
2011-02-02 10:28 ` Peter Dyballa
@ 2011-02-03 10:58 ` Peter Dyballa
2011-02-03 12:59 ` Jan Djärv
2011-02-03 13:47 ` Jan Djärv
4 siblings, 2 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-03 10:58 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 01.02.2011 um 08:20 schrieb Jan Djärv:
> This is supposing the error handler is invoked.
Is the error handler invoked? If so, it does not seem to work. Xterm
or xfd clearly say that the font cannot be loaded and quit. Why is GNU
Emacs spinning around in something like an infinite loop?
Jeremy Huddleston keeps saying:
> Now the reason emacs is spinning is because it's not handling the
> error correctly. It's calling XSync() from within its
> x_error_handler().
--
Greetings
Pete
What is this talk of 'release?' Klingons do not make software
'releases.' Our software 'escapes,' leaving a bloody trail of
designers and quality assurance people in its wake.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 10:58 ` Peter Dyballa
@ 2011-02-03 12:59 ` Jan Djärv
2011-02-03 14:25 ` Peter Dyballa
2011-02-03 13:47 ` Jan Djärv
1 sibling, 1 reply; 22+ messages in thread
From: Jan Djärv @ 2011-02-03 12:59 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
2011-02-03 11:58, Peter Dyballa skrev:
>
> Am 01.02.2011 um 08:20 schrieb Jan Djärv:
>
>> This is supposing the error handler is invoked.
>
>
> Is the error handler invoked? If so, it does not seem to work. Xterm or xfd
> clearly say that the font cannot be loaded and quit. Why is GNU Emacs spinning
> around in something like an infinite loop?
>
> Jeremy Huddleston keeps saying:
>
>> Now the reason emacs is spinning is because it's not handling the error
>> correctly. It's calling XSync() from within its x_error_handler().
>
You said it still hanged when XSync was commented out. So something else is
wrong. Did you read etc/DEBUG?
Jan D.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 10:58 ` Peter Dyballa
2011-02-03 12:59 ` Jan Djärv
@ 2011-02-03 13:47 ` Jan Djärv
2011-02-03 14:26 ` Peter Dyballa
` (2 more replies)
1 sibling, 3 replies; 22+ messages in thread
From: Jan Djärv @ 2011-02-03 13:47 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
2011-02-03 11:58, Peter Dyballa skrev:
>
> Am 01.02.2011 um 08:20 schrieb Jan Djärv:
>
>> This is supposing the error handler is invoked.
>
>
> Is the error handler invoked? If so, it does not seem to work. Xterm or xfd
> clearly say that the font cannot be loaded and quit. Why is GNU Emacs spinning
> around in something like an infinite loop?
>
> Jeremy Huddleston keeps saying:
>
>> Now the reason emacs is spinning is because it's not handling the error
>> correctly. It's calling XSync() from within its x_error_handler().
>
It turns out that XtCloseDisplay also calls XSync. I removed all XSync from
the error handler. Can you try with a frech checkout from trunk?
Jan D.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 12:59 ` Jan Djärv
@ 2011-02-03 14:25 ` Peter Dyballa
0 siblings, 0 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-03 14:25 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 03.02.2011 um 13:59 schrieb Jan Djärv:
> Did you read etc/DEBUG?
Years ago. I'll re-read it and continue debugging. Today, this
evening, I'd like to work on the text font problem, bug#7956. finding
that font minimising statement should happen in a finite span of time.
--
Greetings
Pete
We need a president who's fluent in at least one language.
– Buck Henry
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 13:47 ` Jan Djärv
@ 2011-02-03 14:26 ` Peter Dyballa
2011-02-03 15:18 ` Peter Dyballa
2011-02-03 20:29 ` Peter Dyballa
2 siblings, 0 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-03 14:26 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 03.02.2011 um 14:47 schrieb Jan Djärv:
> Can you try with a frech checkout from trunk?
Yes!
--
Greetings
Pete
If men could get pregnant, abortion would be a sacrament.
– Florynce Kennedy
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 13:47 ` Jan Djärv
2011-02-03 14:26 ` Peter Dyballa
@ 2011-02-03 15:18 ` Peter Dyballa
2011-02-03 19:02 ` Jan Djärv
2011-02-03 20:29 ` Peter Dyballa
2 siblings, 1 reply; 22+ messages in thread
From: Peter Dyballa @ 2011-02-03 15:18 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 03.02.2011 um 14:47 schrieb Jan Djärv:
> 2011-02-03 11:58, Peter Dyballa skrev:
>>
>> Am 01.02.2011 um 08:20 schrieb Jan Djärv:
>>
>>> This is supposing the error handler is invoked.
>>
>>
>> Is the error handler invoked? If so, it does not seem to work.
>> Xterm or xfd
>> clearly say that the font cannot be loaded and quit. Why is GNU
>> Emacs spinning
>> around in something like an infinite loop?
>>
>> Jeremy Huddleston keeps saying:
>>
>>> Now the reason emacs is spinning is because it's not handling the
>>> error
>>> correctly. It's calling XSync() from within its x_error_handler().
>>
>
> It turns out that XtCloseDisplay also calls XSync. I removed all
> XSync from the error handler. Can you try with a frech checkout
> from trunk?
Jan,
to avoid possible misunderstandings: Since I removed (and then
corrected to iso8859-1 encoding) one X resource, all my Xaw3d X
clients of GNU Emacs launch. Only in gdb it halted with the once
modified xterm.c *while* that resource was set.
So my task is to check whether GNU Emacs launches from gdb when that
faulty resource is set? (which can be accomplished by running it with
arguments "-xrm '*synchronous: true' -xrm '*pane.menubar.font: -
linotype-optima-black-*-*-*-10-*-*-*-*-*-iso10646-1'")
--
Greetings
Pete
Never be led astray onto the path of virtue
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 15:18 ` Peter Dyballa
@ 2011-02-03 19:02 ` Jan Djärv
0 siblings, 0 replies; 22+ messages in thread
From: Jan Djärv @ 2011-02-03 19:02 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
Peter Dyballa skrev 2011-02-03 16.18:
> Jan,
>
> to avoid possible misunderstandings: Since I removed (and then corrected to
> iso8859-1 encoding) one X resource, all my Xaw3d X clients of GNU Emacs
> launch. Only in gdb it halted with the once modified xterm.c *while* that
> resource was set.
>
> So my task is to check whether GNU Emacs launches from gdb when that faulty
> resource is set? (which can be accomplished by running it with arguments "-xrm
> '*synchronous: true' -xrm '*pane.menubar.font:
> -linotype-optima-black-*-*-*-10-*-*-*-*-*-iso10646-1'")
>
Yes, please.
Jan D.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 13:47 ` Jan Djärv
2011-02-03 14:26 ` Peter Dyballa
2011-02-03 15:18 ` Peter Dyballa
@ 2011-02-03 20:29 ` Peter Dyballa
2011-02-04 15:30 ` Jan Djärv
2 siblings, 1 reply; 22+ messages in thread
From: Peter Dyballa @ 2011-02-03 20:29 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 03.02.2011 um 14:47 schrieb Jan Djärv:
> It turns out that XtCloseDisplay also calls XSync. I removed all
> XSync from the error handler.
During the first tries (with gdb and command line) something's seemed
faulty: GNU Emacs did launch! Presumingly because I have two X
resources:
Emacs*pane.menubar.font: -linotype-optima-black-*-*-*-10-*-*-*-*-
*-iso8859-1
Emacs.pane.menubar.faceName: Libris ADF Std-9:style=Bold
The latter one was the effective one, overriding the "-xrm
'*pane.menubar.font: -linotype-optima-black-*-*-*-10-*-*-*-*-*-
iso10646-1'". Removing this resource brings back the previous
behaviour! Here are the lower 60 % of the *gud-emacs-...* buffer:
Breakpoint 1 at 0x9134abc0
Breakpoint 3, x_connection_closed (dpy=0x3834e00,
error_message=0xbfffb178 "X protocol error: BadValue (integer
parameter out of range for operation) on protocol request 45") at
xterm.c:7689
(gdb) p error_message
$1 = 0xbfffb178 "X protocol error: BadValue (integer parameter out of
range for operation) on protocol request 45"
(gdb) bt
#0 x_connection_closed (dpy=0x3834e00, error_message=0xbfffb178 "X
protocol error: BadValue (integer parameter out of range for
operation) on protocol request 45") at xterm.c:7689
#1 0x0012a988 in x_error_quitter (display=0x3834e00,
error=0xbfffb388) at xterm.c:7837
#2 0x0012a8c8 in x_error_handler (display=0x3834e00,
error=0xbfffb388) at xterm.c:7807
#3 0x00783b38 in _XError ()
#4 0x007802f8 in handle_error ()
#5 0x007805e4 in handle_response ()
#6 0x007810c0 in _XReply ()
#7 0x0075db74 in _XQueryFont ()
#8 0x0075edd8 in XLoadQueryFont ()
#9 0x0061192c in XtCvtStringToFontStruct ()
#10 0x0060e958 in CallConverter ()
#11 0x0060ef2c in _XtConvert ()
#12 0x0062da60 in GetResources ()
#13 0x0062e124 in _XtGetResources ()
#14 0x00614b14 in xtCreate ()
#15 0x006151cc in _XtCreateWidget ()
#16 0x00615288 in XtCreateWidget ()
#17 0x0030ac24 in xlw_create_menubar (instance=0x187d160) at lwlib-
Xlw.c:151
#18 0x00309488 in instantiate_widget_instance (instance=0x187d160)
at .../emacs-24.0.50/lwlib/lwlib.c:814
#19 0x00307f48 in allocate_widget_instance (info=0x1866230,
parent=0x1851640, pop_up_p=0 '\0') at .../emacs-24.0.50/lwlib/lwlib.c:
308
#20 0x0030965c in lw_make_widget (id=1, parent=0x1851640, pop_up_p=0
'\0') at .../emacs-24.0.50/lwlib/lwlib.c:858
#21 0x0030971c in lw_create_widget (type=0x318a80 "menubar",
name=0x318a80 "menubar", id=1, val=0x1807e30, parent=0x1851640,
pop_up_p=0 '\0', pre_activate_cb=0x7ff38 <popup_activate_callback>,
selection_cb=0x8011c <menubar_selection_callback>,
post_activate_cb=0x7ff90 <popup_deactivate_callback>,
highlight_cb=0x8007c <menu_highlight_callback>) at .../emacs-24.0.50/
lwlib/lwlib.c:874
#22 0x000811ac in set_frame_menubar (f=0x184afd0, first_time=1,
deep_p=1) at xmenu.c:1213
#23 0x000813b4 in initialize_frame_menubar (f=0x184afd0) at xmenu.c:1280
#24 0x0013bb18 in Fx_create_frame (parms=23062686) at xfns.c:3415
#25 0x00247988 in Ffuncall (nargs=2, args=0xbfffda20) at eval.c:2842
#26 0x002b40a0 in Fbyte_code (bytestr=3588769, vector=3588789,
maxdepth=20) at bytecode.c:676
#27 0x00248670 in funcall_lambda (fun=3588733, nargs=1,
arg_vector=0xbfffdda4) at eval.c:3028
#28 0x00247d10 in Ffuncall (nargs=2, args=0xbfffdda0) at eval.c:2891
#29 0x002b40a0 in Fbyte_code (bytestr=3926489, vector=3926509,
maxdepth=24) at bytecode.c:676
#30 0x00248670 in funcall_lambda (fun=3926461, nargs=1,
arg_vector=0xbfffe124) at eval.c:3028
#31 0x00247d10 in Ffuncall (nargs=2, args=0xbfffe120) at eval.c:2891
#32 0x002b40a0 in Fbyte_code (bytestr=3923825, vector=3923845,
maxdepth=24) at bytecode.c:676
#33 0x00248670 in funcall_lambda (fun=3923797, nargs=0,
arg_vector=0xbfffe4a4) at eval.c:3028
#34 0x00247d10 in Ffuncall (nargs=1, args=0xbfffe4a0) at eval.c:2891
#35 0x002b40a0 in Fbyte_code (bytestr=3625865, vector=3625885,
maxdepth=28) at bytecode.c:676
#36 0x00248670 in funcall_lambda (fun=3625845, nargs=0,
arg_vector=0xbfffe824) at eval.c:3028
#37 0x00247d10 in Ffuncall (nargs=1, args=0xbfffe820) at eval.c:2891
#38 0x002b40a0 in Fbyte_code (bytestr=3623289, vector=3623309,
maxdepth=24) at bytecode.c:676
#39 0x00248670 in funcall_lambda (fun=3623269, nargs=0,
arg_vector=0xbfffeb10) at eval.c:3028
#40 0x00248108 in apply_lambda (fun=3623269, args=41949218,
eval_flag=1) at eval.c:2954
#41 0x00246100 in Feval (form=23060102) at eval.c:2296
#42 0x00172578 in top_level_2 () at keyboard.c:1138
#43 0x00243804 in internal_condition_case (bfun=0x172544
<top_level_2>, handlers=41977714, hfun=0x171ea4 <cmd_error>) at eval.c:
1408
#44 0x00172600 in top_level_1 (ignore=41949218) at keyboard.c:1146
#45 0x00242f4c in internal_catch (tag=41975810, func=0x172598
<top_level_1>, arg=41949218) at eval.c:1152
#46 0x00172430 in command_loop () at keyboard.c:1101
#47 0x00171658 in recursive_edit_1 () at keyboard.c:731
#48 0x0017194c in Frecursive_edit () at keyboard.c:793
#49 0x0016ef54 in main (argc=5, argv=0xbffff6e4) at emacs.c:1682
Lisp Backtrace:
"x-create-frame" (0xbfffda24)
"x-create-frame-with-faces" (0xbfffdda4)
"make-frame" (0xbfffe124)
"frame-initialize" (0xbfffe4a4)
"command-line" (0xbfffe824)
"normal-top-level" (0xbfffeb10)
--
Greetings
Pete
Sometimes I think the surest sign that intelligent life exists
elsewhere in the universe is that none of it has tried to contact us.
– Bill Watterson, in his comic strip Calvin and Hobbes
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-03 20:29 ` Peter Dyballa
@ 2011-02-04 15:30 ` Jan Djärv
2011-02-04 20:38 ` Peter Dyballa
2011-02-04 21:07 ` Peter Dyballa
0 siblings, 2 replies; 22+ messages in thread
From: Jan Djärv @ 2011-02-04 15:30 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
Peter Dyballa skrev 2011-02-03 21.29:
>
> Am 03.02.2011 um 14:47 schrieb Jan Djärv:
>
>> It turns out that XtCloseDisplay also calls XSync. I removed all XSync from
>> the error handler.
>
> During the first tries (with gdb and command line) something's seemed faulty:
> GNU Emacs did launch! Presumingly because I have two X resources:
>
> Emacs*pane.menubar.font: -linotype-optima-black-*-*-*-10-*-*-*-*-*-iso8859-1
> Emacs.pane.menubar.faceName: Libris ADF Std-9:style=Bold
>
> The latter one was the effective one, overriding the "-xrm
> '*pane.menubar.font: -linotype-optima-black-*-*-*-10-*-*-*-*-*-iso10646-1'".
> Removing this resource brings back the previous behaviour! Here are the lower
> 60 % of the *gud-emacs-...* buffer:
Is there anyplace I can get the X server you are using?
Jan D.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-04 15:30 ` Jan Djärv
@ 2011-02-04 20:38 ` Peter Dyballa
2011-02-04 21:07 ` Peter Dyballa
1 sibling, 0 replies; 22+ messages in thread
From: Peter Dyballa @ 2011-02-04 20:38 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 04.02.2011 um 16:30 schrieb Jan Djärv:
> Is there anyplace I can get the X server you are using?
Either MacPorts (first installation of some basic software for the
package manager, then a day-long sequence of download and compilation/
installation/activation and download and compilation/installation/
activation and ...), or you can get the whole package as a replacement
for the X server that Apple delivers (which has bug #7956).
Option #1: https://trac.macports.org/, a GUI: http://porticus.alittledrop.com/index.html
(GNU Emacs' compilation-mode + a *shell* buffer, both with super-
user privileges, are sufficient)
Option #2: http://xquartz.macosforge.org/trac/wiki, http://xquartz.macosforge.org/trac/wiki/X112.6.0
Recent version is XQuartz 2.6.0 (xorg-server 1.9.3). I don't know to
which X11R7.? release it belongs. It's mostly developed and debugged
by Jeremy Huddleston. A mailing list exists.
I am using Mac OS X 10.5.8, Leopard (without snow), on PPC based
hardware (7447A).
--
Greetings
Pete
If you're not confused, you're not paying attention.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-04 15:30 ` Jan Djärv
2011-02-04 20:38 ` Peter Dyballa
@ 2011-02-04 21:07 ` Peter Dyballa
2017-12-06 19:44 ` Glenn Morris
1 sibling, 1 reply; 22+ messages in thread
From: Peter Dyballa @ 2011-02-04 21:07 UTC (permalink / raw)
To: Jan Djärv; +Cc: 7949
Am 04.02.2011 um 16:30 schrieb Jan Djärv:
> Is there anyplace I can get the X server you are using?
I should add that the compile command to install the X server is:
(sudo) port install xorg-server
Before, you should run
(sudo) port selfupdate
that the latest packages are known. I prefer to install the "unstable"
X server (right now it seems that "stable" and "unstable" are the
same). To achieve this you'd need:
(sudo) port install xorg-server-devel
When you want some more documentation on the X server, you'd need:
(sudo) port install xorg-server-devel+docs or xorg-server-devel
@1.9.3_0+docs
(If you want to know which variants of a package exist: port variants
<package name>.)
--
Greetings
Pete
Ce qui a été compris n'existe plus.
(Paul Eluard)
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client
2011-02-04 21:07 ` Peter Dyballa
@ 2017-12-06 19:44 ` Glenn Morris
0 siblings, 0 replies; 22+ messages in thread
From: Glenn Morris @ 2017-12-06 19:44 UTC (permalink / raw)
To: Peter Dyballa; +Cc: 7949
Sorry, I can't see this issue ever making progress, so will close it.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2017-12-06 19:44 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-31 16:59 bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client Peter Dyballa
2011-01-31 22:07 ` Jan Djärv
2011-01-31 23:49 ` Peter Dyballa
2011-02-01 7:20 ` Jan Djärv
2011-02-01 10:53 ` Peter Dyballa
2011-02-01 17:23 ` Peter Dyballa
2011-02-01 18:02 ` Peter Dyballa
2011-02-02 10:28 ` Peter Dyballa
2011-02-02 19:36 ` Jan Djärv
2011-02-02 22:41 ` Peter Dyballa
2011-02-03 10:58 ` Peter Dyballa
2011-02-03 12:59 ` Jan Djärv
2011-02-03 14:25 ` Peter Dyballa
2011-02-03 13:47 ` Jan Djärv
2011-02-03 14:26 ` Peter Dyballa
2011-02-03 15:18 ` Peter Dyballa
2011-02-03 19:02 ` Jan Djärv
2011-02-03 20:29 ` Peter Dyballa
2011-02-04 15:30 ` Jan Djärv
2011-02-04 20:38 ` Peter Dyballa
2011-02-04 21:07 ` Peter Dyballa
2017-12-06 19:44 ` Glenn Morris
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).