Christopher R Volpe (volpe++at++ash.crd.ge.com)
Mon, 13 Jan 1997 15:18:09 -0500
Regarding my following error at startup:
> ->>
> ->> PF Warning/Internal(12): pfWindow::openNewNoPort() - null visual.
> ->> X Error: 0
> ->> Request Major code 0 ()
> ->> Error Serial #33
> ->> Current Serial #15
> ->> Exit 1
Fred Clyne notes:
>
> ->
> ->>From the Performer 2.2 Beta Release Notes:
> ->
> ->o 6.2 OS bug with shared arena placement
> ->
> -> An obscure bug in IRIX 65.2 with default placement of the shared arena
> -> can cause programs to die due to lack of heap space for malloc.
> -> Typcially the program will die during X or GL initialization with
> -> a message like [what you stated above].
>
And Sharon points out:
> It is easy enough to see if you are being bit by this. Run your program through
> par: par -s -i -SS prog [options]
> and see if you get messages in the output about brk failing due to lack of space.
> If you do, then this is your beast.
Yup. That's my beast. I get lots o' them. However, if I compile the
entire application with -mips4 (I'm on an R10000), the problem
disappears. However, I suspect that's only because -mips4 allows the use
of certain instructions which cause the resulting code size to shrink,
therefore leaving more room between the shared arena and the brk point.
Therefore, the problem is likely to bite me again.
>
> ->
> ->WAR: through the environment variable PFSHAREDBASE or in with
> -> pfSharedArenaBase() before pfInit(), explicitly set the address of the
> -> arena so that it is not too close to the heap and does not collide
> -> with other DSOs. An address that has worked with programs exhibiting
> -> the problem that are very close to perfly is: 0x18000000.
>
> FYI, I added the PFSHAREDBASE when I ran into this problem so it isn't in
> currently released versions of Performer -- you have to use the API,
Ok, I'll use the API. However, my application is not derived from
perfly, so the magic number 0x18000000 is not necessarily correct. Is
there an algorithmic run-time way to determine a value that will make
brk() happy?
> or else
> a tricky rld WAR from Don Hatch - contact us for more info.
Fire away :).
Fred adds:
>
> ->
> -> ex: pfSharedArenaBase(0x18000000); or
> -> setenv PFSHAREDBASE 0x18000000
> ->
> -> If this address is not sufficient, run again with par [they had an
> -> example earlier: par -s -i -SS prog options] and the following
> -> environment variables set:
> -> setenv _RLD_PATH /usr/lib/rld.debug; setenv _RLD_ARGS -v
> -> and redirect all output to a file. Look for the addresses of the
> -> mmap() calls and of address of DSO load actions to find a free
> -> address range in which to place the arena. Compiling with some
> -> libraries statically can make this operation easier.
> ->
> ->Whew! I hope I don't run into this bug. Hope this helps.
Thanks for the info, Fred. Is this the "tricky rld WAR" that Sharon
refers to?
--Chris Volpe Phone: (518) 387-7766 GE Corporate R&D Fax: (518) 387-6560 PO Box 8 Email: volpecr++at++crd.ge.com Schenectady, NY 12301 Web: http://www.crd.ge.com/~volpecr ======================================================================= List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/ Submissions: info-performer++at++sgi.com Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:19 PDT