Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this wiki page for instructions on how to get full permissions. Sorry for the inconvenience.
Admin message
Equinix is shutting down its operations with us on April 30, 2025. They have gracefully supported us for almost 5 years, but all good things come to an end.
Given the time frame, it's going to be hard to make a smooth transition of the cluster to somewhere else (TBD). Please expect in the next months some hiccups in the service and probably at least a full week of downtime to transfer gitlab to a different place.
FreeDesktop Bugzilla Database Corruption Fix User said:
RECORD extension generates X protocol violation.
This is the bug of RECORD's reply buffer management algorithm.
RecordAProtocolElement (...) /* xc/programs/Xserver/record/record.c /
{
:
if (futurelen >= 0)
{ / start of new protocol element /
:
if (!pContext->numBufBytes) / reply buffer is empty /
{
create reply packet header
}
:
/ adjust reply length in reply buffer /
:
} / end if not continued reply */
/* if space available >= space needed, buffer the data */if (REPLY_BUF_SIZE - pContext->numBufBytes >= datalen +
o RECORD's reply packet header is created if o recording a new protocol element (not a continued one) and o reply buffer is emptyo recording element (both new one and continued one) is buffered if space available
consider this scenario;
step1: RECORD's reply buffer is empty.step2: X server calls WriteToClient() to send a part of reply (names "A1")step3: RecordAProtocolElement is called. it creates reply packet header in RECORD's reply buffer because the buffer is empty. then buffer "A1" with protocol element header.step4: X server calls WriteToClient() to send continued part of the same reply (names "A2")step5: RecordAProtocolElement is called again. reply buffer space is not enough to store "A2". so flush reply buffer (i.e. "A1") and send "A2". ("A2" is not buffered). now reply buffer is empty.step6: X server calls WriteToClient() to send the rest of the same reply (names "A3")step7: RecordAProtocolElement is called again. buffers "A3" really top of the reply buffer. no packet header is created because this reply is continued
one.
step8: X server calls WriteToClient() to send NEW reply (names "B")
step9: RecordAProtocolElement is called again. append "B" to reply buffer with protocol element because this is a new reply. but reply packet header is not created because reply buffer is not empty.......
So, recording client will receive protocol violated stream like below.
[reply packet header]-[protocol element header]-[A1]-[A2]-[A3]-[protocol element header]-[B].
of course, expected stream is;
[reply packet header]-[protocol element header]-[A1]-[A2]-[A3]-[reply packet header]-[protocol element header]-[B].
my solution is simple; not buffer continued reply if reply buffer is empty.