https://bugs.kde.org/show_bug.cgi?id=466884
--- Comment #3 from Matthew Fennell <matthew.robert.fennell+bugzi...@gmail.com>
---
(In reply to Paul Floyd from comment #1)
> Can you find the source in xcb that is causing this?
I'll do my best :) To be honest - I'm not at all familiar with how these
libraries interact, so forgive me if this description is not very good. But,
here goes:
I made a more minimal example that does not require openscenegraph. Here is the
backtrace of the bug:
#0 __GI___writev (fd=3, iov=0x7fffffffdbf0, iovcnt=3) at
../sysdeps/unix/sysv/linux/writev.c:26
#1 0x00007ffff7c38fb9 in write_vec (count=0x7fffffffdb8c,
vector=0x7fffffffdb90, c=0x55555555c430) at ../../src/xcb_conn.c:277
#2 _xcb_conn_wait (c=c@entry=0x55555555c430, cond=cond@entry=0x55555555d560,
vector=vector@entry=0x7fffffffdb90, count=count@entry=0x7fffffffdb8c) at
../../src/xcb_conn.c:523
#3 0x00007ffff7c39381 in _xcb_out_send (count=<optimized out>,
vector=<optimized out>, c=0x55555555c430) at ../../src/xcb_out.c:464
#4 xcb_writev (c=c@entry=0x55555555c430, vector=vector@entry=0x7fffffffdbf0,
count=-9332, count@entry=3, requests=requests@entry=8) at
../../src/xcb_out.c:412
#5 0x00007ffff7ea3eae in _XSend (dpy=0x555555559d80, data=0x7fffffffdc20
"8\004", data@entry=0x0, size=size@entry=0) at ../../src/xcb_io.c:578
#6 0x00007ffff7ea447c in _XReply (dpy=dpy@entry=0x555555559d80,
rep=rep@entry=0x7fffffffdcf0, extra=extra@entry=0, discard=discard@entry=1) at
../../src/xcb_io.c:670
#7 0x00007ffff7e8eac4 in XInternAtom (dpy=0x555555559d80, name=0x55555555603f
"_MOTIF_WM_HINTS", onlyIfExists=0) at ../../src/IntAtom.c:182
#8 0x00005555555555cb in main () at
/home/matthew/Documents/libre-racing/dependencies/bug-reports/x11-uninitialised-variable-usage/example.cpp:70
Frame 8:
The bug is triggered by a call to XInternAtom(display, "_MOTIF_WM_HINTS", 0);
This call on its own does not cause any reports - it relies on the previous
lines.
Frame 7 (libX11):
libX11 has a Display struct which contains a char * dpy->buffer. It also has
another char * dpy->bufptr, which starts set to the same position as
dpy->buffer, but expands and shrinks throughout the lifetime of the program.
In the call to XInternAtom, libX11 passes dpy to xcb.
Frame 5 (xcb):
xcb creates the struct iovec * like so:
vec[0].iov_base = dpy->buffer
vec[0].iov_len = dpy->bufptr - dpy->buffer
There is also vec[1], and vec[2], but they both have iov_len values of 0.
At this point:
dpy->buffer: "\001\030\f"
dpy->bufptr: ""
dpy->bufptr - dpy->buffer = 296
Frames #4-0:
This iovec * is passed down to the writev call without modification.
Then, on the writev call, valgrind reports:
==21464== Syscall param writev(vector[...]) points to uninitialised byte(s)
==21464== at 0x4AD770D: __writev (writev.c:26)
==21464== by 0x4AD770D: writev (writev.c:24)
==21464== by 0x4BC6FB8: write_vec (xcb_conn.c:277)
==21464== by 0x4BC6FB8: _xcb_conn_wait (xcb_conn.c:523)
==21464== by 0x4BC7380: _xcb_out_send (xcb_out.c:464)
==21464== by 0x4BC7380: xcb_writev (xcb_out.c:412)
==21464== by 0x48B1EAD: _XSend (xcb_io.c:578)
==21464== by 0x48B247B: _XReply (xcb_io.c:670)
==21464== by 0x489CAC3: XInternAtom (IntAtom.c:182)
==21464== by 0x1095CA: main (example.cpp:70)
==21464== Address 0x4ee5738 is 264 bytes inside a block of size 16,384 alloc'd
==21464== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==21464== by 0x48A1D79: XOpenDisplay (OpenDis.c:240)
==21464== by 0x10920B: main (example.cpp:5)
==21464== Uninitialised value was created by a stack allocation
==21464== at 0x109207: main (example.cpp:5)
==21464==
{
<insert_a_suppression_name_here>
Memcheck:Param
writev(vector[...])
fun:__writev
fun:writev
fun:write_vec
fun:_xcb_conn_wait
fun:_xcb_out_send
fun:xcb_writev
fun:_XSend
fun:_XReply
fun:XInternAtom
fun:main
}
I believe the error is ultimately caused by 296 (iov_len = dpy->bufptr -
dpy->buffer) > 264 (amount of initialised memory in dpy->buffer).
However, unfortunately, I don't know enough about X11 to understand why this is
happening, or if it's expected. Nevertheless, I hope this helps a little.
Let me know if you'd like me to do more research or there's some other info
that would help. I initially reported here since I noticed the almost identical
suppressions, but I'm certainly open to the suggestion that this is a real bug
in X. I just don't know enough to know how to tell for sure :)
--
You are receiving this mail because:
You are watching all bug changes.
