1073190 - js-ctypes dylib is not reloaded when upgrading a restartless addon, until a Firefox restart (if dylib uses Cocoa)

Status: NEW

(Core :: js-ctypes, defect)

Description

[DSUWIRYA]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36

Steps to reproduce:


- Characteristic of addon.xpi:
  + it is built using addon-sdk-1.6.
  + contains a dylib component that expose GetVersion()
  + accessed using js-ctypes in addon main.js.

- addon.xpi v0.0.0.1 installed.
- invoke GetVersion() - returns 0.0.0.1 - OK.

- update to addon.xpi v0.0.0.2.
- invoke GetVersion(), returns 0.0.0.1 - NOK.

- restart Firefox.
- invoke GetVersion(), returns 0.0.0.2 - OK. 



Actual results:

Firefox OSX does NOT correctly reloads the new js-ctypes dylib immediately after the addon.xpi update. Firefox OSX only reloads it, after the browser restart.




Expected results:

Firefox Windows and Linux do correctly reload the new js-ctypes native component (.dll, .so) immediately after the addon.xpi update, without the need for restarting the browser first.

Comment 1

[Nickolay_Ponomarev]

Thanks for the report! Do you have a testcase extension that can be used to reproduce the problem -- or even better some code in Browser scratchpad that reproduces the issue?

Comment 2

[DSUWIRYA]

Attachment: ff-bug-1073190.zip

- ./addon : addon code
- ./native : dylib code
- test-1.0.xpi : test addon version 1
- test-2.0.xpi : test addon version 2

Steps:
- Launch FF, open Browser Console.
- Drag & drop test-1.0.xpi, you'll see log in Browser Console : TEST-VERSION: 1
- Drag & drop test-2.0.xpi, you'll see new log in Browser Console but still with TEST-VERSION: 1 (NOK), where it's expected to log TEST-VERSION: 2.
- Restart FF, open Browser Console, you'll see log TEST-VERSION: 2.

Note.

- This problem seems to occurs if the dylib code using Cocoa framework.

- From a quick search I made, this might be related : 
http://stackoverflow.com/questions/8793099/unload-dynamic-library-needs-two-dlclose-calls

Comment 3

[Andrew Zitnay]

I'm seeing this as well, and I appear to be seeing it on both Mac OS X and Linux (not Windows).

Comment 4

[Nickolay_Ponomarev]

I can reproduce with the testcase from comment 2 (thanks again!)

The stackoverflow answer says this is limitation of Objective-C runtime... I think this can be worked around by changing the lib name in each new version of the addon.

If this also happens on Linux, it's probably a different issue.

Comment 5

[DSUWIRYA]

Lib renaming approach on each new version doesn't seem to help neither. 

Please find a new attachment containing test-2.0-rename.xpi. Do exact steps as in comment #2 to reproduce.

Thanks.

Comment 6

[DSUWIRYA]

Attachment: test-2.0-rename.xpi

additional test for comment #5.

Comment 7

[Nickolay_Ponomarev]

Unfortunately, I won't be able to look into this issue.

Comment 5 is surprising though, and probably warrants further troubleshooting. The first thing I'd try is check if you're able to load the two dylibs from a single add-on (without the upgrade step). If you can't it's either another serious limitation, or the dylibs you're testing with have something that prevents them from being loaded simultaneously.