xrandr not linked to libfakexrandr
Closed this issue · 6 comments
After make and make install. ldd xrandr still loads libxrandr shared system library. No complaints from configure. OS: Gnome Ubuntu 14.04
What's the exact output of configure? What's the content of /etc/ld.so.conf and all files in /etc/ld.so.conf.d? Does make install place the new libXrandr.so file to /usr/local/lib (presumably, that's what it uses here with Mint) and are you certain that ldd shows you the original system library and not the fake one (which would also be named libXrandr.so, but be in a different directory)?
./configure:
The path to the real XRandR library is
/usr/lib/x86_64-linux-gnu/libXrandr.so.2
The fake library will be installed to /usr/local/lib
ld.so.conf loads:
/usr/local/lib
make install:
places libXrandr.so in /usr/local/lib
ldd xrandr:
linux-vdso.so.1 => (0x00007ffc4e4bd000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2
(0x00007f0ed2fdb000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f0ed2ca6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0ed29a0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0ed25db000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f0ed23c9000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
(0x00007f0ed21bf000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f0ed1fa0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0ed1d9c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0ed31e5000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f0ed1b98000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007f0ed1992000)
ldconfig -p | grep -i xrand
libXrandr.so.2 (libc6,x86-64) => /usr/local/lib/libXrandr.so.2
libXrandr.so.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libXrandr.so.2
libXrandr.so (libc6,x86-64) => /usr/local/lib/libXrandr.so
libXrandr.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libXrandr.so
So it is loaded into ld.so.cache but doesn't seem to be loaded by xrandr.
Anyway my display crashes before launching if I have a
.config/fakexrandr... file.
On Thu, Nov 12, 2015 at 5:26 AM, Phillip Berndt notifications@github.com
wrote:
What's the exact output of configure? What's the content of
/etc/ld.so.conf and all files in /etc/ld.so.conf.d? Does make install
place the new libXrandr.so file to /usr/local/lib (presumably, that's
what it uses here with Mint) and are you certain that ldd shows you the
original system library and not the fake one (which would also be named
libXrandr.so, but be in a different directory)?—
Reply to this email directly or view it on GitHub
#24 (comment)
.
That is a pretty weird behaviour for ld.so.
Anyway my display crashes before launching if I have a .config/fakexrandr... file.
At least, that clearly means that at least something there is using the library. This issue seems more important than the xrandr one now. Try compiling with make CFLAGS=-g and start the X11 session with core dumps enabled (ulimit -c unlimited). This should create a core file after the crash. Run gdb <the actual program that crashed> core to start the gdb debugger and there type bt to produce a backtrace. That'll hopefully reveal what is going wrong.
Hi Phillip (Phil?),
Sorry for the slow reply, I am writing a massive grant proposal due
Thursday so I'll be a bit slow to respond before then. Here is the output
you requested (without the .config/fakexrandr.bin file startx starts X with
no errors):
root@primary:# gdb /usr/lib/ibus/ibus-x11 fcore14.04.2) 7.7.1
GNU gdb (Ubuntu 7.7.1-0ubuntu5
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
Reading symbols from /usr/lib/ibus/ibus-x11...(no debugging symbols
found)...done.
[New LWP 6605]
[New LWP 6618]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/ibus/ibus-x11 --kill-daemon'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f4676e8e1d8 in config_handle_output (dpy=0xfcf0f0,
resources=0x10631d0, output=83, target_edid=0x7fffe853e9b0 "00", 'f'
<repeats 12 times>,
"005a6324d8010101011d15010380341d782eeed5a555489b26125054bfef80b300a940950f950081808140714f0101023a801871382d40582c450009252100001e000000ff005250583131323932303039370a000000fd00324b185211"...,
fake_crtcs=0x7fffe853e960, fake_outputs=0x7fffe853e958,
fake_modes=0x7fffe853e968) at libXrandr.c:202
202 if(output_crtc->width == (int)width && output_crtc->height ==
(int)height) {
(gdb) bt
#0 0x00007f4676e8e1d8 in config_handle_output (dpy=0xfcf0f0,
resources=0x10631d0, output=83, target_edid=0x7fffe853e9b0 "00", 'f'
<repeats 12 times>,
"005a6324d8010101011d15010380341d782eeed5a555489b26125054bfef80b300a940950f950081808140714f0101023a801871382d40582c450009252100001e000000ff005250583131323932303039370a000000fd00324b185211"...,
fake_crtcs=0x7fffe853e960, fake_outputs=0x7fffe853e958,
fake_modes=0x7fffe853e968) at libXrandr.c:202
#1 0x00007f4676e8e927 in augment_resources (dpy=0xfcf0f0, res=0x10631d0)
at libXrandr.c:357
#2 0x00007f4676e8f5dc in XRRGetScreenResourcesCurrent (dpy=0xfcf0f0,
window=740) at libXrandr.c:456
#3 0x00007f4679cd9e8d in ?? () from
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#4 0x00007f4679cdae0d in ?? () from
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#5 0x00007f4679ccfc3c in ?? () from
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#6 0x00007f4679cd0366 in ?? () from
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#7 0x00007f4679cd040e in ?? () from
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#8 0x00007f4679766e04 in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x00007f4679767048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007f467976730a in g_main_loop_run () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007f467a055447 in gtk_main () from
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#12 0x00000000004028e6 in ?? ()
#13 0x00007f467915cec5 in __libc_start_main (main=0x402420, argc=2,
argv=0x7fffe853f498, init=, fini=,
rtld_fini=, stack_end=0x7fffe853f488) at libc-start.c:287
#14 0x0000000000402a0c in ?? ()
Also, maybe this helps?
(gdb) print _dpy
$1 = {ext_data = 0x0, free_funcs = 0xfba5d0, fd = 3, conn_checker = 0,
proto_major_version = 11, proto_minor_version = 0, vendor = 0xfcdfe0 "The
X.Org Foundation", resource_base = 10485760, resource_mask = 2097151,
resource_id = 0, resource_shift = 0, resource_alloc = 0x7f467a5a3280
<_XAllocID>, byte_order = 0, bitmap_unit = 32, bitmap_pad = 32,
bitmap_bit_order = 0, nformats = 7, pixmap_format = 0xfba620, vnumber = 11,
release = 11501000, head = 0xff2eb0, tail = 0xff2b30, qlen = 7,
last_request_read = 204, request = 204, last_req = 0x7f467a89b6e0 "",
buffer = 0xfd6d40 "\214\024\003", bufptr = 0xfd6d40 "\214\024\003", bufmax
= 0xfdad40 "", max_request_size = 65535, db = 0x10154b0, synchandler = 0x0,
display_name = 0xfb4220 ":0", default_screen = 0, nscreens = 1, screens =
0xfba6d0, motion_buffer = 256, flags = 128, min_keycode = 8,
max_keycode = 255, keysyms = 0x0, modifiermap = 0x0, keysyms_per_keycode
= 0, xdefaults = 0xfb8330 "_customization:\t-color\n", scratch_buffer =
0x0, scratch_length = 0, ext_number = 12, ext_procs = 0x1014d30, event_vec
= {0x7f467a5a4cd0 <_XUnknownWireEvent>, 0x7f467a5a4cd0
<_XUnknownWireEvent>, 0x7f467a5a4d10 <_XWireToEvent> <repeats 33 times>,
0x7f4676465400, 0x7f467a5a4cd0 <_XUnknownWireEvent> <repeats 28 times>,
0x7f4676460060, 0x7f4676460f10, 0x7f4676c82930 <repeats 17 times>,
0x7f4676462600, 0x7f4676462600, 0x7f467a5f65d0, 0x7f467a5a4cd0
<_XUnknownWireEvent>, 0x7f46783915c0, 0x7f46783915c0, 0x7f4673b78e80,
0x7f4673b78e80, 0x7f467666c090, 0x7f467a5a4cd0 <_XUnknownWireEvent>
<repeats 36 times>}, wire_vec = {0x7f467a5a4d00 <_XUnknownNativeEvent>,
0x7f467a5a4d00 <_XUnknownNativeEvent>, 0x0 <repeats 33 times>,
0x7f4676465370,
0x7f467a5a4d00 <_XUnknownNativeEvent> <repeats 28 times>,
0x7f467645ffb0, 0x7f4676460fe0, 0x7f4676c7e560 <repeats 17 times>,
0x7f4676462cc0, 0x7f4676462cc0, 0x7f467a5a4d00 <_XUnknownNativeEvent>,
0x7f467a5a4d00 <_XUnknownNativeEvent>, 0x7f46783914f0, 0x7f46783914f0,
0x7f4673b78c90, 0x7f4673b78c90, 0x7f467666bfc0, 0x7f467a5a4d00
<_XUnknownNativeEvent> <repeats 36 times>}, lock_meaning = 0, lock = 0x0,
async_handlers = 0x0, bigreq_size = 4194303, lock_fns = 0x0, idlist_alloc
= 0x7f467a5a32d0 <_XAllocIDs>, key_bindings = 0x0, cursor_font = 0, atoms =
0xfded10, mode_switch = 0, num_lock = 0, context_db = 0x0, error_vec = 0x0,
cms = {defaultCCCs = 0x0, clientCmaps = 0x0, perVisualIntensityMaps = 0x0},
im_filters = 0xfe02d0, qfree = 0xff2a50, next_event_serial_num = 83,
flushes = 0x0, im_fd_info = 0x0, im_fd_length = 0,
conn_watchers = 0xfde250, watcher_count = 1, filedes = 0xfb80c0 "\003",
savedsynchandler = 0x0, resource_max = 2097146, xcmisc_opcode = 0, xkb_info
= 0xfde3d0, trans_conn = 0x0, xcb = 0xfb8050, next_cookie = 0,
generic_event_vec = {0x0, 0x0, 0x0, 0x7f4676c839b0, 0x0 <repeats 124
times>}, generic_event_copy_vec = {0x0, 0x0, 0x0, 0x7f4676c81f10, 0x0
<repeats 124 times>}, cookiejar = 0x0}
(gdb) print *resources
$2 = {timestamp = 46916400, configTimestamp = 46916400, ncrtc = 2, crtcs =
0x1063210, noutput = 3, outputs = 0x1063220, nmode = 53, modes = 0x1063238}
On Thu, Nov 12, 2015 at 11:26 AM, Phillip Berndt notifications@github.com
wrote:
That is a pretty weird behaviour for ld.so.
Anyway my display crashes before launching if I have a
.config/fakexrandr... file.At least, that clearly means that at least something there is using the
library. This issue seems more important than the xrandr one now. Try
compiling with make CFLAGS=-g and start the X11 session with core dumps
enabled (ulimit -c unlimited). This should create a core file after the
crash. Run gdb core to start the gdb
debugger and there type bt to produce a backtrace. That'll hopefully
reveal what is going wrong.—
Reply to this email directly or view it on GitHub
#24 (comment)
.
Take your time, you're the only one complaining about this right now, so there's no need to hurry from my side 😄 I've made a commit that might help mitigate the crash. Could you test it, please?
Beautiful!!! That seems to have fixed the issue I was having. I really
appreciate your effort. If I had more time I might have tried to track this
down myself but things are crazy right now. I see this being an extremely
useful tool and will highly recommend it. One giant 4k TV is already
cheaper, more functional and easier to install than a bank of 4 monitors
1/4 sized monitors...especially when you have to double their cost to pay
facilities management to install them :D
On Sat, Nov 14, 2015 at 8:57 AM, Phillip Berndt notifications@github.com
wrote:
Take your time, you're the only one complaining about this right now, so
there's no need to hurry from my side [image: 😄] I've made a commit
that might help mitigate the crash. Could you test it, please?—
Reply to this email directly or view it on GitHub
#24 (comment)
.