Looking at the code around line 181 in ClientChannel.C where the
crash happened, seems to me that format should have one of the
values 8, 32 and maybe 16. Re-writing the code to explicitly test
for format==16 so:
--- ClientChannel.C-prePSz 2007-02-03 01:25:48.000000000 +1100
+++ ClientChannel.C 2014-10-13 07:23:24.000000000 +1100
@@ -171,19 +171,23 @@
clientCache_.
changePropertyData32Cache);
nextSrc += 4;
}
}
- else
+ else if (format == 16)
{
for (unsigned int i = 0; i < dataLength; i++)
{
encodeBuffer.encodeValue(GetUINT(nextSrc,
bigEndian_), 16);
nextSrc += 2;
}
}
+ else
+ {
+ CERR << "PSz debug: weird format " << ( (unsigned
int)format ) << ENDL;
+ }
}
break;
case X_ChangeWindowAttributes:
{
encodeBuffer.encodeValue((size - 12) >> 2, 4);
then building, dxpc works fine for xterm, Matlab or LibreOffice;
but running texworks I got (an infinite? stream) of
PSz debug: weird format 6
lines.
I do not quite understand X protocol and do not know how to handle
the format==6 case: cannot be "lumped in" with the format==8 case,
as changing the line
- if (format == 8)
+ if ((format > 0) && (format <= 8))
seems to cause dxpc to "run away" with 100%CPU.
Can someone help please?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
