bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
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       (:
         _    / __    -    -
       _/ \__/_/        -     -
      (´`)      (´`)   -    -
       `´        `´




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Jan D.-2
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 (:
> _ / __ - -
> _/ \__/_/ - -
> (´`) (´`) - -
> `´ `´
>
>
>



Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2

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




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Jan D.-2
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.



Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2

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!




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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)




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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ɓ ʇɐɥʍ«




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Jan D.-2


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.



Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2

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.




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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.




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Jan D.-2
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.



Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Jan D.-2
In reply to this post by Peter Dyballa-2
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.



Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Jan D.-2


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.



Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2
In reply to this post by Jan D.-2

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




Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Jan D.-2


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.



Reply | Threaded
Open this post in threaded view
|

bug#7949: 24.0.50; GNU Emacs with Xaw3d does not launch as X client

Peter Dyballa-2

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.




12