Jan Vroonhof <vroonhof(a)math.ethz.ch> writes:
[...]
See my comments below... on the suspect ioctls. I still think it
could be some symbolversioning problem. The main change glibc 2.1
made was in the FILE * structure. In this case the open() call is
done by the X libraries (which I assume were not recompiled with
glibc 2.1), but XEmacs is doing the F_SETSIG stuff which is only
supported if you opened the file with the new open.
No, my XFree86 and the other packages XEmacs depends on are compiled
with glibc2.1.
Or maybe it is something else altogether (it would be interesting to
find out if these two failing ioctl's (see below) are indeed the code
in request_sigio_on_device.
Yes, they happen in this function.
Maybe you can set a breakpoint on that function to see which
settings
XEmacs does?
The only interesting variable there is "struct device *d", which is
--------------------------------------
(gdb) p *d
$1 = {header = {lheader = {implementation = 0x82df1c0},
next = 0x84469f0, uid = 8726, free = 0}, devmeths = 0x83435a0,
name = 137776084, connection = 137775668, canon_connection = 137776036,
frame_list = 137512588, console = 138652128, selected_frame =
137512588, frame_with_focus_real = 137512588,
frame_with_focus_for_hooks = 137512588,
frame_that_ought_to_have_focus = 137512588, device_class =
137512588, user_defined_tags = 137512588, color_instance_cache =
138701616, font_instance_cache = 138701688, image_instance_cache =
138702104, device_data = 0x8446e58, buffers_changed = 0,
clip_changed = 0, extents_changed = 0, faces_changed = 0,
frame_changed = 0, glyphs_changed = 0, subwindows_changed = 0,
icon_changed = 0, menubar_changed = 0, modeline_changed = 0,
point_changed = 0, size_changed = 0, toolbar_changed = 0,
windows_changed = 0, windows_structure_changed = 0, locked = 0,
pixel_to_glyph_cache = {
valid = 0, frame = 0x0, low_x_coord = 0, high_x_coord = 0,
col = 0, obj_x = 0, low_y_coord = 0, high_y_coord = 0, row = 0,
obj_y = 0, w = 0x0, bufpos = 0, closest = 0, modeline_closest = 0,
obj1 = 137512588, obj2 = 137512588, retval = 0},
baud_rate = 38400, on_console_p = 0, connected_to_nas_p = 0,
infd = 11, outfd = 11, old_fcntl_owner = 0}
(gdb) p *(struct x_device *)d->device_data
$2 = {display = 0x83f0218, being_deleted = 0,
Xt_app_shell = 0x84a2e40, gc_cache = 0x0, visual = 0x838b8a0,
depth = 16, device_cmap = 33, gray_pixmap = 0,
Xatom_WM_PROTOCOLS = 0, Xatom_WM_DELETE_WINDOW = 0,
Xatom_WM_SAVE_YOURSELF = 0, Xatom_WM_TAKE_FOCUS = 0,
Xatom_WM_STATE = 0, Xatom_CLIPBOARD = 0, Xatom_TIMESTAMP = 0,
Xatom_TEXT = 0, Xatom_DELETE = 0, Xatom_MULTIPLE = 0,
Xatom_INCR = 0, Xatom_EMACS_TMP = 0, Xatom_TARGETS = 0,
Xatom_NULL = 0, Xatom_ATOM_PAIR = 0, Xatom_COMPOUND_TEXT = 0,
Xatom_FOUNDRY = 0, Xatom_FAMILY_NAME = 0, Xatom_WEIGHT_NAME = 0,
Xatom_SLANT = 0, Xatom_SETWIDTH_NAME = 0, Xatom_ADD_STYLE_NAME = 0,
Xatom_PIXEL_SIZE = 0, Xatom_POINT_SIZE = 0, Xatom_RESOLUTION_X = 0,
Xatom_RESOLUTION_Y = 0, Xatom_SPACING = 0, Xatom_AVERAGE_WIDTH = 0,
Xatom_CHARSET_REGISTRY = 0, Xatom_CHARSET_ENCODING = 0,
MetaMask = 64, HyperMask = 0, SuperMask = 32, AltMask = 8,
ModeMask = 0, lock_interpretation = 65509,
x_modifier_keymap = 0x8498050, x_keysym_map = 0x84b4f90,
x_keysym_map_min_code = 8, x_keysym_map_max_code = 134,
x_keysym_map_keysyms_per_code = 3,
x_keysym_map_hash_table = 139154824, WM_COMMAND_frame = 137512588,
mouse_timestamp = 0, global_mouse_timestamp = 0,
last_server_timestamp = 0, need_to_add_mask = 0, down_mask = 0,
last_downkey = 0 '\000', release_time = 0}
---------------------------------------
The backtrace of a (slightly modified) xemacs is:
(gdb) bt
#0 0x40403021 in __kill ()
#1 0x40402c6a in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x4040451b in abort () at ../sysdeps/generic/abort.c:88
#3 0x8088f35 in assert_failed (file=0x820af1e "sysdep.c", line=1021,
expr=0x820af60 "ioctl (filedesc, I_GETSIG, &events)!=-1")
at emacs.c:2649
#4 0x81745e4 in request_sigio_on_device (d=0x845c600) at sysdep.c:1021
#5 0x8174bca in init_one_device (d=0x845c600) at sysdep.c:1709
#6 0x817a3bc in x_init_device (d=0x845c600, props=137512588)
at device-x.c:726
#7 0x8076fe7 in Fmake_device (type=137614668, connection=137512588,
props=137512588) at device.c:581
#8 0x808f4ee in Ffuncall (nargs=3, args=0xbfffefcc) at eval.c:3189
#9 [...]
Then we can compare this with a glibc 2.0 build.
It would be interesting to know if all glibc2.1 build's are concerned,
or if it happens just under certain circumstances.
Here is your trace, annotated by me. I am learning by doing here so
please correct me if I am writing gibberish.
The X-signal-stuff is a closed book for me :) Do you know a good
documentation/manual which handles with it? About which Solaris
manpage are you speaking below?
[...]
fcntl(11, F_GETOWN) = 0
getpid() = 2285
fcntl(11, F_SETOWN, 2285) = 0
ioctl(11, 0x7, 0xbfffef38) = -1 EINVAL (Invalid argument)
ioctl(11, 0x6, 0x4) = -1 EINVAL (Invalid argument)
This seems suspect to me.... It does look suspiciously like
ioctl (filedesc, I_GETSIG, &events);
ioctl (filedesc, I_SETSIG, events | S_INPUT);
from sysdep.c
That's right.
(The solaris manpage says this what you need to do
there to get a signal on input). Could you grep the glibc2.1 include
files to compare the definition of I_GETSIG, I_SETSIG, S_INPUT with
0x7, 0x6, and 0x4 ?
Yes, the I_xxx #define's have the values above.
If you are interested in a precompiled device-x.c and sysdep.c, you
can find them at
http://www.tu-chemnitz.de/~ensc/xemacs/ .
Enrico
--
eMail: enrico.scholz(a)wirtschaft.tu-chemnitz.de
talk: ensc(a)ultra.csn.tu-chemnitz.de