3:34 p.m.
21.5.b27, on fedora fc6 x86_64 built with xft.
Works OK normally, but when I tried to fire it up through an nx terminal server:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496323568 (LWP 19991)]
0x0000000000598817 in x_wm_set_cell_size ()
(gdb) where
#0 0x0000000000598817 in x_wm_set_cell_size ()
#1 0x00000000004ba980 in update_frame_face_values ()
#2 0x00000000005995d6 in x_frame_window_state ()
#3 0x00000000004dc7a8 in Fmake_frame ()
#4 0x000000000048e3d8 in Ffuncall ()
#5 0x000000000045fada in execute_optimized_program ()
#6 0x000000000048e127 in Ffuncall ()
#7 0x000000000045fada in execute_optimized_program ()
#8 0x000000000048d4ce in Feval ()
#9 0x0000000000490748 in condition_case_1 ()
#10 0x000000000045f1ba in execute_rare_opcode ()
#11 0x00000000004603ff in execute_optimized_program ()
#12 0x000000000048d4ce in Feval ()
#13 0x0000000000490748 in condition_case_1 ()
#14 0x000000000046a970 in initial_command_loop ()
#15 0x000000000048ca20 in internal_catch ()
#16 0x000000000046a8b3 in initial_command_loop ()
#17 0x0000000000488533 in xemacs_21_5_b27_x86_64_redhat_linux ()
#18 0x0000000000489120 in main ()
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:45 a.m.
Neal Becker writes:
21.5.b27, on fedora fc6 x86_64 built with xft.
Works OK normally, but when I tried to fire it up through an nx
terminal server:
And what, pray tell, is an "nx terminal server"? Specifically, do you
have any idea why it would confuse XEmacs?
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46912496323568 (LWP 19991)]
0x0000000000598817 in x_wm_set_cell_size ()
(gdb) where
#0 0x0000000000598817 in x_wm_set_cell_size ()
strip should be put up against a wall and shot as aiding and abetting
the escape from justice of more known critical bugs than any other
denizen of the underworld of software.
Maybe you have the core and symbol table and can load them and get a
backtrace that allows us to figure out what arguments these functions
are getting called here? I forget the details and need to do some
RealWork RealSoon, but if you ask gdb for help on files it will
tellyou how to do that if the data is available.
(Somebody who's done this with the RH debug package, couldja write it
up for FAQ or PROBLEMS, starting from "rpm -i xemacs-debug"?)
What is probably happening here is that the default font is "weird"
and somehow a cell dimension (or pointer to it) is zero. Several
developers (Mike and Aidan come to mind) have been busily papering
over these bugs at the crash sites, but nobody yet knows how the
out-of-range values get accessed in the first place....
We can probably fix this by analysis of x_wm_set_cell_size, but you
should expect more crashes like this. You really really do not want
to use a stripped build of 21.5. (There is no cost to using an
unstripped debug build on Linux except +5MB or so of symbol table on
disk; performance and VM footprint are affected by < 1%.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:41 p.m.
On Thursday 15 March 2007, Stephen J. Turnbull wrote:
(Somebody who's done this with the RH debug package, couldja
write it
up for FAQ or PROBLEMS, starting from "rpm -i xemacs-debug"?)
Practically *all* packages shipped in Fedora [0] have had their debug symbols
stripped into a corresponding -debuginfo package. If not, it's almost
certainly a bug. The instructions for getting sane stack traces are at
http://fedoraproject.org/wiki/StackTraces
Adding info about it in the xemacs package makes no sense, because it is prone
to bitrot as these things are not controlled within the xemacs package
itself. It also depends on the system rpmbuild config if someone decides to
rebuild some of the source rpms locally.
[0] The original report did not mention whether this had anything to do with
any packaged version of XEmacs, it just said it was 21.5.b27 on FC6 x86_64.
The xemacs package shipped in Fedora is not built with Xft, but it has a
build time "--with xft" rpmbuild option for those who want to experiment with
a packaged Xft-enabled XEmacs. I *guess* this is what the OP did, with a
rpmbuild config that strips debug symbols into -debuginfo packages.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:43 p.m.
On Thursday 15 March 2007, Stephen J. Turnbull wrote:
Neal Becker writes:
> 21.5.b27, on fedora fc6 x86_64 built with xft.
>
> Works OK normally, but when I tried to fire it up through an nx
> terminal server:
And what, pray tell, is an "nx terminal server"? Specifically, do you
have any idea why it would confuse XEmacs?
It's a virtual X server. I didn't find the real problem, but I did fix it.
The problem was that the server couldn't find it's rgb.txt, so no colors
could be found by name.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6462
days inactive
6463
days old
3 comments
3 participants
participants (3)
-
Neal Becker -
Stephen J. Turnbull -
Ville Skyttä