> I hope nobody has been putting many brain cycles into the PCB > rendering slowness I mentioned a little while back. [...]
> [...] if I [...], then the machine crashes. I now know what's going on here, and yes, it has nothing to do with PCB - well, except that PCB happened to tickle it. It's a bug in the X server, collaborating with something only partially characterized at the OS level. When the X server is asked to draw a line that (a) is unusually long in the vertical direction (two or three thousand pixels is enough in my case - this is independent of how many pixels high the display is), (b) is wide, (c) is neither horizontal nor vertical, and (d) is clipped by a shape more complex than a simple rectangle, then the code path taken involves allocating some arrays on the stack, arrays whose size is linear in the (pre-clipping) Y dimension of the line. The server runs out of stack and crashes; when the OS tries to dump its core, something goes wrong that wedges the machine - I suspect this is related to its having the framebuffer memory-mapped, and probably the particular framebuffer in use. Certainly setting the coredumpsize limit for the X server process to zero makes the machine stop wedging, just taking down the X server instead. I am mildly curious how widespread the bug is. If anyone has a suitable crash-and-burn machine and would care to try it, the source to my test program is on ftp.rodents.montreal.qc.ca:/mouse/misc/crash-X.c (needs gcc to compile; link with -lXext -lX11 -lm). /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
