Solution: Re: Sudden X/Performer problem

New Message Reply Date view Thread view Subject view Author view

Christopher R Volpe (volpe++at++ash.crd.ge.com)
Tue, 14 Jan 1997 15:29:36 -0500

Christopher R Volpe (that's me) wrote:
>
>
[Sharon describes how to tell if I'm a victim of this strange shared
arena bug]
> 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.

Bogus explanation on my part. For some reason I thought the heap was at
the top of the virtual address space, and the brk value was trying to
grow down into the shared arena, which was being placed too close below
the heap. Don't know why I thought that. I compared the brk value to the
pfGetSharedArenaBase() value after doing an explicit pfInitArenas().
They are equal when compiled with the default -mips3 (thereby preventing
the brk value from being increased by subsequent calls to malloc -- this
is the bug), but when compiled with -mips4, there's a 128Mb gap between
the brk value and the shared arena base, thereby allowing the brk value
to grow by a nice hefty amount if it needs to during the course of the
execution.

So, I decided to ensure that I had enough mallocable space by malloccing
and freeing some memory prior to initializing the shared arena. I
mallocced and freed 16MB, under the assumption that this would be enough
to shift the brk point a little, leaving enough room for whatever pfInit
needed. But I noticed that the arena base was now placed 128Mb beyond
the brk point, no longer right at the brk point.

So, maybe just moving the brk point at all causes the bug to disappear
and allows the shared arena base to be placed where it should, 128MB
beyond the brk point. I tested this by scrapping the malloc/free of 16MB
and replaced it with sbrk(1), i.e. move the brk point by one byte. Sure
enough, this did the trick.

So, if anyone else runs into this problem, before hardcoding virtual
addresses for the shared arena with pfSharedArenaBase(), try putting a
sbrk(1) before your pfInit() call.

Now, the question on my mind is: What on earth would tell Irix to
allocate shared arena right at the brk point, and why does it only do
this under certain circumstances?

-Chris

--


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

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:20 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.