36170 - NSPR's shared library loader doesn't properly report errors under beos

Status: VERIFIED FIXED

(NSPR :: NSPR, defect, P3)

Description

[justin morey]

the beos-specific part of the nspr's shared library loader doesn't preserve 
failure codes, causing a not-very-helpful "No Error" description to be displayed 
to the user whenever a shared library fails to load, regardless of the actual 
cause

Comment 1

[justin morey]

Attachment: fix for bug (saves error code into errno)

Comment 2

[Wan-Teh Chang]

Thanks for the bug report and the fix.

I'm going to propose a different fix for the
following reasons:
1. I don't want to mess with errno.  NSPR functions
   should not set errno.  I'm going to store the
   error code in a local variable named oserr.
2. We are not passing the right error code to PR_SetError
   on Mac and OS/2 either, so I'm going to fix that too.

Comment 3

[Wan-Teh Chang]

Attachment: Proposed fix that uses a local variable oserr.

Comment 4

[Wan-Teh Chang]

The patch (id=7758) was checked in on the main trunk.
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision 3.38.

Note that the Mozilla client pulls a branch tag of NSPR,
not the tip of NSPR, so the Mozilla client is not getting
this fix right now.

This fix will be in NSPR 4.1.  I do not think it is serious
enough to go into the NSPR 4.0.1 patch release.  Please let
me know if you think the Mozilla client needs the fix right
away.

Comment 5

[Yannick Koehler]

I would like to see this patch inside the Mozilla client current branch.  Reasons is that most newcomers just 
extract current version and always come back with this one.  The other problem being that this is slowing us down 
on finding what's the reason of the error.

Comment 6

[Wan-Teh Chang]

The documentation at
http://www-classic.be.com/documentation/be_book/The%20Kernel%20Kit/Images.html#l
oad_add_on()
says that the only error code that can be returned
by load_add_on() is B_ERROR, which is a convenient
catchall for general errors.  If so, this fix still
can't tell you the reason of the load_add_on()
failure; it only removes the confusing "No Error"
error message.

Comment 7

[justin morey]

in this case, the bebook is mistaken - load_add_on() actually does return meaningful error codes, and the patch i submitted did indeed result in proper error messages ("Symbol not found", "No such file or directory", etc.)

Comment 8

[Wan-Teh Chang]

OK.  That makes sense.  Are all BeOS error codes negative
numbers?

I checked in the fix on the NSPRPUB_RELEASE_4_0_BRANCH
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision 3.32.4.4

I checked in the fix on the NSPRPUB_CLIENT_BRANCH.
/cvsroot/mozilla/nsprpub/pr/src/linking/prlink.c, revision 3.34.2.2

Comment 9

[justin morey]

all beos errors codes are negative numbers (see http://www-classic.be.com/developers/developer_library/headers/be/support/Errors.h for the complete list)...thanks!

Comment 10

[justin morey]

your patch works just fine - thanks!

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3f3815b6daaa
[fenix] Issue #36170: BaseBrowserFragment: Use new feature-prompts API.