Closed Bug 1395104 Opened 7 years ago Closed 6 years ago

Crash in NS_CycleCollectorSuspect3 when uploading a video with a screenreader active

Categories

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

Product:
Core
Component:
Disability Access APIs
Platform:
x86
Windows 7
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1379913
Tracking Flags:
Tracking Status
firefox56 + wontfix
firefox57 --- affected

People

(Reporter: giuseppe, Unassigned)

References

Details

(Keywords: crash, crashreportid, Whiteboard: aes+)

Crash Data

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.
Blocks: 1151643
Component: Untriaged → XPCOM
Keywords: crash, crashreportid
Product: Firefox → Core
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?
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
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.
The stack trace strongly hints something going wrong in fsdomnodeiatext.dll
If you can see this new crash, without screen reader. bp-0f67fbd3-5ba5-464d-8403-db4820170830
fsdomnodeiatext.dll is still there.
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.
Perhaps David has some contacts to them?
Flags: needinfo?(dbolter)
Status: RESOLVED → REOPENED
Component: XPCOM → Other
Ever confirmed: true
Product: Core → External Software Affecting Firefox
Resolution: INVALID → ---
Summary: Crash in NS_CycleCollectorSuspect3 → Crash in NS_CycleCollectorSuspect3 when uploading a video with a screenreader active
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?
Flags: needinfo?(giuseppe)
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.
Flags: needinfo?(giuseppe)
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
Flags: needinfo?(dbolter) → needinfo?(lhenry)
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.
status-firefox56: --- → affected
tracking-firefox56: --- → +
Flags: needinfo?(lhenry) → needinfo?(jvarga)
Hm, the stack traces don't seem to be related to changes made in bug 1350637 or bug 1283609.
Flags: needinfo?(jvarga)
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?
The volume of crashes in 56 seems low, mark 56 won't fix for now. Feel free to nominate tracking request for 57.
status-firefox57: --- → affected
Component: Other → Disability Access APIs
Flags: needinfo?(aklotz)
Priority: -- → P2
Product: External Software Affecting Firefox → Core
Whiteboard: aes+
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?
Flags: needinfo?(aklotz)
Assignee: nobody → aklotz
Status: REOPENED → ASSIGNED
(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.
(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?
(In reply to James Teh [:Jamie] from comment #18)
> But what HWND?

Not one of ours, that's for sure.
Pinging Giuseppe for comment 17.
Flags: needinfo?(giuseppe)
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.
Assignee: aklotz → nobody
Status: ASSIGNED → NEW
it appears this one is a dupe of bug 1379913
Status: NEW → RESOLVED
Closed: 7 years ago → 6 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(giuseppe)
You need to log in before you can comment on or make changes to this bug.