summaryrefslogtreecommitdiff
path: root/src/libvmon/list.h
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2017-03-27 22:37:21 -0700
committerVito Caputo <vcaputo@pengaru.com>2017-03-27 22:37:21 -0700
commit221587a31b4ffe42a6f4d0b0f817e2a2cedcfb45 (patch)
treebfbe4abcba1abaf1609a19d9c73fc42dd466a00b /src/libvmon/list.h
parent54faa24df5f5c6c260d4d55075736b04d494cdc6 (diff)
charts: reduce CHART_MAX_ARGC from 512 to 64
`make tags` in the linux kernel revealed that XDrawText can return a BadLength error, which is not mentioned in the man page. Glancing at the xorg-server source for doPolyText() this is found: 1192 else { /* print a string */ 1193 1194 unsigned char *pNextElt; 1195 1196 pNextElt = c->pElt + TextEltHeader + (*c->pElt) * itemSize; 1197 if (pNextElt > c->endReq) { 1198 err = BadLength; 1199 goto bail; 1200 } So there appears to bea fairly arbitrary ceiling on how many items one can pass to XDrawText, and it probably depends on the cumulative length of the individual items overflowing the maximum request length. Well.. that's lame, and shrinking the maximum items makes it less likely to trip over this in practice, but it probably just takes a long enough individual item to trigger it again. I had erred on the side of "excessively long" assuming XDrawText would just deal and clip the text to the bounds of the destination drawable, just in case there was an argv with lots of tiny items, then that would be covered. This approach is incompatible with the potential for BadLength errors, so drastically shrinking the maximum number of items until further notice.
Diffstat (limited to 'src/libvmon/list.h')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved