XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) (03/10/89)
Hallo everybody,
we just encountered a strange graphic problem after upgrading
a) from a 4D70G to a 4D70/GT and after that
b) from some IRIX 3.1 prerelease to IRIX 3.1C.
Before this action the following (highly simplified) code worked just fine:
main()
winopen("1.st");
fork()
if parent: do some work
else if child: winopen("2.nd") and some more work
After the double-upgrade we get a core-dump from the second winopen. The call-
stack reads like this:
gl_init_wstate( .... ) glinit.c line 148
winope( ..... ) winstuff.c line 538
winopen (....) ginit.c line 98
I would like to know whether this is a bug in the software, or a violation
of the window-manager rules, or a feature of the GT-hardware. A small test-
program, which reproduces the described behaviour, is included an can be
compiled and linked using
cc test.c -o test -lgl -g
We would really appreciate a fast response, because this problem is quite
disturbing to our work.
Regards
Martin Knoblauch
TH-Darmstadt
Physical Chemistry 1
Petersenstrasse 20
D-6100 Darmstadt, FRG
BITNET: <XBR2D96D@DDATHD21>
-----------------------------test.c-------------------------------------------
#include <stdio.h>
#include <gl.h>
main()
{
int id1,id2,f_id;
id1 = winopen("first");
f_id = fork();
if( f_id == -1) { printf(" no success in fork \n ");
exit(0); }
if( f_id != 0) { printf(" child = %d \n",f_id);
while(TRUE);
exit(0); }
printf(" now new \n");
id2 = winopen("second");
printf(" kicker ??? \n");
ringbell();
while(TRUE);
}
-----------------------------------end of test.c------------------------------
msc@ramoth.SGI.COM (Mark Callow) (03/10/89)
In article <8903091140.aa07481@SMOKE.BRL.MIL>, XBR2D96D@DDATHD21.BITNET (Knobi der Rechnerschrat) writes: > Hallo everybody, > > we just encountered a strange graphic problem after upgrading > > a) from a 4D70G to a 4D70/GT and after that > b) from some IRIX 3.1 prerelease to IRIX 3.1C. > > > Before this action the following (highly simplified) code worked just fine: > > > main() > > winopen("1.st"); > fork() > if parent: do some work > else if child: winopen("2.nd") and some more work > > After the double-upgrade we get a core-dump from the second winopen. The call- > stack reads like this: > > gl_init_wstate( .... ) glinit.c line 148 > winope( ..... ) winstuff.c line 538 > winopen (....) ginit.c line 98 > I've just investigated this for you. The problem is that on the GT there is a piece of per-process shared memory between the GL Client and the Window Server. This is established when the GL is initialized which happens at the first winopen. When you fork and do the second winopen, the window server establishes another piece of shared memory for the child process. Unfortunately the GL, since it has already been initialized, tries to use the shared memory of the parent instead of reinitializing its global state structure to use the child's shared memory. In other words, this is a bug in the GL. We are planning to fix the GL so you can use graphics from multiple shared-processes (sproc threads). This is probably typical of the problems we will uncover in that work. You can expect the problem to be fixed though I don't know when. Unfortunately I can't think of a workaround. Perhaps the GL experts can help. -Mark -- -Mark