1334503 - After upgrading to version 51.0.1 a lot of conathst.exe processes are created in Win XP sp3 causing crashes including system crash (memory limit?)

Status: RESOLVED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[dzz1234]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

I've restarted the system and after starting firefox (51) again and opening the task manager, I noticed a plethora of the conathst.exe process. 

I reinstalled an older version (50.1.0) and the above problem doesn't appear, so it's seems it a new bug.


Actual results:

I guess because too many conathst.exe processes were created (thus probably reaching memory limit), firefox suddenly crashed. Another time the whole system (as mentioned: Win XP sp3) crashed (something that doesn't usually happen to me).

Thank you for your time.

Comment 1

[YF (Yang)]

[conathst.exe is part of Norton Identity Safe and developed by Symantec Corporation according to the conathst.exe version information.]


Please check your Norton settings and feedback to them


[Tracking Requested - why for this release]:

Comment 2

[Simon Arbon]

I have this same bug with Firefox 51.0.1, Windows XP, Norton 360 (including Norton Identity Safe).
As soon as I start Firefox (and I assume it is trying to load this web browser add-on from symantic), Firefox tries to "Assign process to job object" with the target file "conathst.exe"  (according to Norton 360's security history log).

Norton's self-protection security system sees this as an "Unauthorised access" to this file and blocks it.
Firefox continuously retries this action and every time it does it creates a new conathst.exe process until there are hundreds of them and windows rapidly becomes unusable.
This did not happen with 51.0.0

Comment 3

[adm101]

This problem is caused by updating from Firefox 50.1.0 to 51.0.1 with no changes to Norton on XP systems.

Many people are having this SYSTEM CRASH caused by updating Firefox, and they have no idea what is causing it, and their Firefox browser is dead and unusable due to this loop situation in Firefox 51.0.1 when running on XP.  It also crashes stable XP systems.  

Firefox is the only current browser we have on XP!  That is the one reason that hundreds of thousands still use Firefox! (If not millions!)

Firefox needs to look at this.  Norton has made no changes.  Dropping back (if one knows how) to Firefox 50.1.0 stops the problem.  FIREFOX, HELP!

Comment 4

[adm101]

Tens of thousands of conathst.exe processes are being created - looks like Norton defending itself against Firefox access.  Problem DOES NOT occur on Windows 7 using exactly same Norton Internet Security release and options.  Something FFOX 51.0.1 is doing on XP that FFOX 50.1.0 does not do is causing problem.  Norton says error is 

Category: Norton Product Tamper Protection
Date & Time,Risk,Activity,Status,Recommended Action,Date,Actor,Actor PID,Target,Target PID,Action,Reaction
1/27/2017 8:09:09 PM,Medium,Unauthorized access blocked (Assign Process To Job Object),Blocked,No Action Required,1/27/2017 8:09:09 PM,C:\PROGRAM FILES\MOZILLA FIREFOX\FIREFOX.EXE,2392,C:\Program Files\Norton Internet Security\Engine\22.8.1.14\conathst.exe,14820,Assign Process To Job Object,Unauthorized access blocked

Firefox 51.0.1 then repeats the function that got the error repeatedly causing loop (high CPU) creating conathst.exe tasks until Firefox or XP crashes.

Comment 5

[Simon Arbon]

(In reply to Simon Arbon from comment #2)
Typo in the last line should be:
This did not happen with 50.1.0

Comment 6

[Bob]

I have exactly the same issue as described in the earlier comments. FF runs slower and slower with more and more conathst.exe processes being spawned until the system crashes (presumably having run out of memory). This didnt happen prior to FF upgrade to 51.0.1. 
Disabling the Norton Security Toolbar plugin in FF and rebooting the system stops the problem, but this is obviously not a permanant solution. Cant upgrade FF on any of my other XP (SP3) boxes until this is fixed.

Comment 7

[Gerry Chang [:gchang]]

Hi Milan,
Can you help shed some light here?

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

This sounds serious; adding a few people on needinfo.

Comment 9

[Marco Castelluccio [:marco]]

We have a thread in the mailing list with Symantec, which reported this to us.

Comment 10

[[:philipp]]

[e-mail] is on our e10s addon whitelist for 51 - maybe this is why it appeared after the last update.

Comment 12

[Jim Mathies [:jimm]]

Updates from the dupe:

(In reply to Jim Mathies [:jimm] from comment #0)
> Issue reported with this API in Fx51 where the spawn succeeds but the child
> process fails to connect up proerly wit the parent, which in some add-ons
> can result in numerous childs process getting launched, consuming system
> resources.
> 
> https://community.norton.com/en/forums/task-manager-gone-mad-conathstexe
> 
> Some data points:
> - only happens on XP SP3.
> - Failure is “Failed to attach process to job” which appears to be related
> to the code calling AssignProcessToJobObject and getting “access denied”.
> - not related to sandboxing or e10s which isn't enabled for these users
> 
> We don't have a lot of devs internally who can test for this. Benjamin, can
> softvision help us out here with an attempt to reproduce and a regression
> range search?

(In reply to Benjamin Smedberg [:bsmedberg] from comment #1)
> We presumably have access to at least some XP VMs. But if you're asking SV
> to provide a regression range, can we create some sort of minimal testcase
> addon so that they can easily run the regression? Having to check task
> manager for a production addon sounds tricky.
> 
> According to AssignProcessToJobObject docs: "Windows 7, Windows Server 2008
> R2, Windows XP with SP3, Windows Server 2008, Windows Vista and Windows
> Server 2003:  The process must not already be assigned to a job; if it is,
> the function fails with ERROR_ACCESS_DENIED. This behavior changed starting
> in Windows 8 and Windows Server 2012."
> 
> We have automated tests for subprocess.jsm at
> toolkit/modules/subprocess/test/xpcshell/test_subprocess.js. Are those being
> run/passing on windows xp? Kris Maglione wrote this module and test, so I
> think he'd be the best engineering lead to look at this.

Comment 13

[Jim Mathies [:jimm]]

Kris, any insight here?

Comment 14

[Jim Mathies [:jimm]]

Looks we do run sdk tests for release builds and XP, but afaict there are no subprocess tests in the sdk test suite -

https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&filter-searchStr=jp

The xpshell tests also run and pass - 

https://treeherder.mozilla.org/#/jobs?repo=mozilla-release&filter-searchStr=xp

18:17:48 INFO -  TEST-PASS | toolkit/modules/subprocess/test/xpcshell/test_subprocess.js | took 7128ms

Comment 15

[Kris Maglione [:kmag]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #1)
> We presumably have access to at least some XP VMs. But if you're asking SV
> to provide a regression range, can we create some sort of minimal testcase
> addon so that they can easily run the regression? Having to check task
> manager for a production addon sounds tricky.

We replaced the subprocess module that the SDK was using with a stub wrapper
around Subprocess.jsm in Firefox 52, and it looks like it was uplifted to 51.
I think it's safe to say that that is the cause.

> According to AssignProcessToJobObject docs: "Windows 7, Windows Server 2008
> R2, Windows XP with SP3, Windows Server 2008, Windows Vista and Windows
> Server 2003:  The process must not already be assigned to a job; if it is,
> the function fails with ERROR_ACCESS_DENIED. This behavior changed starting
> in Windows 8 and Windows Server 2012."

On Windows versions < 6.2 (Windows 8/2012), we attempt to break away from the
current job when we create the process. If that fails, the process creation
should fail, so we should never get to the point of trying to attach it to a
job. There may be something else preventing that, though.

Currently, it looks like we don't explicitly terminate the process if we fail
to attach it to a job, which is probably the cause of the extra processes
hanging around. I suppose our options there are to either terminate the
process, or stop treating the failure to attach the process to a job as an
error.

Either way, I'd suggest that the developers of this add-on either migrate to
using Subprocess.jsm directly, or switch to Native Messaging. The SDK wrappers
around this module add a lot of overhead and extra moving parts.

> We have automated tests for subprocess.jsm at
> toolkit/modules/subprocess/test/xpcshell/test_subprocess.js. Are those being
> run/passing on windows xp? Kris Maglione wrote this module and test, so I
> think he'd be the best engineering lead to look at this.

Yes. The BREAKAWAY_FROM_JOB functionality was added specifically so the tests
would pass under our harness when running on Windows XP.

Comment 16

[Kris Maglione [:kmag]]

(In reply to Simon Arbon from comment #2)
> As soon as I start Firefox (and I assume it is trying to load this web
> browser add-on from symantic), Firefox tries to "Assign process to job
> object" with the target file "conathst.exe"  (according to Norton 360's
> security history log).
> 
> Norton's self-protection security system sees this as an "Unauthorised
> access" to this file and blocks it.

Oh, yeah, I guess that would do it. They're pretty much shooting themselves in the foot, then. But we at least shouldn't leave the stale processes lying around after this happens.

Comment 17

[Jim Mathies [:jimm]]

(In reply to Kris Maglione [:kmag] from comment #15)
> Currently, it looks like we don't explicitly terminate the process if we fail
> to attach it to a job, which is probably the cause of the extra processes
> hanging around. I suppose our options there are to either terminate the
> process, or stop treating the failure to attach the process to a job as an
> error.

How hard would it be to add a fix for this, and could we safely get that out into release?

Comment 18

[Kris Maglione [:kmag]]

(In reply to Jim Mathies [:jimm] from comment #17)
> (In reply to Kris Maglione [:kmag] from comment #15)
> > Currently, it looks like we don't explicitly terminate the process if we fail
> > to attach it to a job, which is probably the cause of the extra processes
> > hanging around. I suppose our options there are to either terminate the
> > process, or stop treating the failure to attach the process to a job as an
> > error.
> 
> How hard would it be to add a fix for this, and could we safely get that out
> into release?

Not very difficult, and yes, we could safely get it into release. I'm not sure we'd want to chemspill for it, though, especially given that it only seems to affect a limited number of Windows XP users.

We might be able to deploy it to those users as a hotfix or system add-on, though. Or just blocklist the extension for XP users.

Comment 20

[Kenneth Allison]

Gentlemen:

09FEB17, Windows XP (SP-3), restored XP back to the future (50.1.0) from yesterday's Firefox update. Update 51.0.1 calls conathst.exe many times over and over again as stated by many other users. These processes remain open even after Firefox 51.0.1 is closed, but no new processes spawn with new PID's. This can be seen in Windows XP Task Manager, so I restored back to version 50.1.0.
>
With the NORTON TOOLBAR enabled on version 50.1.0, I get exactly one (1) instance of conathst.exe. With it disabled I get no instance(s) of conathst.exe. I do not know and will not know how Firefox 51.0.1 would work with the Norton Toolbar Disabled, but it might be a temporary solution.
>
Norton Internet Security, version 22.8.1.14; conathst.exe-description: Web Browser (Norton Identity Safe native host), file version: 2015.8.1.3, original file name: coNatHst.exe.

Comment 21

[Kenneth Allison]

Update: 09FEB17@1212 EST -Norton Internet Security just downloaded a 150 MB version change to 22.9.0.68.
Furthermore, conathst.exe also changed from about 116 KB to 99 KB. New conathst.exe info. -file version: 2015.9.0.7 -The plot thickens.

Comment 22

[adm101]

(In reply to Kenneth Allison from comment #21)
> Update: 09FEB17@1212 EST -Norton Internet Security just downloaded a 150 MB
> version change to 22.9.0.68.
> Furthermore, conathst.exe also changed from about 116 KB to 99 KB. New
> conathst.exe info. -file version: 2015.9.0.7 -The plot thickens.

My XP was updated with that new Norton Internet Security 22.9.0.68 a day or so ago.  Had to do multiple restarts and updates to finish the updates. 

Last night, I enabled the Norton Security Toolbar in Firefox 51.0.1, and the runaway conathst.exe creation started - can't remember if I shut FF down and back right then, but the problem is the same as before (still same problem with 22.9.0.68 installed).  I disabled the Norton Toolbar plugin and the conathst.exe creations stopped right then (and CPU dropped back to idle).  I had to move fast, to avert a crash.  All those conathat.exe's cause the task manager to use a lot of CPU, and shutdown/restart takes a while to clean them up, by the way.  

So no, the plot has not thickened.  Same o.  Needs a Firefox fix as previously discussed!

Wonder if Mozilla has stats to see how many XP and XP MCE machines are running Firefox?  
COULD BE THE MAJORITY OF THE REMAINING CUSTOMERS??  If so, might need to fix this right away, no?

Comment 23

[PaulDent]

I also reverted to version 50, however, there is NO WAY to stop it trying to automatically upgrade to version 51.0.1 when you open it up for the second time. Even when I did the advanced install and asked for no updates, and even after manually deleting the maintenance program from disc. It tries to get round that by downloading something huge, which totally hung up my internet for a couple of hours even after I powered down the DSL modem; when I powered it up again, it was still at it until it gave up hours later! 
Then I had no WiFi and had to reset my router - the password to which I had long forgotten! 
This suggests there is another myriad of annoying issues that need to be fixed.

BTW, I was forced to delete Firefox and install Chrome to carry on working.  There was an AMAZING increase in the speed of my PC, even when not using a browser. It boots up instantly, the disc is not chattering all the time, and webpages load ten times as fast. So I think there are many other issues with Firefox. Maybe it's an interaction with Norton 360, but the disc was forever chattering before, and is totally silent now that Firefox is gone.

Comment 24

[Reginald Allen]

I have some questions and a couple of comments regarding this issue or (bug, if that is what it is).  
My first question is does this problem result from a necessary improvement/upgrade to Firefox?  
If it does, must we assume that the problem will continue to exist in future versions of Firefox?
If it is a bug; bugs happen, then fix it.  
If it is part of a necessary change, then it would be nice to have some sort of workaround, so that XP-ers can keep up with improvements when they are made to Firefox.
Now, to the comments.  I was copied on an Email, apparently between Mozilla people, one of which thought that fixing this problem wasn't worth a lot of hustle.  And, I quote:  "I'm not sure we'd want to chemspill for it, though, especially given that it only seems to affect a limited number of Windows XP users." I'd love to have a pole to find out how many people stuck with XP because it finally became a stable operating system. Is that truly the attitude of people at Mozilla?

Comment 25

[PaulDent]

I am typical of professional users who cannot move on from XP because of the number of expensive software packages like CAD tools, compilers, IDEs etc that would all have to be repurchased and reinstalled to work on windows 7, 8 or 10, if even available for those operating systems. It would be thousands of bucks and weeks of work, plus going up the re-learning curve for all users. Windows 7 and 8 will soon cease to be supported, and Windows 10 does not run XP programs, so uSoft is totally screwing us up. uSoft needs to release an operating system that is totally compatible with everything back to Windows 98, which I still have to have for driving lab instruments because permissions for user programs to drive the ports was prevented from XP onwards, although there are some hacks for this. I know people in plant maintenance in big commercial installations have to do the same and carry XP around installed on a Flash drive for this reason. Many accountants have to stick with XP for similar reasons. They need legacy programs to read legacy data back to the year dot. Some even have XT machines with 5 1/4" floppy drives! 
The reason I installed Firefox was that you cannot install anything past IE8 on XP, and many websites now refuse to talk to XP. We need truly ANONYMOUS BROWSING, where the website cannot deduce what machine, OS or browser you are using. To let them know this is a security breach in my opinion. It lets them know exactly which virus version to send you. They do not need to know this info if they would stick to Standard web protocols, but you can bet that uSoft is putting things in their webpage editing and server software that will deliberately skirt any standard to screw other browsers.  We need a Web Standards authority to take over standards and police compatibility, like the TIA does for cellphones. Maybe Trump's cyber-security people will see the light and do something.

Right now, every upgrade of every software package seems to be getting worse than the previous one. Software quality is going down, maybe due to a generation-shift in programmers?

Comment 26

[Marco Castelluccio [:marco]]

(In reply to Reginald Allen from comment #24)
> I have some questions and a couple of comments regarding this issue or (bug,
> if that is what it is).  
> My first question is does this problem result from a necessary
> improvement/upgrade to Firefox?  
> If it does, must we assume that the problem will continue to exist in future
> versions of Firefox?
> If it is a bug; bugs happen, then fix it.  
> If it is part of a necessary change, then it would be nice to have some sort
> of workaround, so that XP-ers can keep up with improvements when they are
> made to Firefox.
> Now, to the comments.  I was copied on an Email, apparently between Mozilla
> people, one of which thought that fixing this problem wasn't worth a lot of
> hustle.  And, I quote:  "I'm not sure we'd want to chemspill for it, though,
> especially given that it only seems to affect a limited number of Windows XP
> users." I'd love to have a pole to find out how many people stuck with XP
> because it finally became a stable operating system. Is that truly the
> attitude of people at Mozilla?

You are quoting a message from this bug, not some secret conversation :)

There are better and simple solutions for this that don't require a new Firefox build to be released!
We are in touch with Norton and they are working on fixing this.

Comment 27

[John Thompson]

Thanks for the details.

I'm running XP SP3 5.1.2600, Ffx 51.0.1 and NIS 22.9.0.68 (Norton Security Toolbar 2017.9.0.2)

There's (at least one) thread on this problem on the NIS forum (also reported by Jim Mathies):
https://communityjp.norton.com/en/forums/task-manager-gone-mad-conathstexe

Consensus on workaround is to disable Norton Security Toolbar extension.

I'm not saying I recommend that, but it's the option I went for.

If / when Norton come up with a patch it would be useful to report that here so we know. Thanks.

Comment 29

[dzz1234]

It SEEMS that the problem is now RESOLVED (I filed the bug here).
After I updated the Norton software (running "liveupdate") (At least to me and from what I've read to others).

Norton Security Toolbar is enabled in firefox 51.0.1 on Win XP SP3
and only one conathst.exe in the Task Manager.

Thanks again for your time.

Comment 30

[John Thompson]

Looks OK for me too.