Firefox crash after closing it. The issue happens when native java child process launched.



Add-on SDK
2 years ago
9 months ago


(Reporter: Dhatchana Moorthy, Unassigned, NeedInfo)


({crash, crashreportid})

crash, crashreportid

Firefox Tracking Flags

(firefox-esr45 affected)


(crash signature)


(5 attachments)



2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

1. Launch Java native process using the JPM code.

    const { spawn } = require('sdk/system/child_process');
    proc = spawn(javapath ,['-jar',this._nativeAppPath, 'firefox']); 

2. We make the communication between the native code and extension happens through standard input and output.

3. We are not able to capture the firefox close event in extension properly and so we exit java process when the stdout pipe is closed.

Actual results:

Firefox crashes before the stdout pipe is closed

Expected results:

Firefox should close the stdout pipe or there must be a way in capturing the firefox close event in extension code.
Post some URLs of these crashlog reports from about:crashes
Flags: needinfo?(dhatchana.sekar)

Comment 2

2 years ago
Created attachment 8772349 [details]

Comment 3

2 years ago

I have added the screenshot of the about:crashes in which the rounded one's report has already been submitted to Mozilla.


2 years ago
Flags: needinfo?(dhatchana.sekar)
Severity: normal → critical
Crash Signature: [@ shutdownhang | WaitForSingleObjectEx | PR_WaitCondVar | nsThread::ProcessNextEvent | NS_ProcessNextEvent | mozilla::dom::workers::RuntimeService::Cleanup ]
status-firefox-esr45: --- → affected
Keywords: crash, crashreportid
Component: Untriaged → Untriaged
Product: Firefox → Core

Comment 5

2 years ago
WONTFIX probably as Mozilla doesn't want to support Java plugin anymore due to many regressions and security failures.
Component: Untriaged → Plug-ins
Adding this comment on behalf of reporter.

This issue is not about Java Plugin. We are not loading java plugin with Firefox ESR 45.x. We have a Firefox extension implemented which will communicate with standalone java process. While closing Firefox, we expect firefox extension gracefully kill the child/standalone java process, but It couldn't do it and crashes.

Comment 7

2 years ago
So could you provide a testcase or a minimal extension to reproduce the issue.


2 years ago
Flags: needinfo?(dhatchana.sekar)

Comment 8

2 years ago
I have attached the JPM extension code, the html, jar and java files with the task.

Steps to reproduce:

1. Copy extension code and jar file to a local machine
2. Copy the html into any app server app
3. Modify the values of java.exe path and jar path in the addon.js. proc = spawn("C:\\Program Files (x86)\\Java\\jdk1.7.0_45\\bin\\java.exe" ,['-jar',"C:\\Users\\sekard\\Desktop\\firefox addon sample\\samplenative.jar"]);         
4. run the jpm command
5. access the crash_html page in the app server
6. click on 'Launch and Handshake Native' button. You will see an alert after the launch and handshake is done with the java native process
7. Close the browser. Now the jpm command will not be terminated. But if you kill the java process, then the command will be terminated.
8. Also if you do Ctrl+C in the command prompt without killing java process, you will see some error messages in the console.

Basically we need to know the mechanism to identify the firefox close event either in addon.js extension code or in java native.

Comment 9

2 years ago
Created attachment 8774657 [details]

Comment 10

2 years ago
Created attachment 8774658 [details]

Comment 11

2 years ago
Created attachment 8774659 [details]

Comment 12

2 years ago
Created attachment 8774660 [details]


2 years ago
Flags: needinfo?(dhatchana.sekar)
With the minimal/sample firefox extension attached to reproduce the issue, can someone help review this and provide us useful pointers? This is urgent for one of release with the firefox extension we created.

Comment 14

2 years ago
Did it use to work with previous versions of Firefox? If yes, could you download the tool Mozregression (see for FAQ) and narrow down a regression range (copy here the final pushlog).
This crash issue has been observed in Firefox ESR 38.x as well in addition to ESR 45.x. we are not sure about earlier versions before ESR 38. We strongly believe this issue is something to do with firefox handling the child native processes. Can we get some help here? Is the sample extension provided is helpful and the issue reproducible internally?


2 years ago
Flags: needinfo?(benjamin)

Comment 16

2 years ago
CC'ing Benjamin, because he knows better than me the future about fixing bugs about plugins and especially Java.
Benjamin is not available until next week. Considering that this is urgent, I would suggest that you use mozregression to isolate a particular build when this was introduced (see comment 14). This could significantly speed up the process of writing a fix.

Comment 18

2 years ago
As is clear, this has nothing to do with plugins. This is a bug in the Addon SDK implementation of system/child_process.

We now have the native messaging support as part of webextensions. This problem is likely to be solved using the webextensions API instead of the SDK.

That said, the one crash report listed here ( is a shutdown hang. I'm a little confused about the sequence of events here:

1. Firefox launches a child process (in this case, Java)
2. Now what? The user quits Firefox?
2a. If so, does the addon call child.kill or child.disconnect or some other method?
2b. If not, is the child process exiting? and/or just closing its pipes?

Thread 31 of this crash is blocked calling ReadFile, so you're reading from a pipe and that's blocking shutdown. Are you reading more data than the process has actually provided?
Component: Plug-ins → General
Flags: needinfo?(benjamin) → needinfo?(dhatchana.sekar)
Product: Core → Add-on SDK
Version: 45 Branch → unspecified
This is mostly echoing bsmedberg but the SDK child_process module has not been actively maintained in some time.  From looking at your attached extension code, this extension looks like it would port quite easily to webextensions and the native messaging api offered there, I would urge you to follow that path rather than chasing add-on sdk bugs.
Last Resolved: 9 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.