1006402 - 'do_GetService()' returns 'NS_OK' under Windows, but ' NS_ERROR_NOT_INITIALIZED' under Linux and MacOS

Status: RESOLVED INVALID

(Core :: XPCOM, defect)

Description

[sc.mozilla.org.j45P]

Attachment: Test case

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20140314220517

Steps to reproduce:

The problem happens with a XPCOM component written in C++. I wrote a test case to easily reproduce the problem. It's available in the file I've attached to this bug, but it is also visible at http://hg.savannah.gnu.org/hgweb/epeios/file/tip/bugs/Gecko/TestCase1/
The 'XPCOM' directory contains the component sources, and the 'XUL' directory all the XUL-related stuff.

For Linux and MacOS, the given 'Makefile' compiles the component, but you have to define the 'GDK' environment variable to the root path of the xulrunner SDK (as an example, I have 'GDK=/home/csimon/xulrunner-sdk' under Linux and 'GDK=/Users/csimon/xulrunner-sdk' under MacOS).

For Windows, as I don't know how to produce the equivalent of a Makefile (sorry...), you have to create a project in VC++ to compile the component.

Once you have the library for the component, you have to put it to 'XUL/components'. The  '.idl' file for the component is also provided, but the corresponding '.xpt' is already in place.

The '.ini' file to launch with 'firefox -app ...' or 'xulrunner ...' is in the XUL directory.

There is only one '.xul' file, which is 'XUL\chrome\geckobug1\content\Main.xul'. The calls to the component function which calls the 'do_GetService()' function are at lines 30 and 34.

By using the 'strace' commands under Linux, and the 'dtruss' command under MacOS, you can see that the 'LOG' macro (line 42 in 'XPCOM/geckobug1.cpp') write something like 'utime("LOG : geckobug1.cpp 111",...)' ('utimes(...)' under MacOS), where '111' is the line from where the macro is called.

My Windows environment is Windows 7, with Visual C++ 12.

My Linux environment is Ubuntu64 12.04 LTS, with GNU g++ V4.6.3

My MacOS environment is 10.8.0, with GNU g++ V4.6.4

With all this environments, I tried the test case with Firefox 28 and xulrunner 28, with the same issue.


Actual results:

Under Windows, 'do_GetService()' returns 'NS_OK', but 'NS_ERROR_NOT_INITIALIZED' under MacOS and Linux (see line 78 and below in 'XPCOM/geckobug1.cpp').


Expected results:

MacOS and Linux should behave like Window, that is 'do_GetService()' should also return 'NS_OK'.

Comment 1

[Nickolay_Ponomarev]

Sorry this got lost in a pile of 'untriaged' bugs...

Bugzilla is not the right place for this, as it is not clearly a bug in Mozilla's code, more likely something is wrong with the way you build your component.

Did you try https://developer.mozilla.org/en/docs/Troubleshooting_XPCOM_components_registration ?

If this is still a problem, try posting to the mailing lists, such as mozilla.dev.tech.xpcom, or getting help on IRC.

I heard that using ctypes, if you can, is preferred to using binary components these days.

Comment 2

[sc.mozilla.org.j45P]

Thank you for your answer, but the link you give is about problems with component registration, but my component is registered, as its code is executed, the only problem is that 'do_GetService()' behaves differently depending on the platform.

Meanwhile, I've tried the test case I've provided on the V29 and it failed only on one platform, instead of the two as described for the V28 (sorry, I don't remember the platform on which the test case still fails). It, perhaps, isn't due to a Mozilla code's bug, but I don't think that my component, or the way it is build, is faulty given the fact that it worked flawlessly and on all platforms with some previous version of Xulrunner.

I wrote this only for the record, because it might help you, along with the test case I provided (which also provides a Makefile, so you can check the way I built the component), to correct a possible problem with Xulrunner, as I do no more use Xulrunner due to (but not only) the problem described here, and switched to another technology...

Comment 3

[Nickolay_Ponomarev]

OK, I see. Sorry for inattentiveness on my part.

In any case, thanks for taking time to log this and sorry you had to switch to a different technology!

Comment 4

[Benjamin Smedberg]

Since this is external code, this is something you will have to debug yourself. I suspect that you may be using the wrong kind of glue linkage (e.g. defining XPCOM_GLUE) but bugzilla is not the right place to solve this kind of problem.