1219253 - MozCrashReason: MOZ_CRASH(Accessing the Subject Principal without an AutoJSAPI on the stack is forbidden) [@ nsContentUtils::SubjectPrincipal ]

Status: RESOLVED DUPLICATE of bug 773429

(Thunderbird :: General, defect)

Description

[Bob Clary [:bc] (inactive)]

Updated to belated Thunderbird Daily 44.0a1 BuildID=20151028030206 on Linux x86_64.

Prompted for master password, then crash.

Crashed with MOZ_CRASH(Accessing the Subject Principal without an AutoJSAPI on the stack is forbidden)

bp-476986e0-6acf-40c5-a47a-a72bc2151028

:-(

Comment 1

[Wayne Mery (:wsmwk)]

(In reply to Bob Clary [:bc:] from comment #0)
> Updated to belated Thunderbird Daily 44.0a1 BuildID=20151028030206 on Linux
> x86_64.
> 
> Prompted for master password, then crash.
> 
> Crashed with MOZ_CRASH(Accessing the Subject Principal without an AutoJSAPI
> on the stack is forbidden)
> 
> bp-476986e0-6acf-40c5-a47a-a72bc2151028

 0 	libxul.so	nsContentUtils::SubjectPrincipal()	dom/base/nsContentUtils.cpp
1 	libxul.so	nsContentUtils::IsCallerChrome()	dom/base/nsContentUtils.cpp
2 	libxul.so	nsContentUtils::IsImageSrcSetDisabled()	dom/base/nsContentUtils.cpp
3 	libxul.so	mozilla::dom::HTMLImageElement::SetAttr(int, nsIAtom*, nsIAtom*, nsAString_internal const&, bool)	dom/html/HTMLImageElement.cpp
4 	libxul.so	nsXMLContentSink::AddAttributes(char16_t const**, nsIContent*)	dom/xml/nsXMLContentSink.cpp
5 	libxul.so	nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, bool)	dom/xml/nsXMLContentSink.cpp
6 	libxul.so	nsExpatDriver::HandleStartElement(char16_t const*, char16_t const**)	parser/htmlparser/nsExpatDriver.cpp
7 	libxul.so	doContent	parser/expat/lib/xmlparse.c
8 	libxul.so	contentProcessor	parser/expat/lib/xmlparse.c
9 	libxul.so	doProlog	parser/expat/lib/xmlparse.c

Comment 2

[Kent James (:rkent)]

That issue is an assert that was added to debug builds (going to telemetry on release builds) for a proposed change in security management, looking for sources that might not like that change. I'll mark a dependency so that they see this.

Comment 3

[Jorg K (CEST = GMT+2)]

Kent didn't tell us where, but here it is:
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsContentUtils.cpp#2717

Comment 4

[Jorg K (CEST = GMT+2)]

(In reply to Bob Clary [:bc:] from comment #0)
> Updated to belated Thunderbird Daily 44.0a1 BuildID=20151028030206 on Linux
> x86_64.
> Prompted for master password, then crash.

How do you reproduce this? I compiled a debug build from current trunk just now, 10 Nov 2015, 21:00 (GMT+1) and don't see the problem. I added a master password and I get prompted when starting TB before e-mail is retrieved from the server. I also get prompted when editing saves passwords.

Can someone else try this on a Daily.

Comment 5

[Bob Clary [:bc] (inactive)]

I'm not sure why this isn't reproducible. I can easily reproduce using a nightly Daily build downloaded from http://archive.mozilla.org/pub/thunderbird/nightly/2015/11/2015-11-19-03-02-39-comm-central/thunderbird-45.0a1.en-US.linux-x86_64.tar.bz2

I tried with safe mode and still got the same crash.

Usually I am switching from a Thunderbird Beta build now since that is the most recent one that will work for me any more. So,...

1. Start Thunderbird
2. Select the defaults which Thunderbird will handle (email, news, etc)
3. Enter master password
4. Crash.

bp-cd160645-9a90-4bad-8bc7-7873d2151119
bp-0cf48bd5-9cde-4691-9f34-eb3b72151119
bp-d2deec1b-c4dc-457a-a238-863fc2151119
bp-47ac33e1-eb43-49af-8121-131472151119

Have you tried a release build instead of a debug build?

Comment 6

[Jorg K (CEST = GMT+2)]

I have a local debug build on Windows.

Please describe *all* the steps to reproduce the bug starting with a *new* profile. What you wrote makes no sense.

"Select the defaults which Thunderbird will handle" only comes up on first start. But on first start there is no master password. For a master password you need to start, create an account, then set the master password. Then maybe start TB again, but then you won't get the "defaults" prompt again.

Comment 7

[Bob Clary [:bc] (inactive)]

(In reply to Jorg K (GMT+1) [currently frustrated by waiting for reviews/feedback] from comment #6)
> I have a local debug build on Windows.
> 

This bug was reported on Linux x86_64.

> Please describe *all* the steps to reproduce the bug starting with a *new*
> profile. What you wrote makes no sense.
> 

Thanks for being insulting.

> "Select the defaults which Thunderbird will handle" only comes up on first
> start. But on first start there is no master password. For a master password
> you need to start, create an account, then set the master password. Then
> maybe start TB again, but then you won't get the "defaults" prompt again.

I never mentioned creating a new profile. This is with an existing profile and I gave you the exact steps I used to reproduce when switching from Thunderbird Beta though switching is not required nor is the setting of the values in the System Integration dialog. The crash does occur just after I enter the master password however.

It does not reproduce with a fresh, empty profile and a single account.

The profile where it does reproduce has an account on bclary.com, two gmail accounts (one associated with my mozilla.com address), a number of subscriptions to rss feeds. It still reproduces in safe mode.

Comment 8

[Magnus Melin [:mkmelin]]

(In reply to Jorg K (GMT+1) [currently frustrated by waiting for reviews/feedback] from comment #6)
> "Select the defaults which Thunderbird will handle" only comes up on first
> start. 

The system integration dialog comes up also if some other app or another version of thunderbird is the default mail app. (If the pref to ask in such cases is set; it is by default)

Comment 9

[Jorg K (CEST = GMT+2)]

In principle, Linux and Windows debug builds should behave the same.

I apologise if any of my comments was badly received. What you said indeed made no sense to me since I only ever see the integration dialogue on a first start on a new profile. Thanks, Magnus, for the hint.

Look, Thunderbird developers have very little time in general. So it would greatly help if you could indeed present a reproducible case starting from scratch with a new profile. If, as you said, this doesn't reproduce "with a fresh, empty profile and a single account" how do you expect anyone to reproduce it?

Sometimes a user reporting a bug needs to invest some work narrowing the bug down since we don't know the exact circumstances. And since you've been a Mozillian for 15 years, I'm not telling you anything new here ;-)

To track down the bug, we need to make it happen first. We know where it's caused, see comment #3, but we don't know, or at least I don't know, how to get there. Your cooperation would be greatly appreciated.

Comment 10

[Bob Clary [:bc] (inactive)]

I'll see if I can get a Thunderbird build environment working and capture the crash.

Comment 11

[Bob Clary [:bc] (inactive)]

fwiw, I did a debug Thunderbird trunk build on Linux x86_64 (Fedora 22) and reproduced the crash with my normal profile. If you would like to remotely drive me in gdb, we can arrange a time to do so. Looking at the originally reported stacks and the current one (which is very similar), I wonder which of the prefs I have set may be involved. I'll try to twiddle some prefs and see if I can make the crash happen with a test account later.

Comment 12

[Jorg K (CEST = GMT+2)]

Great, but sadly I'm not a Linux guy and never used "gdb".

The crash is pretty well defined, we know where it crashes (with intent) and what the stack is:
https://crash-stats.mozilla.com/report/index/476986e0-6acf-40c5-a47a-a72bc2151028

I'm just wondering what it's digging around in mozilla::dom::HTMLImageElement::SetAttr() for. That's why I wanted some reproducible steps.

But I think I've found the problem anyway, look at frame 2 of the crash and click on the source "dom/base/nsContentUtils.cpp". There we see:

nsContentUtils::IsImageSrcSetDisabled()
  return Preferences::GetBool("dom.disable_image_src_set") && !IsCallerChrome();
}

If you have preference dom.disable_image_src_set set to the default, 'false', it will return after evaluating the first part of the expression to 'false'. If you have that preference set to 'true', it must evaluate the second part and then crashes in IsCallerChrome();

Perhaps you can check the preference for me. And then, if your time permits, get steps to reproduce starting with a fresh profile ;-). One of the steps will be "Set dom.disable_image_src_set to true".

Thanks for your patience!

Comment 14

[Jorg K (CEST = GMT+2)]

Thanks Robert for getting us onto the right track here.