842473 - crash in mozilla::dom::FragmentOrElement::CanSkip with FoxyProxy 4.2

Status: RESOLVED INVALID

(Firefox :: Extension Compatibility, defect)

Description

[Scoobidiver (away)]

It's #6 top browser crasher in 19.0b6 on Mac OS X.

It's correlated to FoxyProxy 4.2.

Signature 	@0x0 | mozilla::dom::FragmentOrElement::CanSkip(nsINode*, bool) More Reports Search
UUID	8f1cbaed-f3de-41ef-a592-c4cf12130218
Date Processed	2013-02-18 09:40:03
Uptime	59
Last Crash	more than 3 months before submission
Install Age	1.8 days since version was first installed.
Install Time	2013-02-16 14:09:26
Product	Firefox
Version	19.0
Build ID	20130212082553
Release Channel	beta
OS	Mac OS X
OS Version	10.6.8 10K549
Build Architecture	amd64
Build Architecture Info	family 6 model 23 stepping 10
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0x0
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x 863GL Context? GL Context+ GL Layers? GL Layers+ 
Processor Notes 	sp-processor02.phx1.mozilla.com_19469:2008; exploitablity tool: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x 863

Frame 	Module 	Signature 	Source
0 		@0x0 	
1 	XUL 	mozilla::dom::FragmentOrElement::CanSkip 	content/base/src/FragmentOrElement.cpp:1425
2 	XUL 	nsDocument::cycleCollection::CanSkipImpl 	content/base/src/nsDocument.cpp:1525
3 	XUL 	UnmarkJSHolder 	nsCycleCollectionParticipant.h:209
4 	XUL 	PL_DHashTableEnumerate 	obj-firefox/x86_64/xpcom/build/pldhash.cpp:717
5 	XUL 	xpc_UnmarkSkippableJSHolders 	nsBaseHashtable.h:221
6 	XUL 	nsCCUncollectableMarker::Observe 	content/base/src/nsCCUncollectableMarker.cpp:390
7 	XUL 	nsObserverList::NotifyObservers 	xpcom/ds/nsObserverList.cpp:99
8 	XUL 	nsObserverService::NotifyObservers 	xpcom/ds/nsObserverService.cpp:161
9 	XUL 	nsCycleCollector_forgetSkippable 	xpcom/base/nsCycleCollector.cpp:2150
10 	XUL 	CCTimerFired 	dom/base/nsJSEnvironment.cpp:3118
11 	XUL 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:482
12 	XUL 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:565
13 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:627
14 	XUL 	NS_ProcessPendingEvents_P 	obj-firefox/x86_64/xpcom/build/nsThreadUtils.cpp:188
15 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/xpwidgets/nsBaseAppShell.cpp:97
16 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/cocoa/nsAppShell.mm:387
17 	CoreFoundation 	__CFRunLoopDoSources0 	
18 	CoreFoundation 	__CFRunLoopRun 	
19 	CoreFoundation 	CFRunLoopRunSpecific 	
20 	HIToolbox 	HIToolbox@0x2e7ee 	
21 	HIToolbox 	HIToolbox@0x2e551 	
22 	HIToolbox 	HIToolbox@0x2e4ac 	
23 	AppKit 	_DPSNextEvent 	
24 	AppKit 	-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 	
25 	XUL 	-[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] 	widget/cocoa/nsAppShell.mm:164
26 	AppKit 	-[NSApplication run] 	
27 	XUL 	nsAppShell::Run 	widget/cocoa/nsAppShell.mm:741
28 	XUL 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:290
29 	XUL 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3823
30 	XUL 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3890
31 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4084
32 	firefox 	main 	browser/app/nsBrowserApp.cpp:174
33 	firefox 	start 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=%400x0+|+mozilla%3A%3Adom%3A%3AFragmentOrElement%3A%3ACanSkip%28nsINode*%2C+bool%29

Comment 1

[Alex Keybl [:akeybl]]

Anthony - can you try reproducing?

Comment 2

[u279076]

There are three different flavours of FoxyProxy with varying version numbers.

FoxyProxy Basic (free):
Latest available version is 3.1.3 via AMO (v3.2 is pending review)

FoxyProxy Standard (free):
Latest available version is 3.2 via AMO

FoxyProxy Plus (paid):
Latest available version is 5.2 via getfoxyproxy.org

I've tested either free versions and have been unable to reproduce.  If this is correlated to FoxyProxy 4.2 then it is correlated to a paid product which was released on September 8, 2011 (17 months out of date).

I'd like us to perform some outreach before I take the step of spending money on a product which may or may not reproduce this bug. I can only buy the latest version and there have been 12 FoxyProxy Plus releases since FoxyProxy Plus 4.2.

Comment 3

[Georg Koppen]

Attachment: Disabled FoxyProxy Standard 4.2

Comment 4

[Georg Koppen]

The currently available versions are

FoxyProxy Basic 3.1.3
FoxyProxy Standard 4.1.3
FoxyProxy Plus 5.2

FoxyProxy Standard 4.2 and FoxyProxy Basic 3.2 got released last Saturday (I guess FoxyProxy 4.2 in the first comment is referring to FoxyProxy Standard 4.2). Both got meanwhile disabled by us (FoxyProxy team) due to a usability issue that is quite annoying to our users and which we are still trying to reproduce and understand. I add that version to help you investigate the crash issue.

If there is more I can do let me know. We are usually hanging out at least on #foxyproxy but on some other Mozilla IRC channels as well (GeKo is my nick).

Comment 5

[Scoobidiver (away)]

Correlations per version are:
    100% (18/18) vs.   7% (34/481) [e-mail] (FoxyProxy, https://addons.mozilla.org/addon/2464)
          0% (0/18) vs.   0% (1/481) 4.1.3
        100% (18/18) vs.   7% (33/481) 4.2

Comment 6

[Scoobidiver (away)]

There's a Windows version of crashes:
https://crash-stats.mozilla.com/report/list?signature=nsIDocument%3A%3AGetExtraPropertyTable%28unsigned+short%29

Comment 7

[Alex Keybl [:akeybl]]

(In reply to Georg Koppen from comment #4)
> FoxyProxy Standard 4.2 and FoxyProxy Basic 3.2 got released last Saturday (I
> guess FoxyProxy 4.2 in the first comment is referring to FoxyProxy Standard
> 4.2). Both got meanwhile disabled by us (FoxyProxy team) due to a usability
> issue that is quite annoying to our users and which we are still trying to
> reproduce and understand. I add that version to help you investigate the
> crash issue.

Can you provide Anthony (Mozilla QA) with test vpn/proxy subscriptions to use with FoxyProxy?

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #2)
> FoxyProxy Standard (free):
> Latest available version is 3.2 via AMO

Anthony - can you try retesting with the attachment from comment 3 once we have access to a test proxy?

Comment 8

[Eric Jung [:ericjung]]

(In reply to Alex Keybl [:akeybl] from comment #7)

> Can you provide Anthony (Mozilla QA) with test vpn/proxy subscriptions to
> use with FoxyProxy?

This should be in Anthony's email now from Kensie. Please kindly keep the info (ip address, port, username, password) private as it is a paid service.

Comment 9

[u279076]

I've been trying with the attached extension and the credentials provided to me but have not yet experienced a crash. The comments seem to indicate Google+, Ebay, and Fogs Bugz and that's what I've been trying, but no crash yet. That said, I am on OSX 10.7 which does not represent the majority of the crashes. 

I'm wondering if someone with Mac OSX 10.8 can give this a try. Can someone who I can trust to share the credentials with please identify themselves?

Alternatively, I'll have to try upgrading my Mac to test further.

Comment 10

[juan becerra [:juanb]]

I have been trying to reproduce this on 10.8 just browsing around sites as mentioned in comment #9, but so far no luck. I've email a couple of people and asked them for further information including their foxyproxy.xml file (configuration settings) which may help the add-on's devs diagnose this.

Comment 11

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

The stack trace doesn't look too useful.
Somehow we're apparently crashing when accessing null root, but we have had a null check for
root just few lines above.

Comment 12

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

Also, the relevant code seems to have been in the releases since firefox 16.

Comment 13

[juan becerra [:juanb]]

Attachment: about support information from one of the users who experienced this crash

The user also sent us the foxyproxy.xml settings file, and I will send out to the add-on developer for investigation.

Comment 14

[Georg Koppen]

I've tried to reproduce the crash with the about:support information attached to this bug and the user's foxyproxy.xml and his instructions where/under which circumstances the crash happened but still no luck. We'll see if the first debug version I've sent to him today gives some clues on what is going on here. Additionally, I've asked him whether he could install the problematic FoxyProxy 4.2 in a clean, new profile to rule out possible interferences with other add-ons/old settings.

Comment 16

[Sandy Armstrong]

The crashes started for me after installing "MacBook Pro SMC Firmware Update" 1.7 on OS X 10.8.2.

Comment 17

[Georg Koppen]

The first feedback of users helping us to narrow down the issue indicates that the code responsible for hooking the authentication dialog is at least involved in the crashes. It is here:

https://fisheye2.atlassian.com/browse/foxyproxy/tags/4.2/src/modules/authPromptProvider.jsm?r=1381

and it gets executed if the http-on-modify-request observer gets notified:

https://fisheye2.atlassian.com/browse/foxyproxy/tags/4.2/src/components/foxyproxy.js?r=1390#to1854

The purpose of the code is to save the user credentials per proxy in FoxyProxy and enter them automatically if they are needed without the authentication dialog popping up anymore.

The only thing that changed in the debug version I sent to the users was disabling the authentication feature if FoxyProxy itself is disabled (a thing I forgot in 4.2). With this change it seems FoxyProxy is only crashing if it is enabled, i.e. that feature is active.

If there are still no bells ringing what could go wrong here I'd need some specific things that we/the testers should do to track the issue further down.

Comment 18

[u279076]

Can we get a Mozilla engineer to have a look at the code mentioned in comment 17 to see if there are any ideas why that might be causing this crash?

In the meantime, Georg, is there anything Mozilla QA can be doing to assist in further debugging this issue?

Comment 19

[Georg Koppen]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #18)
> In the meantime, Georg, is there anything Mozilla QA can be doing to assist
> in further debugging this issue?

Unfortunately not. I think we need some Mozilla engineer to look at the new evidence as we are not familiar enough with the interaction between the problematic and the underlying Mozilla code. At least not familiar enough to give proper advice to the users helping us to narrow down the issue even further.

Comment 20

[u279076]

Okay, thank you Georg. I'm dropping QAWANTED from this bug in the meantime. I've asked Release Management to find a Mozilla engineer to look into this further.

Comment 21

[Alex Keybl [:akeybl]]

Olli - do you have the cycles to take a look at comment 17?

Comment 22

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

I'm not familiar with http-on-modify-request, but my guess is that AuthPromptProvider
ends up being called at unsafe time. Or more exactly, AuthPromptProvider ends up modifying DOM
at unsafe time by opening a dialog.
Has anyone familiar with the addon used it in a debug build? Do you get assertions?

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

Adding qawanted back - can someone try with a debug build to check for assertions?

Comment 24

[u279076]

I've not had any luck yet triggering a crash with the 2013-02-16 Firefox 19.0 mozilla-release-debug build. What kind of browsing behaviour triggers the following code?

> https://fisheye2.atlassian.com/browse/foxyproxy/tags/4.2/src/modules/authPromptProvider.jsm?r=1381

I've tried logging in to several websites and have not seen any FoxyProxy authentication dialogs appear.

Comment 25

[Georg Koppen]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #24)
> What kind of browsing behaviour triggers the following code?
> 
> > https://fisheye2.atlassian.com/browse/foxyproxy/tags/4.2/src/modules/authPromptProvider.jsm?r=1381
> 
> I've tried logging in to several websites and have not seen any FoxyProxy
> authentication dialogs appear.

You have to have use a proxy that needs a username/password (looking at comment 9 you got already credentials). Logging into websites is not handled by FoxyProxy. What FoxyProxy does (ideally) is this: Let's assume you are using a proxy that needs credentials. If there is a request FoxyProxy tries to avoid the authentication dialog: it applies the username/password saved in FoxyProxy. If there aren't any yet, e.g. it is the first request with that proxy FoxyProxy calls promptAuth() and saves the values entered.

That said, at least one of the users helping us said that the authentication feature is not used. Thus, no username/password dialogs at all, but Firefox is crashing though. I've asked both of them to run the crashing FoxyProxy in a release/nightly debug build and send me the output.

Comment 26

[Georg Koppen]

Attachment: Windows assertion log

Comment 27

[Georg Koppen]

Attachment: Linux assertion log

Comment 28

[Georg Koppen]

Okay, I tested the debug build myself again and can reproduce assertions on all three platforms reliably and on Windows (and only on Windows) I get Firefox reliably crashed. That is definitely related to the authentication feature of FoxyProxy. But I am not sure if it belongs to this bug as one has to use that feature in order to trigger the assertions (and the crash) which neither of the users helping us did. Anyway, steps to reproduce are:

1) Configure FoxyProxy to use a proxy with authentication credentials (enter the credentials when you configure the proxy)
2) Select "Use proxy for all URLs"
3) Close Firefox and restart it
4) Do nothing until the assertion shows up (lasts max 5 minutes) or your Windows computer is crashing.

I have not looked at it yet but I guess some Google Safebrowsing request is triggering this. Note: There is no crash (assertion) for me if I just start browsing with Firefox like one would do normally. Attached are the Windows and Linux logs.

Comment 29

[u279076]

Thanks for the detailed follow up Georg. 

Olli, is this enough to get you started?

Comment 30

[Robert Kaiser]

This is marked tracking+ for 20, which is closing its doors soon. Olli, any news here?

Comment 31

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

I did look at the logs, and nothing interesting there. Though, I don't know how serious the
one about SeekableStreamAtBeginning is.

Comment 32

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

Does anyone know how to reproduce this on linux?

Comment 33

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

Necko devs should perhaps look at this, if this is about http-on-modify-request usage.

Comment 34

[Alex Keybl [:akeybl]]

Patrick - I think you're our proxy guru :)

Comment 35

[Patrick McManus [:mcmanus]]

honza knows the auth stuff much better than I do -so I'm going to ask him to help.

When we did the proxy work (18 iirc) the location of on-modify-request got changed so it is no longer called from asyncOpen .. I know that did bite some people. (it was never a guaranteed property of on-modify-request but it had been like that but its not the kind of thing we can revert without adding a lot of jank). I mention it just in case its relevant.

Comment 36

[Lukas Blakk [:lsblakk] use ?needinfo]

Unfortunately it's too late now for FF20, flagging FF21 tracking.

Comment 37

[Georg Koppen]

Okay, we found another user who is affected by the/a crash on Windows. I asked him to do the following:

1) Download and install a release debug build

ftp://ftp.mozilla.org/pub/firefox/nightly/2013-02-17-mozilla-release-debug/firefox-19.0.en-US.debug-win32.installer.exe

1a) You have to _temporarily_ install Visual C++ 20120 (Express edition
is sufficient) as there are otherwise runtime libraries missing the
debug build needs. You get it from

http://go.microsoft.com/?linkid=9709949

(it takes some time and disk space but it is only temporarily, just
delete it after we investigated and fixed the problem)

2) Open the Console (Windows key + r) move to the directory where the
debug firefox.exe actually is located (with cd .. you can go up one
directory and cd "foobar" (without the quotes) changes the directory to
"foobar")

3) Start the debug build with

firefox.exe > afile 2>&1

and get it crashed with FoxyProxy. Note: "afile" should specify a path
you have permission to write to (somewhere in your user profile
probably) + a file, like "C:\Users\klaus\Desktop\debug.log" (without the
quotes)

4) Please, send me the debug file.

What he did/had installed:

1. start Nightly
2. goto url http://www.artan.nnov.ru/
3. http://www.artan.nnov.ru/site.aspx?IID=1936948&SECTIONID=1935945
4. http://www.artan.nnov.ru/site.aspx?IID=2105710&SECTIONID=1944717
5.
http://www.volkswagen.ru/ru/models/golf_plus/features.s9_trimlevel_detail.suffix.html/golf-plus--2013-~2Ftrendline.html
- new tab is opened, goto new tab
6. http://www.volkswagen.ru/ru/models/golf_plus/configurator.html   -
crashed.

Extensions:
FoxyProxy Standard 4.2
LastPass 2.0.0
SQLite manager 2.7.7
Tab Mix Plus 0.4.0.5
XMarks 4.1.3

He is behind a proxy with authentication and uses a system-wide *.pac file. Needless to say, I was not able to reproduce his crashes mimicking his setup...

BUT: he sent me two crash reports so far with a different assertion than the one I found. I attached both.

Comment 38

[Georg Koppen]

Attachment: Firefox crash on Windows due to FoxyProxy March 20

Comment 39

[Georg Koppen]

Attachment: Firefox crash on Windows due to FoxyProxy March 21

Comment 40

[Boris Zbarsky [:bzbarsky]]

Oh, very interesting.

So both of those have:

###!!! ASSERTION: Clearing a preserved wrapper!: '!PreservingWrapper()', file e:\builds\moz2_slave\m-rel-w32-d-000000000000000000\build\dom\base\nsWrapperCache.h, line 111

Any chance of running under gdb with XPCOM_DEBUG_BREAK=trap and at those callsites doing:

  set print object on
  p this
  bt

?

Comment 41

[Georg Koppen]

Well, the user run Windows, thus running gdb could be tricky. I don't know much about debugging Mozilla on Windows either. I briefly looked at https://developer.mozilla.org/en-US/docs/Debugging_Mozilla_on_Windows_FAQ but that seems to be outdated. What I would need then are detailed steps for debugging this on Windows which I can send to the user...

Comment 42

[Boris Zbarsky [:bzbarsky]]

Ah, right.  I wish I knew more about the Windows debugging setup...

Basically what I want first is the callstack to the assertion, and second if possible the concrete type of the nsWrapperCache object.

Comment 43

[Scoobidiver (away)]

(In reply to Georg Koppen from comment #41)
> I briefly looked at https://developer.mozilla.org/en-US/docs
> /Debugging_Mozilla_on_Windows_FAQ but that seems to be outdated.
The right link is https://developer.mozilla.org/docs/How_to_get_a_stacktrace_with_WinDbg

Comment 44

[Alice0775 White]

Sorry, I do not have anything new...

Comment 45

[u279076]

Boris/Georg, is there anything QA can do to assist your investigation?

Comment 46

[Boris Zbarsky [:bzbarsky]]

Well, if QA can reproduce the bug and then get the information I mention in comment 42...

Comment 47

[u279076]

(In reply to Boris Zbarsky (:bz) from comment #46)
> Well, if QA can reproduce the bug and then get the information I mention in
> comment 42...

QA has been unable to reproduce this issue locally. I've tried the steps in comment 37 but just like Georg I was not able to reproduce.

Comment 48

[Georg Koppen]

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #45)
> Boris/Georg, is there anything QA can do to assist your investigation?

I think so, yes. We have

a) general instructions on how to debug on Windows (see comment 43)
b) a user that is willing to do the debugging for us (he just confirmed that by e-mail)
c) the things that Boris needs (comment 40 and 42)

I need an instruction set that takes a)-c) into account which I can send to the user and which is as easy as possible as I don't know his skills and how patient he is. Something that might start from a), takes into account that the user has a (nightly) debug build and gives me/the user detailed steps on how to reach/get the info Boris needs.

Comment 49

[u279076]

Sorry Georg, I'm not familiar enough with gdb and stack walking to advise you on anything more simplified than the already linked docs. Boris, would you be able to help out here, or know someone who might be able to assist? Would it be possible to have this user work 1:1 with someone at Mozilla who knows more about this stuff?

Comment 50

[Boris Zbarsky [:bzbarsky]]

Kyle, mind brain-dumping some debugging steps here?

Comment 51

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

I don't think there's any need to get the user to use a debugger.  I'll circle back tomorrow with a plan.

Comment 52

[Georg Koppen]

Attachment: Crash log with WinDbg

Comment 53

[Boris Zbarsky [:bzbarsky]]

That shows the stack to the crash, which we already had in comment 0.  We need a stack to the assert...

Comment 54

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Basically we need to do a manual build with a patch that makes the assertion crash and then upload the symbols to socorro.  I'm off on unexpected PTO today but I'll try to make that happen next week.

Comment 55

[Paul Silaghi, QA [:pauly]]

In the last 4 weeks there are no crashes > FF 19.0.2. Perhaps something fixed this in 20 and up.

Comment 56

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Well we're shipping 20 today so we probably just haven't had enough users banging on it.
I still need to find someone from releng to help me implement comment 54.

Comment 57

[Sandy Armstrong]

I've reenabled foxyproxy 4.2 in FF20 (I run beta channel), and haven't had any crashes yet.  Previously they would occur within a couple of hours.  I'll update if I have any issues.

Comment 58

[Sandy Armstrong]

Sorry, it did eventually crash again:

https://crash-stats.mozilla.com/report/index/bp-84af557f-af44-4620-8b9a-77d262130402

Comment 59

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Diagnostic Patch

This applies on top of http://hg.mozilla.org/releases/mozilla-release/rev/f785801b8059

KaiRo, can you produce a debug build for Windows that Georg can use?  The key here is that we need to get the symbols for this build on Socorro so that we can get the callstack for the crash this patch induces.

Comment 60

[Robert Kaiser]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #59)
> KaiRo, can you produce a debug build for Windows that Georg can use?

Only if you can work a few weeks until I re-learned my ways around try and got other higher-priority items off my list. I'm pretty swamped as the CrashKill team has been thinned out by stuff like or FxOS priorities, and I'm extremely rusty in anything around builds as I'm not required to do anything with builds in this job.

If you want anything soon, please find someone else with try access to do that.

Comment 61

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Ah, I think I misinterpreted what Eric Jung said.  I thought he was volunteering you for the work ;-)

Anyways, this needs more than try, because try doesn't upload to Socorro.  If it just needed try I would do it myself ;-)

Comment 62

[Justin Wood (:Callek)]

ben in IRC last week said he was ok finding an owner for this, I don't think I can own in the timeframe hoped for.

Comment 63

[[e-mail] (:bhearsum)]

(In reply to Justin Wood (:Callek) from comment #62)
> ben in IRC last week said he was ok finding an owner for this, I don't think
> I can own in the timeframe hoped for.

I have no memory of this, and no context on this bug...

Comment 64

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

14:29:43 <akeybl> KaiRo: do you have the ability to upload symbols to socorro?
14:29:52 <KaiRo> akeybl: no
14:29:59 <akeybl> anybody besides ted?
14:30:09 <Callek> (possibly me, about to check)
14:30:09 <KaiRo> akeybl: you need ted or bsmedbrg for that, AFAIK
14:30:17 <bhearsum|afk> akeybl: as a one-off, we could probably do a build eith\
er by hand or with some hacks
14:30:19 <Callek> well me proxied from ffxbld
14:30:29 <bhearsum|afk> if releng needs to do it, file a bug and cc me, i'll fi\
nd an owner
14:30:34 <bhearsum|afk> unless callek is volunteering already
14:30:43 <KaiRo> Callek: well, the releng users can, but only symbols from the \
build system are allowed to be uploaded via those accounts
14:30:54 <KaiRo> at least AFAIK
14:31:02 <Callek> bhearsum|afk: well if someone more familiar is good, great...\
 otherwise yea I can do it once the try build is done
14:31:09 <KaiRo> akeybl: what kind of symbols would you need uploaded?
14:31:39 <bhearsum|afk> Callek: i'm not going to volunteer you, pick it up if y\
ou want
14:31:40 <bhearsum|afk> no pressure though
14:31:47  * bhearsum|afk is afk for real now

Comment 65

[bhavana bajaj [:bajaj]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #64)
> 14:29:43 <akeybl> KaiRo: do you have the ability to upload symbols to
> socorro?
> 14:29:52 <KaiRo> akeybl: no
> 14:29:59 <akeybl> anybody besides ted?
> 14:30:09 <Callek> (possibly me, about to check)
> 14:30:09 <KaiRo> akeybl: you need ted or bsmedbrg for that, AFAIK
> 14:30:17 <bhearsum|afk> akeybl: as a one-off, we could probably do a build
> eith\
> er by hand or with some hacks
> 14:30:19 <Callek> well me proxied from ffxbld
> 14:30:29 <bhearsum|afk> if releng needs to do it, file a bug and cc me, i'll
> fi\
> nd an owner
> 14:30:34 <bhearsum|afk> unless callek is volunteering already
> 14:30:43 <KaiRo> Callek: well, the releng users can, but only symbols from
> the \
> build system are allowed to be uploaded via those accounts
> 14:30:54 <KaiRo> at least AFAIK
> 14:31:02 <Callek> bhearsum|afk: well if someone more familiar is good,
> great...\
>  otherwise yea I can do it once the try build is done
> 14:31:09 <KaiRo> akeybl: what kind of symbols would you need uploaded?
> 14:31:39 <bhearsum|afk> Callek: i'm not going to volunteer you, pick it up
> if y\
> ou want
> 14:31:40 <bhearsum|afk> no pressure though
> 14:31:47  * bhearsum|afk is afk for real now

Filed Bug 858392 to help generate the custom builds and get this bug actionable.

Comment 66

[Georg Koppen]

One user just got the build in bug 858392 crashing and sent the report. Hope that helps...

Comment 67

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Georg Koppen from comment #66)
> One user just got the build in bug 858392 crashing and sent the report. Hope
> that helps...

Can the user give us the link to the crash report?

Comment 68

[Georg Koppen]

Here we go:
https://crash-stats.mozilla.com/report/index/bp-36116b2b-4c1c-4158-99f6-75a892130405

Comment 69

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Georg Koppen from comment #68)
> Here we go:
> https://crash-stats.mozilla.com/report/index/bp-36116b2b-4c1c-4158-99f6-
> 75a892130405

Excellent.  I'll take a look at it on Monday morning.

Comment 70

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Assertion stack

Comment 71

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

So we're finalizing a preserved wrapper.  This is really really broken, and strongly suggests memory corruption.  So unfortunately we're back to needing steps to reproduce here.

Comment 72

[u279076]

Georg, can you work with this user to find testable steps to reproduce?

Comment 73

[Denis Stefanov]

Hello, I'm the user Georg working with. I have this issue 100% reproducible.

my setup and scenario is described in comment #37 
If you need any additional info, I'm glad to help.

Thanks,

Comment 74

[u279076]

Welcome Denis. At this point Kyle Huey is looking for steps he can follow to reproduce this issue as you are seeing it so that he can debug a potential fix.

Comment 75

[Georg Koppen]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #71)
> So we're finalizing a preserved wrapper.  This is really really broken, and
> strongly suggests memory corruption.  So unfortunately we're back to needing
> steps to reproduce here.

So, are you saying that the steps outlined in comment 37 are not working for you? And if so, forgive me my ignorance but why is it not possible to proceed with handing out debug builds and getting crash reports in return?

Comment 76

[Alex Keybl [:akeybl]]

No longer a top crash in FF20, untracking for upcoming releases.

Comment 77

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to Georg Koppen from comment #75)
> (In reply to Kyle Huey [:khuey] ([e-mail]) from comment #71)
> > So we're finalizing a preserved wrapper.  This is really really broken, and
> > strongly suggests memory corruption.  So unfortunately we're back to needing
> > steps to reproduce here.
> 
> So, are you saying that the steps outlined in comment 37 are not working for
> you? And if so, forgive me my ignorance but why is it not possible to
> proceed with handing out debug builds and getting crash reports in return?

Comment 37 has steps that you say you weren't able to reproduce with ... why do you think I will be able to?

Comment 78

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Can QA work with this user to get a reproducible setup here?  The interesting parts are probably the proxy and the PAC file.  Once we have something that we know reproduces I can look at the crash.

Comment 79

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Alternatively we can try to get the user to reproduce the crash under valgrind and see if we can glean anything from that ...

Comment 80

[u279076]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #78)
> Can QA work with this user to get a reproducible setup here?  The
> interesting parts are probably the proxy and the PAC file.  Once we have
> something that we know reproduces I can look at the crash.

Before we do that I would like Georg to confirm that he did not already try the same. It's hard for me to justify allocating any more QA resources to this if we are just going to be duplicating failed efforts. Especially considering this is no longer a top crash.

Comment 81

[Denis Stefanov]

Hi All

Just a little update - I'm able to reproduce this out of corporate environment, without *.pac file i.e. direct connection to internet via wifi

Comment 82

[Denis Stefanov]

the scenario is even easier - just goto http://www.volkswagen.ru/ru/models/golf_plus/configurator.html
I'm always having a crash here...

Comment 83

[u279076]

(In reply to Denis Stefanov from comment #82)
> the scenario is even easier - just goto
> http://www.volkswagen.ru/ru/models/golf_plus/configurator.html
> I'm always having a crash here...

Does not reproduce for me. I don't see much point in trying to go back and forth anymore on this bug trying to reproduce this bug internally. I think our time and energy would be better spent trying to get actionable information out of your system, Denis, as long as you are willing.

Can someone from engineering comment as to what information you would need for this to be actionable (apart from steps to reproduce)?

Aside, I'm dropping QAWANTED from this bug since this is no longer a top crasher and it is unlikely that QA can assist further on this bug. Please re-add QAWANTED if something actionable needing QA's assistance comes to light.

Comment 84

[Sandy Armstrong]

Did anybody try testing with a setup similar to what I described in the dupe, bug #845414?

Comment 85

[u279076]

(In reply to Sandy Armstrong from comment #84)
> Did anybody try testing with a setup similar to what I described in the
> dupe, bug #845414?

Sorry but I don't see anything in that bug that is different from what's already been tested in this bug. If you have any information which might help to reproduce this bug please bring it to our attention.

Comment 86

[ivoshm]

I have similar problem on Linux Ubuntu 12.10 amd64 (with Firefox 20.0 and FoxyProxy Standard 4.2) - only a place of crash on stacktrace is slightly different (SIGSEGV in submethod ShouldClearPurple). 

Crash report:
http://crash-stats.mozilla.com/report/index/bp-e8fa6010-2b14-4f7a-b361-c04312130411

Comment 87

[:Gijs (he/him)]

This hit an OS X devtools test on the UX branch today, see bug 923084.

Comment 88

[Jesper Hansen]

Are we still crashing on this? crash-stats seem pretty low 10 on 28 days for https://crash-stats.mozilla.com/report/list?range_unit=days&range_value=28&signature=%400x0+|+mozilla%3A%3Adom%3A%3AFragmentOrElement%3A%3ACanSkip%28nsINode*%2C+bool%29
Where 3 on Firefox 20

Comment 89

[u279076]

There are multiple signatures representative of this crash so looking at just one signature isn't representative of *all* users encountering this issue. That said, looking at all signatures in this bug report I could find a total of 30 crashes in the last week across all Firefox versions. As such, this bug report should remain open but does not meet a threshold for tracking.

> @0x0 | mozilla::dom::FragmentOrElement::CanSkip(nsINode*, bool) => 1 crash
> nsIDocument::GetExtraPropertyTable(unsigned short)] => 10 crashes
> NameSpaceManagerImpl::RegisterNameSpace(nsAString_internal const&, int&) => 0 crashes
> nsINode::DeleteProperty(unsigned short, nsIAtom*) => 19 crashes

Comment 90

[Andy McKay]

With WebExtensions being the only valid way of doing extensions in Firefox 57, I don't think this bug is still relevant.