1395104 - Crash in NS_CycleCollectorSuspect3 when uploading a video with a screenreader active

Status: RESOLVED DUPLICATE of bug 1379913

(Core :: Disability Access APIs, defect, P2)

Description

[Giuseppe Di Grande]

This bug was filed from the Socorro interface and is 
report bp-6781e7ba-ed35-4162-824e-313cd0170830.
=============================================================

I've opened my Facebook page and upload a video.
Crash occurs randomly.
An assumption that I have verified today. With a video I had already posted crash did not occur. Then I posted a new video and the crash reappeared.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

There is some fsdomnodeiatext.dll on stack. 
Doesn't seem to be Firefox issue but some issue with some software coming from http://www.freedomscientific.com/ perhaps?

Comment 2

[Giuseppe Di Grande]

FsDom is a component of my active screen reader (Jaws). I've tryed with other screen reader (Nvda) and I've generate a new crash. But for netiquette I cannot send it again to Bugzilla. The crash of Firefox I suspect it is due to something about the browser cache, because it occurs more often only when new videos are posted. But I'm not a Firefox expert so i can not be sure of it.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

The stack trace strongly hints something going wrong in fsdomnodeiatext.dll

Comment 4

[Giuseppe Di Grande]

If you can see this new crash, without screen reader. bp-0f67fbd3-5ba5-464d-8403-db4820170830

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

fsdomnodeiatext.dll is still there.

Comment 6

[Giuseppe Di Grande]

However, I posted here the bug to try to solve it with you of the team. As far as I'm concerned, I can safely upload my videos using Google Chrome. If you believe the bug is due to a screen reader component, please contact Freedom Scientific and resolve the issue together.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Perhaps David has some contacts to them?

Comment 8

[Marco Zehe (:MarcoZ)]

FSDOMNodeIAText.dll is definitely a component of JAWS. David, when you next talk to them, ask if one of the fixes they did for us recently is in this module.

Giuseppe, which version of JAWS are you using?

Comment 9

[Giuseppe Di Grande]

Jaws 18.2740. However when I've closed Jaws and open Nvda the bug has remained. Ok, the dll module was injected inside the Firefox process, but I'd closed and reopen Firefox. And the thing most important, when I upload a video until to end, the next few times that upload the same video Firefox does not crash. Firefox crash only with new video that I upload. If I try to replay until the video is completed, after that video I can charge it without problems as often as I want. If Jaws have a bug because it does not always happen? Unfortunately I do not have people available to try without screen reader. I try to close Jaws after I start upload, and Firefox crash. I could create something to detached a dll from Firefox process, but I can not get to do such a thing and waste time for such this problem.

Comment 10

[David Bolter [:davidb] (NeedInfo me for attention)]

More stacks (8 distinct installations) where Jaws is involved, notably all in 56 beta:

bp-4c06e8ad-84de-4815-89e9-65e070170831 	56.0b7 	0x2
bp-ea1c6b3c-5828-4f61-81aa-469940170828 	56.0b6 	0x2
bp-1469c751-db2a-4d64-a507-8714b0170828 	56.0b6 	0x2
bp-b66b49fd-ded7-4a5e-94ea-ef1a70170828 	56.0b6 	0x2
bp-25175082-11e2-4e77-9a0a-9bd420170828 	56.0b6 	0x2
bp-70375f91-b122-485d-a5fd-1ad350170828 	56.0b6 	0x2
bp-56244312-0409-4ce9-bc31-c7ec30170828 	56.0b6 	0x2
bp-92d9a9d4-092f-4411-a7a8-acdb00170828 	56.0b6 	0x2
bp-ae5c1b83-a4d5-4227-b0d1-ca1770170828 	56.0b6 	0x2
bp-960fa4e8-1e7b-4280-a382-e79500170826 	56.0b5 	0x2
bp-ed527ae0-140e-469f-a669-2c59e0170826 	56.0b5 	0x2
bp-d80871a2-7d79-4960-910c-34f900170825 	56.0b5 	0x2

Liz do any 56 b5 uplifts jump out at you?

Marco, Jaws multi fixes probably unrelated -- although please add any thinking I might be missing here. If you get a chance maybe you can try to catch this crash on 56 via one of the crashing URLs: http://keepvid.com/pop-up

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Here's what landed in between beta 4 and beta 5: https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=FIREFOX_56_0b4_RELEASE&tochange=FIREFOX_56_0b5_RELEASE

Maybe bug 1350637?  Jan, you had some big changes land for beta 5 from that and Bug 1283609. Can you take a look? I am only guessing.

Comment 12

[Jan Varga [:janv]]

Hm, the stack traces don't seem to be related to changes made in bug 1350637 or bug 1283609.

Comment 13

[Giuseppe Di Grande]

Last night I renamed the FSDomNodeIAText.dll file. Seemed to work properly. Jaws allows you to use Firefox, but that is an important component for reading web editbox. Next sunday, when upload a new video on my Facebook page, I will try to rename it again and I'll see how it goes.
When I upload the same video on my Youtube channel everything works properly.
Sometimes the crash also occurred when I uploaded a photo using Facebook mobile (m.facebook.com).
Will it be the curse of Facebook pharaoh?

Comment 14

[Gerry Chang [:gchang]]

The volume of crashes in 56 seems low, mark 56 won't fix for now. Feel free to nominate tracking request for 57.

Comment 15

[Jim Mathies [:jimm]]

a11y only search, which covers about half of the reports - 

https://crash-stats.mozilla.com/search/?signature=%3DNS_CycleCollectorSuspect3&accessibility=__true__&product=Firefox&date=%3E%3D2017-10-16T19%3A08%3A00.000Z&date=%3C2017-10-23T19%3A08%3A00.000Z&_sort=-date&_facets=signature&_facets=accessibility&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-accessibility

Comment 16

[(No longer employed by Mozilla) Aaron Klotz]

In many of these reports I see jaws calling Release on our accessibles from the wrong thread.

We should probably add more checks to our IUnknown implementation to ensure that the caller is using the correct thread, though in the AddRef/Release case that might cause leaks or other problems... maybe in that case we should post a runnable instead?

Comment 17

[James Teh [:Jamie]]

(In reply to Giuseppe Di Grande from comment #2)
> FsDom is a component of my active screen reader (Jaws). I've tryed with
> other screen reader (Nvda) and I've generate a new crash. But for netiquette
> I cannot send it again to Bugzilla.

Can you reproduce the crash with NVDA (without having loaded JAWS) and provide the crash id here? That might be enlightening.

Comment 18

[James Teh [:Jamie]]

(In reply to Aaron Klotz [:aklotz] from comment #16)
> In many of these reports I see jaws calling Release on our accessibles from
> the wrong thread.

It's interesting that we're seeing __ClientCallWinEventProc in these stacks. That suggests a win event got fired and that JAWS was responding to it, presumably releasing accessibles as a result. The question is: what win event? I don't see any Gecko code firing a win event, so it must be a system win event, perhaps a destroy event for an HWND. But what HWND?

Comment 19

[(No longer employed by Mozilla) Aaron Klotz]

(In reply to James Teh [:Jamie] from comment #18)
> But what HWND?

Not one of ours, that's for sure.

Comment 20

[David Bolter [:davidb] (NeedInfo me for attention)]

Pinging Giuseppe for comment 17.

Comment 21

[(No longer employed by Mozilla) Aaron Klotz]

Deassigning myself from this. Jamie and I have discussed this in the past and we believe that, in addition to engagement with affected clients, we should probably implement Comment 16 for robustness.

For QI we should return RPC_E_WRONG_THREAD when the thread is wrong. OTOH, AddRef and Release don't return HRESULTs, so we'll have to probably make those silently work via posting runnables to the main thread.

Comment 22

[alexander :surkov (:asurkov)]

it appears this one is a dupe of bug 1379913