51655 - beos load_add_on() workaround

Status: VERIFIED FIXED

(NSPR :: NSPR, defect, P3)

Description

[justin morey]

due to a limitation of the its system loader, the beos can have only 32M of
add-ons (code dynamically loaded through the load_add_on() system call) loaded
at any given time.  the beos version of the nspr implements PR_LoadLibrary()
using load_add_on().  

unfortunately, mozilla is larger than 32M.

to work around this problem, some of mozilla's addons must be loaded as shared
libraries (the beos allows 256M of shared libraries).  i've attached a patch
which allows this to happen, through the use of "stub" add-ons: instead of
loading the library straight-away, the nspr will first try to load a stub add-on
(an empty .so which has been linked against the actual library).  when this stub
is loaded, the real library is loaded into the 256M shared library area, and
disaster is averted!

Comment 1

[justin morey]

Attachment: patch to PR_LoadLibrary() to accomodate stub addons

Comment 2

[Wan-Teh Chang]

r=[e-mail].

Do we need to get approval from brendan or waterson?

Comment 3

[cls]

By the book, yes but this patch has zero chance of destabilizing any tier-1
platforms (completely within XP_BEOS) and will help a lot in getting one of our
ports off the ground.  I say, just check it in. :-)

Comment 4

[Wan-Teh Chang]

I sent email to brendan and waterson for
checkin approval on NSPRPUB_CLIENT_BRANCH.

Comment 5

[Brendan Eich [:brendan]]

a=[e-mail] (sorry if redundant -- i thought i sent mail earlier).

/be

Comment 6

[Wan-Teh Chang]

Yes, brendan emailed me his approval this morning.
I just didn't have time to check in the patch.

I just checked it in on the NSPRPUB_CLIENT_BRANCH.
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision: 3.34.2.6

Comment 7

[Yannick Koehler]

I think there's a problem with this patch... when the add-on will get unloaded 
the ID of the add-on will not point on the add-on but on the library.  This may 
leave the part of the add-on still in the memory.  Totally uncertain about this 
but it's something one must look at.

Comment 8

[justin morey]

there's no problem:  a stub add-on is always unloaded immediately after it is
loaded (before PR_LoadLibrary() even returns), so none of the other code
(including PR_UnloadLibrary()) need know it ever existed...

Comment 9

[cls]

wtc, has this patch been checked into the nspr trunk as well?

Comment 10

[Wan-Teh Chang]

No, I haven't checked this patch into the NSPR trunk.
Is this patch final?

Comment 11

[cls]

Afaik, the patch is final until Be decides to release a kernel patch for the
problem.  From jbq's post to m.beos, it does not sound like this will be anytime
soon.  (jbq is a Be engineer.)

Comment 12

[larryh (gone)]

I will check in this patch to the trunk as a prerequisite fix before checking in 
 the patch for 53014.

Comment 13

[larryh (gone)]

Checking in prlink.c;
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c,v  <--  prlink.c
new revision: 3.44; previous revision: 3.43
done

Comment 14

[cls]

Marking fixed.

Comment 15

[Kai Lahmann (is there, where MNG is)]

v