Sharon Clay (src++at++rose.engr.sgi.com)
Mon, 3 Aug 1998 11:36:58 -0700
->Shared memory is allocated by the data process. We attach to it
->in the render process... or at least we used to. Having recompiled
->and linked with Performer 2.2, our call to shmat() in our render
->process as shown below now fails, with errno=ENOMEM.
->
->key_t memKey = 0x1234567 // our unique key, unique eh?
->size_t ttlSize = 0x210000 // big enough for our purposes
->#define SHM_ADRESS 0x04200000 // the result of some tuning
Are you sure this address is still valid?
Possibly some DSO is getting loaded in your range from this address now,
maybe only in your main process where you do the attach.
To find out... set RLD tracing to see where DSOs are placed:
setenv _RLD_PATH /usr/lib/rld.debug;
setenv _RLDN32_PATH /usr/lib32/rld.debug;
setenv _RLD_ARGS -v
Then run your program via
par -s -i -SS prog prog_options
and you'll see every single shared mem segment and DSO placed so that
you can find out where the conflict is.
If this is the problem, DSO default locations can be moved with rqs and the
creation of a new so_locations file (do a man on rqs).
src.
--
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com (650) 933 - 1002 FAX: (650) 933 - 0858 MS 8U-590
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
=======================================================================
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 Tue Aug 11 1998 - 13:42:34 PDT