Bug in PEX server code?
Kevyn Ford soft
reference, I've tried the same program on these two platforms:
PC/Linux Sparcstation2/SunOS 4.1.x
X11R6/Motif 2.0/X3D-PEX X11R5/Motif 1.2/X3D-PEX
XFree86 3.1.1/3.1.2 ??
gcc 2.6.3 gcc 2.6.3
Essentially, I have a small test application (one of the PHIGS examples) that
draws a sphere. For a small number of vertices (~600) it works fine, for a
larger number of vertices (~20,000) the program crashes the server as it is
in the process of rendering the sphere (you can see it die in the middle).
Further investigation seems to indicate that a SMALLER sphere with 20,000
vertices works and a LARGER sphere with 600 vertices also works - I started to
wonder if the problem dealt with clipping.
Using gdb, the stack at the time of the segment violation indicated:
end
??
Xalloc <-- (via #define macro)
miClipPolyLines
miPolyLines
traverser
miTraverse
RedrawStructures
which further pointed to a memory allocation problem, which I find hard to
believe because my PC has 20M of RAM and 100M of swap.
I am definitely out of my league when it comes to debugging X server code, but
methinks I can rule out a problem with the PHIGS API; but I also find it hard
to believe that with all the people using PEXlib applications that noone else
has seen this kind of behaviour (I've been looking at the available X11R6
fixes but haven't seen anything related to-date) - can anyone more
knowledgeable shed some light on what could be going on?
--
-------------------------------------------------------------------------------
Kevyn B. Ford Eastman Kodak Company Voice : (716)253-0149
Software Engineer 901 Elmgrove Road Email : ke...@kodak.com
Rochester, NY 14653-5810 k...@raster.kodak.com
Karl Schultz
> I have a problem with PEX/PHIGS applications that crash my X server; as a
> reference, I've tried the same program on these two platforms:
>
> PC/Linux Sparcstation2/SunOS 4.1.x
> X11R6/Motif 2.0/X3D-PEX X11R5/Motif 1.2/X3D-PEX
> XFree86 3.1.1/3.1.2 ??
> gcc 2.6.3 gcc 2.6.3
Does it fail on both these platforms? You don't really say.
Are you using Sun's PEX server on the Sun, or did you build X/PEX on it from the
Consortium distribution? If you can, try using Sun's product PEX server.
> Essentially, I have a small test application (one of the PHIGS examples) that
> draws a sphere. For a small number of vertices (~600) it works fine, for a
> larger number of vertices (~20,000) the program crashes the server as it is
> in the process of rendering the sphere (you can see it die in the middle).
Be careful with a large number of vertices, so that you don't go over
the 65K word limit per request/primitive. But that is not the problem
here, as the next paragraph shows.
> Further investigation seems to indicate that a SMALLER sphere with 20,000
> vertices works and a LARGER sphere with 600 vertices also works - I started to
> wonder if the problem dealt with clipping.
Does it die only when the lines are clipped?
>
> Using gdb, the stack at the time of the segment violation indicated:
>
> end
> ??
> Xalloc <-- (via #define macro)
> miClipPolyLines
> miPolyLines
> traverser
> miTraverse
> RedrawStructures
>
> which further pointed to a memory allocation problem, which I find hard to
> believe because my PC has 20M of RAM and 100M of swap.
If there was an errant memory write in the stack/malloc area, Xalloc (malloc)
might fail, independent of the amount of storage in the system.
> I am definitely out of my league when it comes to debugging X server code, but
> methinks I can rule out a problem with the PHIGS API; but I also find it hard
> to believe that with all the people using PEXlib applications that noone else
> has seen this kind of behaviour (I've been looking at the available X11R6
> fixes but haven't seen anything related to-date) - can anyone more
> knowledgeable shed some light on what could be going on?
First, try it on other PEX servers, if you can. Try to use vendor
product PEX servers if you can. The PEX-SI in the Consortium distribution
may still have bugs. It was fixed quite a bit when it came out in R5,
but has not changed much since.
You should probably file an error report with the X Consortium if you'd
like them to try to fix the problem. A report form is in your X source
tree, as well in other places. Part of the problem is that people discover
these bugs and don't report them!
Simon Wright
clipping of polylines.
I found the same effect in one of the examples from Gaskins' book
(sorry, forget which one); this was in X11R5, I understand the X11R6
PEX SI is the same.
--
Simon Wright
Ferranti Naval Systems Voice: +44(0)1705-701778
A Division of GEC-Marconi Ltd FAX: +44(0)1705-701800
Kevyn Ford soft
> >
> > PC/Linux Sparcstation2/SunOS 4.1.x
> > X11R6/Motif 2.0/X3D-PEX X11R5/Motif 1.2/X3D-PEX
> > XFree86 3.1.1/3.1.2 ??
> > gcc 2.6.3 gcc 2.6.3
>
> Does it fail on both these platforms? You don't really say.
>
> Are you using Sun's PEX server on the Sun, or did you build X/PEX on it from
> the Consortium distribution?
however.
> Be careful with a large number of vertices, so that you don't go over
> the 65K word limit per request/primitive. But that is not the problem
> here, as the next paragraph shows.
Actually, this very well may be the problem; I broke up the ppolyline3()
calls so that only around 10 verticies per call were used - the problem went
away!
I had been fairly sure that it was a resource-related problem, but didn't
know about the 65k limit...
R. D. Cook [Rick]
|> > Be careful with a large number of vertices, so that you don't go over
|> > the 65K word limit per request/primitive. But that is not the problem
|> > here, as the next paragraph shows.
|> Actually, this very well may be the problem; I broke up the ppolyline3()
|> calls so that only around 10 verticies per call were used - the problem went
|> away!
|>
|> I had been fairly sure that it was a resource-related problem, but didn't
|> know about the 65k limit...
|>
Kevyn,
This is actually an X limit - not PEX per say.
The maximum size (in bytes) of any X protocol request
can be computed using
max = 4 * (XMaxRequestSize(dpy) - 4)
and then there is a function in PEXlib called PEXGetSizeOCs()
that you can use to see if your OC is under that limit. There
is a good discussion of this in Gaskin's "PEXlib Programming
Manual".
Rick
Karl Schultz
> > Be careful with a large number of vertices, so that you don't go over
> > the 65K word limit per request/primitive. But that is not the problem
> > here, as the next paragraph shows.
> Actually, this very well may be the problem; I broke up the ppolyline3()
> calls so that only around 10 verticies per call were used - the problem went
> away!
>
> I had been fairly sure that it was a resource-related problem, but didn't
> know about the 65k limit...
The X protocol allows for a 16-bit length field per request, where the
request units are words. PEX, being an X extension, must also be subject
to the same restriction.
With X11R6, there is a new extension to X, called BRE (Big Requests Extension)
that would allow larger PEX requests. It works by looking at the next
WORD for the length if the normal 16-bit length field is zero. BRE is
important to PEX, especially for texture mapping, where texture data can
easily exceed 65k words. The PEX-SI does NOT use BRE and few, if any
vendors have actually implemented BRE yet.
Besides the architected limit, a server implementation might impose a
lower limit than 65k words. It is possible that you were bumping up
against a lower limit than you thought. If you want to double check,
determine the max request size using xdpyinfo and calculate the
length of a polyline by assuming 3 words per vertex, plus another
6 or so words for headers and overhead and see if you were pushing
the limit. If there is a color per vertex (I don't think so for this
example), the size is 6 words per vertex.
Thomas Stickdorn
>In article <42vif6$j...@kodak.rdcs.Kodak.COM>, k...@success.raster.kodak.com (Kevyn Ford soft) writes:
>> I have a problem with PEX/PHIGS applications that crash my X server; as a
>> reference, I've tried the same program on these two platforms:
>>
>> PC/Linux Sparcstation2/SunOS 4.1.x
>> X11R6/Motif 2.0/X3D-PEX X11R5/Motif 1.2/X3D-PEX
>> XFree86 3.1.1/3.1.2 ??
>> gcc 2.6.3 gcc 2.6.3
.
.
.
>> Essentially, I have a small test application (one of the PHIGS examples) that
>> draws a sphere. For a small number of vertices (~600) it works fine, for a
>> larger number of vertices (~20,000) the program crashes the server as it is
>> in the process of rendering the sphere (you can see it die in the middle).
.
.
.
>> Further investigation seems to indicate that a SMALLER sphere with 20,000
>> vertices works and a LARGER sphere with 600 vertices also works - I started to
>> wonder if the problem dealt with clipping.
>Does it die only when the lines are clipped?
>>
>> Using gdb, the stack at the time of the segment violation indicated:
>>
>> end
>> ??
>> Xalloc <-- (via #define macro)
>> miClipPolyLines
>> miPolyLines
>> traverser
>> miTraverse
>> RedrawStructures
>>
>> which further pointed to a memory allocation problem, which I find hard to
>> believe because my PC has 20M of RAM and 100M of swap.
>If there was an errant memory write in the stack/malloc area, Xalloc (malloc)
>might fail, independent of the amount of storage in the system.
>
>> I am definitely out of my league when it comes to debugging X server code, but
...
we had a similar problem while porting the PEX5 sample server (from X11R6)
to a different 3d graphics accelerator. Mysterious server crashes occured,
with similar core dump trace backs as shown above. In the end I found at least
one error in triangle strip clipping in the X11R6/PEX5 sample server code.
I corrected it - and the server stopped crashing. Essentially it was
an allocation error (underdimensioned) which can cause frequent server
crashes on some server compilations and none or nearly none on others.
I posted the following bug report to the X Consortium about nine month ago,
which was registered but - as far as I can see - not dealt with up to now.
Maybe you can try applying the error correction - as I suggested - and let me
know if it helped. For the reason of the proprietary graphics HW we ported to,
I cannot send a simple context diff, but understanding the problem and changing
your code (the sample code) shouldn't be a big problem.
Good luck,
Thomas Stickdorn
Thomas Stickdorn, GMD-FIRST, Rudower Ch. 5, D-12489 Berlin, Germany
(German National Research Center for Computer Science)
phone:+49-30-6392-1778 fax: +49-30-6392-1805 e-mail: sti...@first.gmd.de
-----------------------------------------------------------
ORIGINAL BUG REPORT:
-----------------------------------------------------------
From sticki Wed Dec 21 17:36:47 1994
Return-Path: <sticki>
Received: from kolibri.first.gmd.de by prosun.first.gmd.de (4.1/SMI-4.1)
id AA24757; Wed, 21 Dec 94 17:36:47 +0100
Date: Wed, 21 Dec 94 17:36:47 +0100
From: sticki (Thomas Stickdorn)
Message-Id: <941221163...@prosun.first.gmd.de>
To: sticki
Subject: Xserver/PEX5: memory allocation error in triangle strip clipping
Status: RO
VERSION:
R6, public-patch-5
CLIENT MACHINE and OPERATING SYSTEM:
Sparc/SunOS 4.1.3
DISPLAY TYPE:
custom
WINDOW MANAGER:
mwm - makes no difference
COMPILER:
gcc 2.6.3
AREA:
Xserver/PEX5
SYNOPSIS:
Memory allocation error in the function miClipTriStrip()
in the file xc/programs/Xserver/PEX5/ddpex/mi/level2/miTriStrip.c.
DESCRIPTION:
TriangleStrip-Clipping as one step in the rendering pipeline processes
a list of triangle strips (which are essentially a list of points).
The clipping takes places incrementally at possibly all 6 delimiting
planes of the (viewing) frustum. For each clipping plane the input list
of triangle strips is transferred into an output list, which is the input
list of the clipping process for the next clipping plane and so on.
These lists are taken from a stack of lists located in a device dependent
context structure. Each triangle strip consists of a list of points
that has as many entries as have been used by previous users of the
device dependent context. Before starting the clipping process on one
triangle strip, one has to assure that there is enough room for the clipped
triangles(i.e. points) in the output list. This is done by a macro called
MI_ALLOCLISTOFDDPOINT(pddolist, count, point_size), which takes as the
second argument the number of entries that should at least be allocated
in the corresponding point list. If there are already enough or even more
entries allocated in the list, nothing happens, otherwise (additional) memory
is (re)allocated. (In most critical cases the output list is already more
than large enough - that's why the error does only become obvious in a few
of these critcal situations).
The function miClipTriStrip() now allocates twice the number of points in the
input list for the output list, which looks like a reasonable amount, as a
triangle (3 points) intersected by a line (the clipping plane) will yield
no more than two triangles (six points). Looking at the actual clipping
process - which falls into 7 cases - one realizes that after the two starting
points of a triangle strip have been transferred to the output list, each
additional point from the input list can possibly produce 5 points in the output
list. Thus the above simple reasoning of "twice the vertex count" is obviously
too simple. The consequence is the allocated output list can get too short,
in which case the clipping routine writes beyond its end - and possibly
into any other structure allocated behind the output list on the heap.
My suggestion of a good amount is noted below in the sample fix -
though I must admit, I didn't think too much whether this is really correct -
I hope You do ?!.
REPEAT BY:
Not directly repeatable for you, because of custom hw, unportable program ... -
but easily reproducable by thinking it over.
SAMPLE FIX:
no context diff, because too many private changes in the file but the following
should suffice:
initial allocation:
/* Insure sufficient room for vertecies and degenerate points
* Note that twice the vertex count is an upper-bound for
* a clipped triangle(although there is probably a "tighter fit").
*/
/* The "twice assumption" may be right for a single triangle -
a triangle strip that is clipped the way it is done here
can definetely contain some more points:
Assuming a N-point tristrip has N-2 triangles, which can be
decomposed into 5 points each by the clip cases below,
an upper bound of (N-2)*5 vertices seems to better -
(correct me if I'm wrong).
The same applies to the point-allocation in case 7 below.
The following lines are changed :
MI_ALLOCLISTOFDDPOINT(pddolist, 2*vert_count, point_size);
sticki 20/12/94
*/
MI_ALLOCLISTOFDDPOINT(pddolist, 5*(vert_count - 2), point_size);
special case 7:
/* Insure sufficient room for remaining verts
and degenerate points */
/*
Look for the comment near the initial point allocation
for an explanation of the amount of allocation.
The following lines are changed :
MI_ALLOCLISTOFDDPOINT(pddolist,
2*(vert_count - k), point_size);
sticki 20/12/94
*/
MI_ALLOCLISTOFDDPOINT(pddolist,
5*(vert_count - k), point_size);
-----------------------------------------------------------
END OF ORIGINAL BUG REPORT:
-----------------------------------------------------------
Thomas Stickdorn, GMD-FIRST, Rudower Ch. 5, D-12489 Berlin, Germany
(German National Research Center for Computer Science)
phone:+49-30-6392-1778 fax: +49-30-6392-1805 e-mail: sti...@first.gmd.de
--
Thomas Stickdorn, GMD-FIRST, Rudower Ch. 5, D-12489 Berlin, Germany
(German National Research Center for Computer Science)
phone:+49-30-6392-1778 fax: +49-30-6392-1805 e-mail: sti...@first.gmd.de