Last Comment Bug 416119 - js-ctypes doesn't open shared library when using Linux
: js-ctypes doesn't open shared library when using Linux
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: js-ctypes (show other bugs)
: unspecified
: x86 Linux
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: js-ctypes
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-07 05:46 PST by Fredrik Larsson (:nossralf)
Modified: 2009-10-02 03:17 PDT (History)
1 user (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
tentative fix (835 bytes, patch)
2008-02-07 05:53 PST, Fredrik Larsson (:nossralf)
no flags Details | Diff | Splinter Review
tentative patch v. 2 (801 bytes, patch)
2008-02-07 07:05 PST, Fredrik Larsson (:nossralf)
no flags Details | Diff | Splinter Review
yet another revision, wee (1.13 KB, patch)
2008-02-18 16:01 PST, Fredrik Larsson (:nossralf)
no flags Details | Diff | Splinter Review

Description Fredrik Larsson (:nossralf) 2008-02-07 05:46:00 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4pre) Gecko/2008020504 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008013122 Minefield/3.0b3pre

When trying to open a shared library using js-ctypes in Linux, the open() method returns/throws NS_ERROR_FAILURE.

Reproducible: Always

Steps to Reproduce:
1.Compile Firefox with js-ctypes as an extension.
2.Try opening a shared library file (in an extension or similar).

Actual Results:  
NS_ERROR_FAILURE is returned/thrown.

Expected Results:  
The shared library is loaded.

This is due to the way the PRLibSpec struct is filled out in nsNativeTypes::Open. The |libSpec.value.pathname_u = ...| assignment only works under Win32 as can be seen in prlink.c.
Comment 1 Fredrik Larsson (:nossralf) 2008-02-07 05:53:08 PST
Created attachment 301890 [details] [diff] [review]
tentative fix

This patch fixes the problem for me. It's fairly straight-forward, although since I'm new at this thing (especially the Mozilla string classes) there may be a shorter way of doing it.

Also, I'm not 100% sure that dlopen() groks UTF-8 so it's possible the conversion has to be the lossy one from UTF-16 to ASCII. (From what I've been able to find, it doesn't seem to mind being fed UTF-8.)

Also, the patch isn't -u8p since svn diff kinda sucks.
Comment 2 Fredrik Larsson (:nossralf) 2008-02-07 07:05:33 PST
Created attachment 301909 [details] [diff] [review]
tentative patch v. 2

The copy was most likely completely unnecessary (aName being an in parameter). This works too, and is probably more correct.

Sorry for the bug spam. I still have the training wheels on my bug-fixin' bike.
Comment 3 Fredrik Larsson (:nossralf) 2008-02-18 16:01:19 PST
Created attachment 304115 [details] [diff] [review]
yet another revision, wee

I may be breaking the record for most patch revisions for a 6-line addition. I deserve a medal. And cake.

Anyway, this one only uses ns[C]AutoString, and gets rid of the original nsString line, which is bad stack mojo according to the string literature.

I'll shut up now.
Comment 4 Mark Finkle (:mfinkle) (use needinfo?) 2008-02-27 20:15:06 PST
Bug 397248 pointed out a problem with not using a local string so I used patch 2 instead of patch 3.

Note You need to log in before you can comment on or make changes to this bug.