[comp.windows.x] X10 on a color sun

eirik@tekcrl.TEK.COM (Eirik Fuller) (09/08/88)

We're having a problem with the X10 server on a color Sun 3.
Something is corrupting the memory pool, which causes a segment
violation in malloc().  If I rearrange some things, the symptoms
change (free() complains instead), but the basic problem remains.

The operations performed by the server before malloc() trips are
primarily with Pixmaps, but it's unclear whether there is anything
unusual about them.  There are also a few calls to some font
routines, and not a whole lot else.

The same server running on a monochrome Sun 3 has never had the same
problem, with the identical client connected to it.

Has anyone else seen (or, preferably, fixed) bugs in this server
relating to a corrupted memory pool?  If this is an old topic, please
excuse my ignorance; I don't follow comp.windows.x carefully.  If you
want to tell me why I should use X11 instead, feel free; I'll be
happy to ignore it.  If you have any useful information about how to
deal with this problem (fixes to the server, or things to avoid in
the client), I'd like to hear from you.  Email, please; if there is
anything useful to summarize, I'll do so.

eirik%crl.tek.com@relay.cs.net

eirik@tekcrl.TEK.COM (Eirik Fuller) (10/07/88)

A while back I posted a request for information about memory
corruption on the Sun X10 server running on a color display.
We found the problem just before the project that depended on it was
cancelled :-(.  One of the respondents to my original posting also
told us about the cure the very next day (such timing).  For pixmaps of
odd width, there should be an extra byte of padding on an eight bit
deep display, but the server code failed to take that into account.

The fix I did, that cured our particular problem, was to replace the
calls in libsun/bitpix.c to the macro BZPixmapSize() with calls to a
minor variation, which I called ABZPixmapSize() :

#define ABZPixmapSize(width, height) (((width) + ((width)%2)) * (height))


A couple of the responses also indicated that there were probably
bugs in the font code as well, but just the above fix was enough to
get us past our immediate problem.  Thanks to all who responded.