xcb_writev: Segmentation fault

YuGiOhJCJ Mailing-List yugiohjcj-mailinglist at laposte.net
Thu Aug 31 14:54:44 UTC 2017


Hello,

I built libX11 1.6.5 32-bit on my 64-bit machine and I try to run a 32-bit application:
---
$ gdb 25Assist
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-slackware-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from 25Assist...(no debugging symbols found)...done.
(gdb) run
Starting program: /opt/25assist-20151223/25Assist 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
warning: File "/usr/lib/libstdc++.so.6.0.23-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /usr/lib/libstdc++.so.6.0.23-gdb.py
line to your configuration file "/home/yugiohjcj/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/yugiohjcj/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"

Program received signal SIGSEGV, Segmentation fault.
0xf6f1d6e1 in xcb_writev (c=0x82cbd50, vector=0xffff9e0c, count=3, requests=73) at xcb_out.c:405
405	    c->out.request += requests;
(gdb) bt
#0  0xf6f1d6e1 in xcb_writev (c=0x82cbd50, vector=0xffff9e0c, count=3, requests=73) at xcb_out.c:405
#1  0xf767f85e in _XSend (dpy=0x82cb400, data=0x0, size=0) at xcb_io.c:486
#2  0xf767fe19 in _XReply (dpy=0x82cb400, rep=0xffff9ec4, extra=0, discard=1) at xcb_io.c:573
#3  0xf767b943 in XSync (dpy=0x82cb400, discard=0) at Sync.c:44
#4  0xf7a537b2 in IA__gdk_flush () at gdkevents-x11.c:2606
#5  0xf7a23170 in alloc_scratch_image (image_info=<optimized out>) at gdkimage.c:527
#6  _gdk_image_get_scratch (screen=0x82da0b8, width=160, height=23, depth=24, x=0xffff9fbc, y=0xffff9fc0) at gdkimage.c:592
#7  0xf7a30fbe in gdk_draw_rgb_image_core (image_info=0x83f3bf8, drawable=drawable at entry=0x82c6c00, gc=gc at entry=0x82d8e80, x=0, y=0, width=160, height=23, 
    buf=0x840bc48 "\371\371\371nnn\022\022\022", pixstride=3, rowstride=480, conv=0xf7a2f0a0 <gdk_rgb_convert_0888>, cmap=0x0, xdith=0, ydith=0) at gdkrgb.c:3327
#8  0xf7a329e9 in IA__gdk_draw_rgb_image (drawable=0x82c6c00, gc=0x82d8e80, x=0, y=0, width=160, height=23, dith=GDK_RGB_DITHER_MAX, rgb_buf=0x840bc48 "\371\371\371nnn\022\022\022", 
    rowstride=480) at gdkrgb.c:3393
#9  0x0809d97e in ?? ()
#10 0x081124a0 in ?? ()
#11 0x081124d5 in ?? ()
#12 0xf6252292 in ?? ()
#13 0xf60cf138 in ?? ()
#14 0xf60cf3a3 in ?? ()
#15 0xf62d3f00 in ?? ()
#16 0xf62ceb8b in ?? ()
#17 0x0807077d in ?? ()
#18 0x08070888 in ?? ()
#19 0x08179267 in ?? ()
#20 0xf6100128 in ?? ()
#21 0x0816d65a in ?? ()
#22 0x0816d64e in ?? ()
#23 0x0816d75f in ?? ()
#24 0xf668681b in ?? ()
#25 0xf60b5308 in ?? ()
#26 0xf60b53b4 in ?? ()
#27 0xf6255333 in ?? ()
#28 0xf60b5469 in ?? ()
#29 0xf60b5024 in ?? ()
#30 0x080d2592 in ?? ()
#31 0x0816c1b1 in ?? ()
#32 0xf72be4d3 in __libc_start_main () from /lib/libc.so.6
#33 0x08052b21 in ?? ()
(gdb) quit
A debugging session is active.

	Inferior 1 [process 18645] will be killed.

Quit anyway? (y or n) y
---

As you can see I get a segmentation fault after the call to the xcb_writev function.
>From this program stack, I am unable to guess what could be the problem.
Maybe a communication problem between libX11 and libxcb but why?
I was able to run this application in the past so I think I did something wrong when I built my 32-bit libX11 this time.

Can you guess where the problem is from this backtrace?

Thank you.
Best regards.

Remark: I rebuilt gtk+2, libX11 and libxcb with the '-g' flag to have a nice backtrace so that's why you see the debugging symbols.

32-bit programs used:
atk-2.20.0
cairo-1.14.10
expat-2.1.0
fontconfig-2.12.1
freetype-2.6.3
gdk-pixbuf2-2.36.6
glib2-2.52.3
glibc-2.23
gtk+2-2.24.30
harfbuzz-1.2.7
icu4c-56.1
libdrm-2.4.80
libffi-3.2.1
libjpeg-turbo-1.5.0
libpciaccess-0.13.5
libpng-1.6.25
libtiff-4.0.6
libX11-1.6.5
libXau-1.0.8
libxcb-1.12
libXcomposite-0.4.4
libXcursor-1.1.14
libXdamage-1.1.4
libXext-1.3.3
libXfixes-5.0.3
libXft-2.3.2
libXi-1.7.9
libXinerama-1.1.3
libXrandr-1.5.1
libXrender-0.9.10
libxshmfence-1.2
libXxf86vm-1.1.4
llvm-3.9.0
mesa-17.0.4
ncurses-5.9
pango-1.40.6
pcre-8.39
pixman-0.34.0
util-linux-2.27.1
zlib-1.2.8


More information about the xorg mailing list