Re: mlockall() and Performer

New Message Reply Date view Thread view Subject view Author view

From: Allan Schaffer (allan++at++sgi.com)
Date: 02/17/2000 13:02:08


> I have noticed that whenever I call the mlockall() system function in a
> performer application, performer core dumps during open flight model
> loading, particularly loading the cody wyoming MultiGen database. It does
> not bomb loading smaller simpler models like helicopter.flt. Can anyone
> explain why this is happening?

Wow ! This program crashed my Octane hard, twice. Worked ok with
'esprit.flt' but completely bombed with the Town.

My first impression is that the growable shared memory arenas and
other data lists used by Performer are causing mlockall() to trip
up. A few hints from the manpage strengthen that suspicion:

  Locks established with mlockall are not inherited by a child process
  after a fork.

  If the address space contains autogrow regions [see mmap(2)],
  mlockall will only cause the pages through the current end of file
  to be locked down.

  In the event automatic memory locking of future mappings is enabled
  for a process (MCL_FUTURE), and the locked memory of that process
  exceeds either the system's physical memory or the per process
  limit {PLOCK_MAX}, the process will receive a SIGSEGV with a signal
  code of ENOMEM [see sigaction(2) and signal(5)].

#1 implies problems after pfConfig(); and #3 gives me concern with
Performer's large Shared Arena (256MB, or larger). I presume
mlockall() is trying to lock up the whole thing.

Will have to check into the cause of that system crash though..

Allan


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Thu Feb 17 2000 - 13:11:21 PST

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