[gcc 6.1] Crash on start with an homemade thunderbird trunk version and an existing profile. solved with -fno-delete-null-pointer-checks on gcc6

RESOLVED FIXED in Thunderbird 53.0

Status

MailNews Core
Database
--
critical
RESOLVED FIXED
a year ago
4 months ago

People

(Reporter: Frederic Bezies, Assigned: Jorg K (GMT+2))

Tracking

({crash})

Trunk
Thunderbird 53.0
Unspecified
Linux
crash

Thunderbird Tracking Flags

(thunderbird51 wontfix, thunderbird52 fixed, thunderbird53 fixed)

Details

(crash signature, URL)

Attachments

(4 attachments, 2 obsolete attachments)

(Reporter)

Description

a year ago
This bug was filed from the Socorro interface and is 
report bp-a0caeccf-67df-410d-b78e-dfead2160608.
=============================================================
and bp-152951c7-1919-4ff7-aee0-bc7f42160608 and bp-059d934f-fea1-4ef9-92a0-b360d2160608

Unfortuantely this has no symbols, so the bug report is not actionable as is
(Reporter)

Comment 2

a year ago
Will get it build again. I hope this time, I will have debug-symbols too.
(Reporter)

Comment 3

a year ago
Crash-reporter won't launch. But I got a debug log I add to this bug report.
(Reporter)

Comment 4

a year ago
Created attachment 8761269 [details]
debug log related to startup crash.

.mozconfig used :

mk_add_options PYTHON=/usr/bin/python2
mk_add_options AUTOCONF=autoconf-2.13

mk_add_options MOZ_OBJDIR=/home/fred/logs/mail/objdir-tb

ac_add_options --enable-application=mail
ac_add_options --enable-calendar
ac_add_options --with-ccache
ac_add_options --enable-debug
ac_add_options --disable-warnings-as-errors
ac_add_options --enable-debug-symbols
(Reporter)

Comment 5

a year ago
Forget to add : gcc 6.1.1 + Archlinux + linux kernel 4.6
(Reporter)

Comment 6

a year ago
Created attachment 8761276 [details]
gdb backtrace of this crash.

Last info : gdb backtrace. Hope it helps !
(Reporter)

Comment 7

11 months ago
Made another debug build with this .mozconfig file : mk_add_options PYTHON=/usr/bin/python2
mk_add_options AUTOCONF=autoconf-2.13

mk_add_options MOZ_OBJDIR=/home/fred/logs/mail/objdir-tb-debug

ac_add_options --enable-application=mail
ac_add_options --enable-debug
ac_add_options --enable-calendar

export MOZILLA_OFFICIAL=1
export MOZ_DEBUG_SYMBOLS=1

ac_add_options --disable-install-strip
ac_add_options --enable-debug-symbols

I noticed crash *DOES NOT* happen when thunderbird is launched without an existing profile.

Adding another backtrace. Hope it helps.
(Reporter)

Comment 8

11 months ago
Created attachment 8767224 [details]
Another backtrace
(Reporter)

Updated

11 months ago
Summary: Crash in libxul.so@0xa94024 | libxul.so@0xaa1ea0 | libxul.so@0xbac32d | thunderbird@0x12e18 → [gcc 6.1] Crash on start with an homemade thunderbird trunk version and an existing profile.
near zero cases of morkAtom::AliasYarn  in the wild

(In reply to Frederic Bezies from comment #6)
> Created attachment 8761276 [details]
> gdb backtrace of this crash.

#0  0x00007fffe61655c9 in morkAtom::AliasYarn (this=0x0, 
    outYarn=outYarn@entry=0x7fffffffa510)
    at /home/fred/logs/mail/src/db/mork/src/morkAtom.cpp:145
#1  0x00007fffe6174f32 in morkRowObject::AliasCellYarn (this=0x7fffca3382e0, 
    mev=<optimized out>, inColumn=168, outYarn=0x7fffffffa510)
    at /home/fred/logs/mail/src/db/mork/src/morkRowObject.cpp:492
#2  0x00007fffe6309d3c in nsMsgDatabase::RowCellColumnToUInt32 (
    this=<optimized out>, hdrRow=<optimized out>, columnToken=<optimized out>, 
    uint32Result=uint32Result@entry=0x7fffca041d88, 
    defaultValue=defaultValue@entry=4294967295)
    at /home/fred/logs/mail/src/mailnews/db/msgdb/src/nsMsgDatabase.cpp:3768
#3  0x00007fffe6309d61 in nsMsgDatabase::RowCellColumnToUInt32 (
    this=<optimized out>, hdrRow=<optimized out>, columnToken=<optimized out>, 
    uint32Result=@0x7fffca041d88: 4294967295, 
    defaultValue=defaultValue@entry=4294967295)
    at /home/fred/logs/mail/src/mailnews/db/msgdb/src/nsMsgDatabase.cpp:3756
#4  0x00007fffe63032d6 in nsDBFolderInfo::GetInt32PropertyWithToken (
    this=this@entry=0x7fffca041d40, aProperty=<optimized out>, 
    propertyValue=@0x7fffca041d88: -1, defaultValue=defaultValue@entry=-1)
    at /home/fred/logs/mail/src/mailnews/db/msgdb/src/nsDBFolderInfo.cpp:865
Crash Signature: [@ libxul.so@0xa94024 | libxul.so@0xaa1ea0 | libxul.so@0xbac32d | thunderbird@0x12e18] → [@ libxul.so@0xa94024 | libxul.so@0xaa1ea0 | libxul.so@0xbac32d | thunderbird@0x12e18] [@ morkAtom::AliasYarn]

Comment 10

11 months ago
Have you tried adding 
-fno-delete-null-pointer-checks
to your CFLAGS and CXXFLAGS during configure and compile?
I think it will solve the problem with GCC6.
(Reporter)

Comment 11

11 months ago
(In reply to ISHIKAWA, Chiaki from comment #10)
> Have you tried adding 
> -fno-delete-null-pointer-checks
> to your CFLAGS and CXXFLAGS during configure and compile?
> I think it will solve the problem with GCC6.

It works indeed. It was a good guess. Adding this to my .mozconfig fixes the bug :

export CFLAGS=-fno-delete-null-pointer-checks
export CXXFLAGS=-fno-delete-null-pointer-checks

Thanks for the trick :)

Comment 12

11 months ago
(In reply to Frederic Bezies from comment #11)
> (In reply to ISHIKAWA, Chiaki from comment #10)
> > Have you tried adding 
> > -fno-delete-null-pointer-checks
> > to your CFLAGS and CXXFLAGS during configure and compile?
> > I think it will solve the problem with GCC6.
> 
> It works indeed. It was a good guess. Adding this to my .mozconfig fixes the
> bug :
> 
> export CFLAGS=-fno-delete-null-pointer-checks
> export CXXFLAGS=-fno-delete-null-pointer-checks
> 
> Thanks for the trick :)

Welcome. I was bitten earlier and saw someone's post myself.
(In reply to ISHIKAWA, Chiaki from comment #12)
> 
> Welcome. I was bitten earlier and saw someone's post myself.

So it's covered in a different bug?
Flags: needinfo?(ishikawa)
Summary: [gcc 6.1] Crash on start with an homemade thunderbird trunk version and an existing profile. → [gcc 6.1] Crash on start with an homemade thunderbird trunk version and an existing profile. solved with -fno-delete-null-pointer-checks on gcc6

Comment 14

8 months ago
So what is the problem here. Chiaki, do you know why this happens?
Because we removed some 'if (this)' checks in mork in bug 1294260 (clang was complaining about them being pointless in correct code). May those be the null checks you mean?
It would mean we did the same gcc6 was doing for the reporter. We just did it for everybody. But nobody reported a problem yet.

May the reporters profile (or a single msf file inside) be corrupt?

Comment 15

8 months ago
(In reply to :aceman from comment #14)
> So what is the problem here. Chiaki, do you know why this happens?
> Because we removed some 'if (this)' checks in mork in bug 1294260 (clang was
> complaining about them being pointless in correct code). May those be the
> null checks you mean?
> It would mean we did the same gcc6 was doing for the reporter. We just did
> it for everybody. But nobody reported a problem yet.
> 
> May the reporters profile (or a single msf file inside) be corrupt?

Aceman, 
to be honest, I have no idea :-)
GCC6 seems to have this "optimization" and since I have not followed latest c++ standard in detail, I have no idea what this is all about myself.

I just found out the issue when my compilation failed with newer version of GCC.

Now to answer Wayne's question, and that may explain a bit about
the history of the issue:

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #13)
> (In reply to ISHIKAWA, Chiaki from comment #12)
> > 
> > Welcome. I was bitten earlier and saw someone's post myself.
> 
> So it's covered in a different bug?

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #13)
> (In reply to ISHIKAWA, Chiaki from comment #12)
> > 
> > Welcome. I was bitten earlier and saw someone's post myself.
> 
> So it's covered in a different bug?

I think I saw the issue either in
Bug 1251576 - GCC6 - TB crashes due to removed null pointer checks for "this"
or in a mailing list/Newsgroup posting (but not sure).

Actually, I am a little puzzled that there was a time when I had a compilation issue with gcc5 (five), but
somehow the particular patch I thought was necessary for compilation
never seemed to have made it into the M-C tree.
Strange, but probably somehow, the issue was taken care of by a different modification.

The particular patch, which I found in Ubuntu bugzilla about the time gcc5.3 was introduced, was necessary to compile C-C tree.
It is
https://hg.mozilla.org/try-comm-central/rev/d987a30d496d

I *think* I found it from the following URL
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/1528297

But one post says the original buggy code in question may not be quite standard conformant and
anything can happen.

OTOH, I found today that the original compilation bug may be a regression of gcc5.3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668

If so, it figures that other people who are using the later fixed gcc5.x or gcc6 do not need
the patch in the launcyhpad URL at all.

Oh well.

Well back to the original question of aceman:
> So what is the problem here. Chiaki, do you know why this happens?

Like I say, I have no idea what gcc6 does exactly...
I wish I had time to read up on GCC release notes of late.
Flags: needinfo?(ishikawa)

Comment 16

8 months ago
> > Because we removed some 'if (this)' checks in mork in bug 1294260 (clang was

I wish I knew about bug 1294260 earlier.
Like others, I noticed stricter checking on try-comm-central this month (I could not do much in August) and
added the following to GCC CFLAGS on my local PC running linux:
# added -Werror=sign-compare on Sept 15, 2016
# added -Werror=unused-result on Sept 22, 2016

But they applied to the WHOLE tree.
As a result, I had to fix MANY issues in M-C tree portion as well as LDAP like mentioned in the bug
to compile TB locally.
I have the patches. I wonder if they are worth while and I should submit them (but some of the patches are for 3rd party library, it seems)..

There is even a memory allocation issue that may not have been well-handled: -Werror=unsed-result) has found it.

Also, the following issue was noticed thanks to -Werror=unsed-result and a change made into the underlying M-C tree's definition of function(s)

Bug 1304504 - Check the return value of GetIntPref() properly or an initialized bogus value may be used

Comment 17

8 months ago
Ok, then let's see what happens later. I'm on gcc 5.4, but with gcc 6.2 released, maybe the distro will upgrade soon.

Comment 18

8 months ago
(In reply to ISHIKAWA, Chiaki from comment #16)
> I wish I knew about bug 1294260 earlier.
> Like others, I noticed stricter checking on try-comm-central this month (I
> could not do much in August) and
> added the following to GCC CFLAGS on my local PC running linux:
> # added -Werror=sign-compare on Sept 15, 2016
> # added -Werror=unused-result on Sept 22, 2016
> 
> But they applied to the WHOLE tree.
> As a result, I had to fix MANY issues in M-C tree portion as well as LDAP
> like mentioned in the bug
> to compile TB locally.

Yes, m-c enabled these options and they apply to our whole tree now.

> I have the patches. I wonder if they are worth while and I should submit
> them (but some of the patches are for 3rd party library, it seems)..

We just disabled warnings-as-errors for LDAP as we decided it is not worth to invest in the 3rd party library, when we rather would like to replace it.

But please keep the patch around in case it is needed to maintain the LDAP library in the future. Or make a bug and attach the path there so we can find it if needed.

> There is even a memory allocation issue that may not have been well-handled:
> -Werror=unsed-result) has found it.

IF you have changes that we didn't already cover in bug 1294260, I would be interested in them. Can you rebase the patches (except LDAP) to current trunk and attach to a new bug? Thanks.
 
> Also, the following issue was noticed thanks to -Werror=unsed-result and a
> change made into the underlying M-C tree's definition of function(s)
> 
> Bug 1304504 - Check the return value of GetIntPref() properly or an
> initialized bogus value may be used

Good that you also fix m-c.

Comment 19

8 months ago
(In reply to :aceman from comment #18)
> (In reply to ISHIKAWA, Chiaki from comment #16)
> > I wish I knew about bug 1294260 earlier.
> > Like others, I noticed stricter checking on try-comm-central this month (I
> > could not do much in August) and
> > added the following to GCC CFLAGS on my local PC running linux:
> > # added -Werror=sign-compare on Sept 15, 2016
> > # added -Werror=unused-result on Sept 22, 2016
> > 
> > But they applied to the WHOLE tree.
> > As a result, I had to fix MANY issues in M-C tree portion as well as LDAP
> > like mentioned in the bug
> > to compile TB locally.
> 
> Yes, m-c enabled these options and they apply to our whole tree now.
> 
> > I have the patches. I wonder if they are worth while and I should submit
> > them (but some of the patches are for 3rd party library, it seems)..
> 
> We just disabled warnings-as-errors for LDAP as we decided it is not worth
> to invest in the 3rd party library, when we rather would like to replace it.
> 
> But please keep the patch around in case it is needed to maintain the LDAP
> library in the future. Or make a bug and attach the path there so we can
> find it if needed.
> 


I uploaded the patch to 
Bug 1243121 - C-C ldap directory: fix -Werror=sign-compare: signed vs unsigned warnings (now treated as errors) 
(I edited the title a bit)
so that if someone is willing to modify the files.
Mostly it is a cast at the time of usage, but there are a few variable type declarations.

But as I noticed while testing the patches, LDAP has defined a type, a 32 bit int, and use it to refer to the size. In a few places, pointer values are cast into the data type.
This is OK on 32-bit systems, but not any more on 64-bit systems.
A few years ago,
I thought LDAP's hash was buggy since it only looked at the lower 32bit value of 64-bit pointers, and
I suspect this was related to the 32-vs-64 cast issue, but not sure.
Anyway, GCC6 warns about it loudly and so it is  no brainer to fix that however, I am not sure if
extending the size of this typedef may break existing LDAP database, etc.
(So probably removing the incorrect casts is the way to go.)

Hope this helps.

Updated

8 months ago
See Also: → bug 1243121

Updated

7 months ago
Duplicate of this bug: 1251576

Comment 21

7 months ago
So copying bug 1251576 comment 11 here as I still didn't get an answer. Without the answer this bug is not actionable.

Can anybody reproduce the problem with current trunk? Last comment here is June 2016.

I still have not heard if the crash is caused by:
1. the fact the checks are there (and gcc6 forcibly crashes the app);
2. gcc6 optimizes away the checks and we hit some corrupt object and crash (so that the checks actually are needed).

Can anybody do tests confirming either of those claims? I do not have gcc6 yet. But as we have removed the checks from the tree, the checks are not there even on gcc5. And we do not see the crashes. So that would point to case 1. being the problem. Which is then solved as the checks were removed since.
Component: General → Database
Product: Thunderbird → MailNews Core
Version: unspecified → Trunk

Comment 22

7 months ago
Or is this a case of bug 1167145, with the pattern
var obj = (something returning an obj but sometimes null)->methodOfObj() ?

And this was changed to:
var obj = (something returning an obj but sometimes null);
if (obj)
  obj->methodOfObj()

If this is the case (and Chiaki's logs allow for this interpretation, there is code like this in the mentioned lines), then we can look at that.

Comment 23

7 months ago
I looked at some of the core and it seems the this==null checks could have been useful. There are even comments that indicate it really wants to call the nullObject->methodOfObj() and it will do the right thing.

So then my question again is, when we removed these checks for everybody, how comes there are no crashes even on gcc5 now?
Yes, there are some situations where we do
obj = this;
if (obj) { ... }
if (!obj) { ... }

And clang was not smart enough to error out on these, so those are left in. Could that be the reason this still works up to gcc5, but not 6? Does gcc6 remove also these checks?

Chiaki, can you get a new backtrace with current code?
Flags: needinfo?(ishikawa)

Comment 24

7 months ago
I will see if I can something useful by removing -fno-delete-null-pointer-checks from my gcc-6/g++-6 command flags.
(I suspect that use of XPCOM may have introduced a situation where |this| is set to null in the context
of TB's execution, which doesn't normally happen in a self-contained XPCOM-less program, but I have no proof.)
Flags: needinfo?(ishikawa)

Comment 25

7 months ago
This is the stack trace and the dump leading to it from the DEBUG build of C-C TB (local build).

Tough luck. I forgot to diable optimization and so it does not show the argument, etc.

Maybe tomorrow.

Anyway, if I recall correctly, this MorkAtom::AliasYarn() is where I observed crash before.


[14776] WARNING: NS_ENSURE_TRUE(aURI) failed: file /NREF-COMM-CENTRAL/comm-central/mozilla/netwerk/dns/nsEffectiveTLDService.cpp, line 177
++DOMWINDOW == 27 (0x555559f914f0) [pid = 14776] [serial = 27] [outer = 0x555558ca1310]
++DOMWINDOW == 28 (0x555559faa370) [pid = 14776] [serial = 28] [outer = 0x555558eecc50]
++DOMWINDOW == 29 (0x555559fc3c20) [pid = 14776] [serial = 29] [outer = 0x555558c48fb0]
[14776] WARNING: NS_ENSURE_TRUE(aURI) failed: file /NREF-COMM-CENTRAL/comm-central/mozilla/netwerk/dns/nsEffectiveTLDService.cpp, line 177
[New Thread 0x7fff529bf700 (LWP 14870)]
JavaScript error: chrome://calendar/content/calendar-views.js, line 605: TypeError: deck is null
[New Thread 0x7fff5213e700 (LWP 14873)]
++DOMWINDOW == 30 (0x55555adaf210) [pid = 14776] [serial = 30] [outer = 0x55555776ae50]
[14776] WARNING: NS_ENSURE_TRUE(aURI) failed: file /NREF-COMM-CENTRAL/comm-central/mozilla/netwerk/dns/nsEffectiveTLDService.cpp, line 177

Program received signal SIGSEGV, Segmentation fault.
morkAtom::AliasYarn (this=<optimized out>, outYarn=outYarn@entry=0x7fffffff6e70)
    at /NREF-COMM-CENTRAL/comm-central/db/mork/src/morkAtom.cpp:148
148	    if ( atom->IsWeeBook() )
(gdb) where
#0  morkAtom::AliasYarn (this=<optimized out>, outYarn=outYarn@entry=0x7fffffff6e70)
    at /NREF-COMM-CENTRAL/comm-central/db/mork/src/morkAtom.cpp:148
#1  0x00007fffe74ee6c0 in morkRowObject::AliasCellYarn (this=<optimized out>, mev=<optimized out>, 
    inColumn=<optimized out>, outYarn=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/db/mork/src/morkRowObject.cpp:492
#2  0x00007fffe774744d in nsMsgDatabase::RowCellColumnToUInt32 (this=<optimized out>, 
    hdrRow=<optimized out>, columnToken=<optimized out>, uint32Result=<optimized out>, 
    defaultValue=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:3768
#3  0x00007fffe7747483 in nsMsgDatabase::RowCellColumnToUInt32 (this=<optimized out>, 
    hdrRow=<optimized out>, columnToken=<optimized out>, uint32Result=<optimized out>, 
    defaultValue=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:3756
#4  0x00007fffe773f14f in nsDBFolderInfo::GetInt32PropertyWithToken (this=<optimized out>, 
    aProperty=<optimized out>, propertyValue=<optimized out>, defaultValue=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsDBFolderInfo.cpp:864
#5  0x00007fffe773f1be in nsDBFolderInfo::LoadMemberVariables (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsDBFolderInfo.cpp:357
#6  0x00007fffe773f40c in nsDBFolderInfo::InitFromExistingDB (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsDBFolderInfo.cpp:312
#7  0x00007fffe774f5d9 in nsMsgDatabase::InitExistingDB (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1716
#8  0x00007fffe774e312 in nsMsgDatabase::OpenMDB (this=<optimized out>, dbName=<optimized out>, 
    create=<optimized out>, sync=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1403
#9  0x00007fffe774cf34 in nsMsgDatabase::OpenInternal (this=<optimized out>, 
    aDBService=<optimized out>, summaryFile=<optimized out>, aCreate=<optimized out>, 
    aLeaveInvalidDB=<optimized out>, sync=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1210
#10 0x00007fffe774d69e in nsMsgDatabase::Open (this=<optimized out>, aDBService=<optimized out>, 
    aFolderName=<optimized out>, aCreate=<optimized out>, aLeaveInvalidDB=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:1195
#11 0x00007fffe774331c in nsMailDatabase::Open (this=<optimized out>, aDBService=<optimized out>, 
    aSummaryFile=<optimized out>, aCreate=<optimized out>, aUpgrading=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMailDatabase.cpp:52
#12 0x00007fffe774bf59 in nsMsgDBService::OpenFolderDB (this=<optimized out>, aFolder=<optimized out>, 
    aLeaveInvalidDB=<optimized out>, _retval=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/db/msgdb/src/nsMsgDatabase.cpp:134
#13 0x00007fffe77bb2dd in nsImapMailFolder::GetDatabase (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/imap/src/nsImapMailFolder.cpp:606
#14 0x00007fffe763f9bf in nsMsgDBFolder::GetMsgDatabase (this=<optimized out>, 
    aMsgDatabase=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mailnews/base/util/nsMsgDBFolder.cpp:932
#15 0x00007fffe7a8f7b1 in NS_InvokeByIndex (that=<optimized out>, methodIndex=<optimized out>, 
    paramCount=<optimized out>, params=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:182
#16 0x00007fffe84b8062 in CallMethodHelper::Invoke (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:2064
#17 CallMethodHelper::Call (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1383
#18 XPCWrappedNative::CallMethod (ccx=..., mode=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1350
#19 0x00007fffe84c234f in XPCWrappedNative::GetAttribute (ccx=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/xpcprivate.h:1877
#20 XPC_WN_GetterSetter (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1179
#21 0x00007fffec08a4b4 in js::CallJSNative (cx=<optimized out>, native=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:239
#22 0x00007fffec0befcb in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:458
#23 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#24 0x00007fffec0bf57d in js::Call (cx=<optimized out>, fval=..., thisv=..., args=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:522
#25 0x00007fffec0c0720 in js::CallGetter (cx=<optimized out>, thisv=..., getter=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:636
#26 0x00007fffec0fd9ac in CallGetter (vp=..., shape=..., receiver=..., obj=..., cx=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/NativeObject.cpp:1791
#27 GetExistingProperty<(js::AllowGC)1> (cx=<optimized out>, receiver=..., obj=..., shape=..., vp=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/NativeObject.cpp:1839
#28 0x00007fffec0fe604 in NativeGetPropertyInline<(js::AllowGC)1> (cx=<optimized out>, obj=..., 
    receiver=..., id=..., nameLookup=<optimized out>, vp=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/NativeObject.cpp:2066
#29 0x00007fffec0fe8a2 in js::NativeGetProperty (cx=<optimized out>, obj=..., receiver=..., id=..., 
    vp=...) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/NativeObject.cpp:2100
#30 0x00007fffeba2386c in js::GetProperty (cx=<optimized out>, obj=..., receiver=..., id=..., vp=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/NativeObject.h:1533
#31 0x00007fffec0b0b8c in js::GetProperty (vp=..., name=<optimized out>, receiver=..., obj=..., 
    cx=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jsobj.h:846
#32 js::GetProperty (cx=<optimized out>, v=..., name=..., vp=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:4250
#33 0x00007fffec0b71e0 in GetPropertyOperation (vp=..., lval=..., pc=<optimized out>, script=..., 
    fp=<optimized out>, cx=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:191
#34 Interpret (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2639
#35 0x00007fffec0bedde in js::RunScript (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:404
#36 0x00007fffec0bf24e in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:476
#37 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#38 0x00007fffec0bf57d in js::Call (cx=<optimized out>, fval=..., thisv=..., args=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:522
#39 0x00007fffebfe73cf in js::Wrapper::call (this=<optimized out>, cx=<optimized out>, proxy=..., 
    args=...) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/proxy/Wrapper.cpp:165
#40 0x00007fffebfa1f4d in js::CrossCompartmentWrapper::call (this=<optimized out>, cx=<optimized out>, 
    wrapper=..., args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/proxy/CrossCompartmentWrapper.cpp:333
#41 0x00007fffebfdc5da in js::Proxy::call (cx=<optimized out>, proxy=..., args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/proxy/Proxy.cpp:400
#42 0x00007fffebfdc66a in js::proxy_Call (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/proxy/Proxy.cpp:689
#43 0x00007fffec08a4b4 in js::CallJSNative (cx=<optimized out>, native=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:239
#44 0x00007fffec0bf0b8 in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:446
#45 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#46 0x00007fffec0bf54d in js::CallFromStack (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:509
#47 0x00007fffec0b86aa in Interpret (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2922
#48 0x00007fffec0bedde in js::RunScript (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:404
#49 0x00007fffec0bf24e in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:476
#50 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#51 0x00007fffec0bf57d in js::Call (cx=<optimized out>, fval=..., thisv=..., args=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:522
#52 0x00007fffebe9185e in JS::Call (cx=<optimized out>, thisv=..., fval=..., args=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:2827
#53 0x00007fffe95f91f7 in (anonymous namespace)::dom::EventHandlerNonNull::Call (this=<optimized out>, 
    cx=<optimized out>, aThisVal=..., event=..., aRetVal=..., aRv=...)
    at /NREF-COMM-CENTRAL/objdir-tb3/dom/bindings/EventHandlerBinding.cpp:259
#54 0x00007fffe99ceb43 in (anonymous namespace)::dom::EventHandlerNonNull::Call<nsISupports*> (
    aCompartment=<optimized out>, aExceptionHandling=<optimized out>, aExecutionReason=<optimized out>, 
    aRv=..., aRetVal=..., event=..., thisVal=<optimized out>, this=<optimized out>)
    at /NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/dom/EventHandlerBinding.h:361
#55 (anonymous namespace)::JSEventHandler::HandleEvent (this=<optimized out>, aEvent=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/JSEventHandler.cpp:214
#56 0x00007fffe99db762 in (anonymous namespace)::EventListenerManager::HandleEventSubType (
    this=<optimized out>, aListener=<optimized out>, aDOMEvent=<optimized out>, 
    aCurrentTarget=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:1133
#57 0x00007fffe99dc1a8 in (anonymous namespace)::EventListenerManager::HandleEventInternal (
    this=<optimized out>, aPresContext=<optimized out>, aEvent=<optimized out>, 
    aDOMEvent=<optimized out>, aCurrentTarget=<optimized out>, aEventStatus=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventListenerManager.cpp:1286
#58 0x00007fffe99dcd67 in (anonymous namespace)::EventListenerManager::HandleEvent (
    aEventStatus=<optimized out>, aCurrentTarget=<optimized out>, aDOMEvent=<optimized out>, 
    aEvent=<optimized out>, aPresContext=<optimized out>, this=<optimized out>)
    at /NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/EventListenerManager.h:375
#59 (anonymous namespace)::EventTargetChainItem::HandleEvent (this=<optimized out>, aVisitor=..., 
    aCd=...) at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:278
#60 0x00007fffe99dcf33 in (anonymous namespace)::EventTargetChainItem::HandleEventTargetChain (
    aChain=..., aVisitor=..., aCallback=<optimized out>, aCd=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:380
#61 0x00007fffe99ddff4 in (anonymous namespace)::EventDispatcher::Dispatch (aTarget=<optimized out>, 
    aPresContext=<optimized out>, aEvent=<optimized out>, aDOMEvent=<optimized out>, 
    aEventStatus=<optimized out>, aCallback=<optimized out>, aTargets=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:712
#62 0x00007fffe99de33f in (anonymous namespace)::EventDispatcher::DispatchDOMEvent (
    aTarget=<optimized out>, aEvent=<optimized out>, aDOMEvent=<optimized out>, 
    aPresContext=<optimized out>, aEventStatus=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/EventDispatcher.cpp:778
#63 0x00007fffe8d5eda5 in nsINode::DispatchEvent (this=<optimized out>, aEvent=<optimized out>, 
    aRetVal=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsINode.cpp:1309
#64 0x00007fffe999566c in (anonymous namespace)::AsyncEventDispatcher::Run (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/AsyncEventDispatcher.cpp:54
#65 0x00007fffe8b3bcc4 in nsContentUtils::AddScriptRunner (aRunnable=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsContentUtils.cpp:5262
#66 0x00007fffe8b3bd7d in nsContentUtils::AddScriptRunner (aRunnable=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsContentUtils.cpp:5269
#67 0x00007fffe9997272 in (anonymous namespace)::AsyncEventDispatcher::RunDOMEventWhenSafe (
    this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/events/AsyncEventDispatcher.cpp:76
#68 0x00007fffeab68717 in nsTreeSelection::FireOnSelectHandler (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeSelection.cpp:841
#69 0x00007fffeab6bb8e in nsTreeSelection::Select (this=<optimized out>, aIndex=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/layout/xul/tree/nsTreeSelection.cpp:384
#70 0x00007fffe7a8f7b1 in NS_InvokeByIndex (that=<optimized out>, methodIndex=<optimized out>, 
    paramCount=<optimized out>, params=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/reflect/xptcall/md/unix/xptcinvoke_x86_64_unix.cpp:182
#71 0x00007fffe84b8062 in CallMethodHelper::Invoke (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:2064
#72 CallMethodHelper::Call (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1383
#73 XPCWrappedNative::CallMethod (ccx=..., mode=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNative.cpp:1350
#74 0x00007fffe84c1f8d in XPC_WN_CallMethod (cx=<optimized out>, argc=<optimized out>, 
    vp=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1143
#75 0x00007fffec08a4b4 in js::CallJSNative (cx=<optimized out>, native=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:239
#76 0x00007fffec0befcb in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:458
#77 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#78 0x00007fffec0bf54d in js::CallFromStack (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:509
#79 0x00007fffec0b86aa in Interpret (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2922
#80 0x00007fffec0bedde in js::RunScript (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:404
#81 0x00007fffec0bf24e in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:476
#82 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#83 0x00007fffec0bf57d in js::Call (cx=<optimized out>, fval=..., thisv=..., args=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:522
#84 0x00007fffebf2ead7 in js::fun_call (cx=<optimized out>, argc=<optimized out>, vp=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jsfun.cpp:1231
#85 0x00007fffec08a4b4 in js::CallJSNative (cx=<optimized out>, native=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jscntxtinlines.h:239
#86 0x00007fffec0befcb in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:458
#87 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#88 0x00007fffec0bf54d in js::CallFromStack (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:509
#89 0x00007fffec0b86aa in Interpret (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:2922
#90 0x00007fffec0bedde in js::RunScript (cx=<optimized out>, state=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:404
#91 0x00007fffec0bf24e in js::InternalCallOrConstruct (cx=<optimized out>, args=..., 
    construct=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:476
#92 0x00007fffec0bf3cc in InternalCall (cx=<optimized out>, args=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:503
#93 0x00007fffec0bf57d in js::Call (cx=<optimized out>, fval=..., thisv=..., args=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/vm/Interpreter.cpp:522
#94 0x00007fffebe9185e in JS::Call (cx=<optimized out>, thisv=..., fval=..., args=..., rval=...)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/js/src/jsapi.cpp:2827
#95 0x00007fffe9646a18 in (anonymous namespace)::dom::Function::Call (this=<optimized out>, 
    cx=<optimized out>, aThisVal=..., arguments=..., aRetVal=..., aRv=...)
    at /NREF-COMM-CENTRAL/objdir-tb3/dom/bindings/FunctionBinding.cpp:36
#96 0x00007fffe8b84c6c in (anonymous namespace)::dom::Function::Call<nsCOMPtr<nsISupports> > (
    aCompartment=<optimized out>, aExceptionHandling=<optimized out>, aExecutionReason=<optimized out>, 
    aRv=..., aRetVal=..., arguments=..., thisVal=..., this=<optimized out>)
    at /NREF-COMM-CENTRAL/objdir-tb3/dist/include/mozilla/dom/FunctionBinding.h:70
#97 nsGlobalWindow::RunTimeoutHandler (this=<optimized out>, aTimeout=<optimized out>, 
    aScx=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsGlobalWindow.cpp:12666
#98 0x00007fffe8ba560c in nsGlobalWindow::RunTimeout (this=<optimized out>, aTimeout=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsGlobalWindow.cpp:12907
#99 0x00007fffe8ba5870 in nsGlobalWindow::TimerCallback (aTimer=<optimized out>, 
    aClosure=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/dom/base/nsGlobalWindow.cpp:13153
#100 0x00007fffe7a8afbb in nsTimerImpl::Fire (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/nsTimerImpl.cpp:477
#101 0x00007fffe7a739f2 in nsTimerEvent::Run (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/TimerThread.cpp:289
#102 0x00007fffe7a7fa14 in nsThread::ProcessNextEvent (this=<optimized out>, aMayWait=<optimized out>, 
    aResult=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/nsThread.cpp:1082
#103 0x00007fffe7ab81b4 in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/xpcom/glue/nsThreadUtils.cpp:290
#104 0x00007fffe7f9c171 in (anonymous namespace)::ipc::MessagePump::Run (this=<optimized out>, 
    aDelegate=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mozilla/ipc/glue/MessagePump.cpp:96
#105 0x00007fffe7f63780 in MessageLoop::RunInternal (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:232
#106 0x00007fffe7f637b9 in MessageLoop::RunHandler (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:225
#107 0x00007fffe7f63b71 in MessageLoop::Run (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/ipc/chromium/src/base/message_loop.cc:205
#108 0x00007fffea4c2dc1 in nsBaseAppShell::Run (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/widget/nsBaseAppShell.cpp:156
#109 0x00007fffeb175c2e in nsAppStartup::Run (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/toolkit/components/startup/nsAppStartup.cpp:283
#110 0x00007fffeb22c535 in XREMain::XRE_mainRun (this=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4467
#111 0x00007fffeb22da10 in XREMain::XRE_main (this=<optimized out>, argc=<optimized out>, 
    argv=<optimized out>, aAppData=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4600
#112 0x00007fffeb22de46 in XRE_main (argc=<optimized out>, argv=<optimized out>, 
    aAppData=<optimized out>, aFlags=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mozilla/toolkit/xre/nsAppRunner.cpp:4691
#113 0x000055555555949d in do_main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>, 
    xreDirectory=<optimized out>) at /NREF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:245
#114 0x0000555555559540 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>)
    at /NREF-COMM-CENTRAL/comm-central/mail/app/nsMailApp.cpp:378
(gdb)

Comment 26

7 months ago
The code is as below.

97	mork_bool
98	morkAtom::AsBuf(morkBuf& outBuf) const
99	{
100	  const morkAtom* atom = this;
101	  if ( atom )
102	  {
103	    if ( atom->IsWeeBook() )
104	    {
(gdb) list
105	      morkWeeBookAtom* weeBook = (morkWeeBookAtom*) atom;
106	      outBuf.mBuf_Body = weeBook->mWeeBookAtom_Body;
107	      outBuf.mBuf_Fill = weeBook->mAtom_Size;
108	    }
109	    else if ( atom->IsBigBook() )
110	    {
111	      morkBigBookAtom* bigBook = (morkBigBookAtom*) atom;
112	      outBuf.mBuf_Body = bigBook->mBigBookAtom_Body;
113	      outBuf.mBuf_Fill = bigBook->mBigBookAtom_Size;
114	    }
(gdb) 


My hypothesis: since in a self-contained c++ program, this can never be null,
in the code snippet,
    100	  const morkAtom* atom = this;
    101	  if ( atom )
gcc/g++ probably skips generating the code to check for atom (= this) != nullptr.

However, as I mention, there may be a situation where the call via XPCOM causes a function to be executing when "this" is null: this sounds a very buggy code, but such is life.
Pure conjecture, though, at this stage.

TIA

PS: BTW, the following error line sprung up in the last couple of days, and there were more than 2K+ of
such lines during |make mozmill| test suite run.
 
[14776] WARNING: NS_ENSURE_TRUE(aURI) failed: file /NREF-COMM-CENTRAL/comm-central/mozilla/netwerk/dns/nsEffectiveTLDService.cpp, line 177

It may be that it is a symptom of a deeper issue that may cause the open attachment test to fail.
(I read the bugzilla entry this morning, but somehow cannot find it ?)
It may be that the security context management code tries to discern "security domain" and part of
the domain check is checking the DNS-style domain, too, and it may be that depending on the name resolution configuration, the lookup through DNS is attempted and fails and that may cause
access violation in terms of "access" permission through system principal or something like that.
But this discussion must be in proper bugzilla entry. Please move it to the appropriate bugzilla entry which I can no longer find somehow.
(Assignee)

Comment 27

7 months ago
Surely you'd have to fix:

.\morkRowObject.cpp: atom->AliasYarn(&yarn); // works even when atom is nil
.\morkWriter.cpp: atom->AliasYarn(&yarn); // works even when atom==nil
.\morkWriter.cpp: atom->AliasYarn(&yarn); // works even when atom==nil

How can you call a method on null??

Comment 28

7 months ago
Yes, seems like some c++ magic. And it seems intentional per the comments.
That seems to be the problem here. The AliasYarn (aand similar) functions were skipping parts of their code when 'this' was null but still executed some. After the checks were removed (or gcc removes them), all code is executed and it crashes as some parts are not intended for null 'this'.

It can be seen in Chiaki's traces. AliasYarn is run with null 'this'.
#0  0x00007fffe61655c9 in morkAtom::AliasYarn (this=0x0, 
    outYarn=outYarn@entry=0x7fffffffa510)
    at /home/fred/logs/mail/src/db/mork/src/morkAtom.cpp:145
#1  0x00007fffe6174f32 in morkRowObject::AliasCellYarn (this=0x7fffca3382e0, 
    mev=<optimized out>, inColumn=168, outYarn=0x7fffffffa510)
    at /home/fred/logs/mail/src/db/mork/src/morkRowObject.cpp:492

So I see 2 options here:
1. put back the null checks and force the compiler option on the whole folder to not optimize them away.
2. find a c++ guru that can unroll the functions to not run with null 'this' but still run the needed code for null objects externally (just not from inside the null object).
(Assignee)

Comment 29

7 months ago
Created attachment 8806491 [details] [diff] [review]
1278795.patch

Remove method call on null. Also removed unused AsBuf().

Chiaki, does this fix anything?
Attachment #8806491 - Flags: feedback?(rkent)
Attachment #8806491 - Flags: feedback?(acelists)

Comment 30

7 months ago
Comment on attachment 8806491 [details] [diff] [review]
1278795.patch

Review of attachment 8806491 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks, nice unrolling :) Seems to be the right direction for option 2, as far as I can tell without running it (I don't have gcc 6). The question is whether AliasYarn is the only function needing this treatment. We removed the this check from a ton of functions so all of them are potential candidates (but many of them did nothing for this==nullptr).
Attachment #8806491 - Flags: feedback?(ishikawa)
Attachment #8806491 - Flags: feedback?(acelists)
Attachment #8806491 - Flags: feedback+
(Assignee)

Comment 31

7 months ago
Created attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

Same thing, just using memset() to avoid extra assignments. Also removed some trailing spaces.

Chiaki, can you see whether that fixes the problem for you?
Attachment #8806491 - Attachment is obsolete: true
Attachment #8806491 - Flags: feedback?(rkent)
Attachment #8806491 - Flags: feedback?(ishikawa)
Attachment #8806504 - Flags: feedback?(rkent)
(Assignee)

Comment 32

7 months ago
Or maybe the reporter wants to try it.
Flags: needinfo?(fredbezies)
(Assignee)

Comment 33

7 months ago
See whether this breaks anything:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=1ccd59aa74e7028ad81340de6baddcf78793a655

(In reply to :aceman from comment #28)
> 2. find a c++ guru ...
Does it really need a guru for this simple task?
(Assignee)

Comment 34

7 months ago
Or maybe Martin wants to try.
Flags: needinfo?(stransky)
(Assignee)

Comment 35

7 months ago
Comment on attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

Try came out green, so this doesn't appear to do any damage.
Attachment #8806504 - Flags: review?(rkent)
Attachment #8806504 - Flags: review?(acelists)
Attachment #8806504 - Flags: feedback?(rkent)

Comment 36

7 months ago
(In reply to Jorg K (GMT+1) from comment #31)
> Created attachment 8806504 [details] [diff] [review]
> 1278795.patch (v2)
> 
> Same thing, just using memset() to avoid extra assignments. Also removed
> some trailing spaces.
> 
> Chiaki, can you see whether that fixes the problem for you?

TB starts up fine with GCC6 with your patch.
I thought I posted the message this morning but it did not show up.
Anyway, I will run |make mozmill| and possibly xpshell-test locally to see if TB is still broken WITHOUT the -fno... flag.

TIA

Comment 37

7 months ago
(In reply to Jorg K (GMT+1) from comment #33)
> (In reply to :aceman from comment #28)
> > 2. find a c++ guru ...
> Does it really need a guru for this simple task?

We removed the 'this' checks from ~30 functions so if all those will need this treatment, then it is not trivial :)

It may also mean you are the guru if you found out only the AliasYarn needs any change :) That would mean all the other checks were not really needed and those other functions weren't called with null this. That would be the better case.
Assignee: nobody → jorgk
Status: NEW → ASSIGNED

Comment 38

7 months ago
(In reply to ISHIKAWA, Chiaki from comment #36)
> TB starts up fine with GCC6 with your patch.
> I thought I posted the message this morning but it did not show up.
> Anyway, I will run |make mozmill| and possibly xpshell-test locally to see
> if TB is still broken WITHOUT the -fno... flag.

Yes, please. Do not use the flag and build with gcc6 and run all the tests possible. Without that we can't know if this is the complete solution.
(Assignee)

Comment 39

7 months ago
(In reply to :aceman from comment #37)
> That would mean all the other checks were not really needed
> and those other functions weren't called with null 'this'. That would be the
> better case.
I think the other checks weren't necessary since clearly the system runs without them on all platforms. In fact, IIRC, the GCC compiler wouldn't have them.

The quirk seems to be that compilers other then the modern GCC6 dispatch to method 'xx()' of class 'yy' on a call of |yy->xx()| even if 'yy' is null. That's why the method checks 'this'. Modern GCC6 already crashes on the dispatch (as it should). Since I removed those checks now and I am instead checking the 'yy', all compilers should treat this the same. My try run was successful, so at least the call sites of morkAtom::AliasYarn() I changed, the ones where a comment mentioned that they were called on a null 'this', were successfully fixed.

There might be further work in:
1) Fixing more call sites of morkAtom::AliasYarn()
2) Giving more functions and their call sites the same treatment as morkAtom::AliasYarn().

2) is unlikely since I checked for "= this;" and there are only valid cases left.

Comment 40

7 months ago
OK, on my main development PC, |make mozmill| seemeed to have run without major hiccups.

However, on a different PC, where I occasionally test C-C TB operation, I noticed a crash
in a diskcache-related routine.

Note that the particular execution path seems to be taken only with a certain state of 
external diskcache and so I could not reproduce it to test my patch below.

The following patch would have been necessary to prevent the crash.


diff --git a/xpcom/io/nsLocalFileUnix.cpp b/xpcom/io/nsLocalFileUnix.cpp
--- a/xpcom/io/nsLocalFileUnix.cpp
+++ b/xpcom/io/nsLocalFileUnix.cpp
@@ -264,16 +264,22 @@ nsLocalFile::nsLocalFileConstructor(nsIS
 
   nsCOMPtr<nsIFile> inst = new nsLocalFile();
   return inst->QueryInterface(aIID, aInstancePtr);
 }
 
 bool
 nsLocalFile::FillStatCache()
 {
+  if (mPath == nullptr) {
+#if 1
+    fprintf(stderr, "FillStatCache: mPath == nullptr\n");
+#endif
+    return false;
+  }
   if (STAT(mPath.get(), &mCachedStat) == -1) {
     // try lstat it may be a symlink
     if (LSTAT(mPath.get(), &mCachedStat) == -1) {
       return false;
     }
   }
   return true;
 }

I think either mPath was null or mPath.get() returned null.

I tried to figure out if there is a simple
mPath = this
assignment somewhere, but could not find it.
There was
mPath = aFile and a few other assignments, but it was not easy to figure out if somehow null |this| value could have been copied via these assignments indirectly.

For that matter, I don't know for sure if this mPath being nullptr is the result of gcc6.
It might as well be the case that the particular diskcache state may have caused
the error in gcc4-compiled binary even, i.e., mPath could have been null by error/bug/mistake, etc.

Like I said, the state of the disckcache changed after a few test runs, and I could no longer trigger the bug :-(

I am going to run xpcshell-test now, but I am afraid the latent bugs that may remain won't be weeded out
until try-comm-central begins using gcc6 (i have no idea: it probably uses clang ?)
and enough people start to use such test version from try-comm-central to exercise many different run-time situations.

OR, those who coded such tricky codes would come forward and confess the problems so that we can rewrite the parts :-)

TIA
(In reply to :aceman from comment #28)
> 2. find a c++ guru that can unroll the functions to not run with null 'this'
> but still run the needed code for null objects externally (just not from
> inside the null object).

I won't claim to be a C++ guru, but the obvious workaround is to turn the method into a class method by adding static to its definition, and add a parameter that replaces `this`. Then adjust the calls from instance->method(args) to Class::method(instance, args). And then you can check whether instance is null in the method.

The fact is, calling instance methods with null is not valid C++. So the compiler is free to assume that if the call happens, it means this is necessarily non-null, and can happily remove the corresponding check that will always be false.

Comment 42

6 months ago
Comment on attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

I started at comment 0, worked my way up, was thinking "this sure sounds like it should have been a static method", then see comment 41 as suggesting that.

Knowing little about these internal Mork workings, it seems to me that the low-risk route is what comment 41 suggested, which should be able to preserve the existing behavior. I'm going to remove the review request until this approach is considered.
Attachment #8806504 - Flags: review?(rkent)
(Assignee)

Updated

6 months ago
Attachment #8806504 - Flags: review?(acelists)
(Assignee)

Comment 43

6 months ago
Created attachment 8809921 [details] [diff] [review]
1278795-take2.patch (v1)

Here with a static function by popular demand.

Frederic and Martin can try this one, too.
Attachment #8809921 - Flags: review?(rkent)
(Reporter)

Comment 44

6 months ago
(In reply to Jorg K (GMT+1) from comment #43)
> Created attachment 8809921 [details] [diff] [review]
> 1278795-take2.patch (v1)
> 
> Here with a static function by popular demand.
> 
> Frederic and Martin can try this one, too.

Will try it asap today.
Flags: needinfo?(fredbezies)
(Reporter)

Comment 45

6 months ago
(In reply to Jorg K (GMT+1) from comment #43)
> Created attachment 8809921 [details] [diff] [review]
> 1278795-take2.patch (v1)
> 
> Here with a static function by popular demand.
> 
> Frederic and Martin can try this one, too.

Patch is working for me. Glad to comment export CFLAGS and CXXFLAGS I added in my .mozconfig to work around this bug.
(Assignee)

Comment 46

6 months ago
How about the other patch?
(Reporter)

Comment 47

6 months ago
(In reply to Jorg K (GMT+1) from comment #46)
> How about the other patch?

I only tried last patch.
(Assignee)

Comment 48

6 months ago
Understood. Please also try the first as I prefer the first solution (attachment 8806504 [details] [diff] [review]).
(Reporter)

Comment 49

6 months ago
(In reply to Jorg K (GMT+1) from comment #48)
> Understood. Please also try the first as I prefer the first solution
> (attachment 8806504 [details] [diff] [review]).

Both patches are working. No more crashes on start.
(Assignee)

Comment 50

6 months ago
Comment on attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

Kent, I like this one better. Yes, this one is more risky, but the static function is just prolonging the mess here. As Alta88 called it elsewhere:
"mindlessly cargo culted patch" ;-) (no offense intended since it's my own patch).
Flags: needinfo?(stransky)
Attachment #8806504 - Flags: review?(rkent)
(Assignee)

Comment 51

6 months ago
Note that I have a green try run for the first patch in comment #33.

Since I removed the checking |const morkAtom* atom = this; if ( atom )| it would have crashed on all platforms and all compilers. But it didn't. So patch 1 is good to go.

Comment 52

6 months ago
Comment on attachment 8809921 [details] [diff] [review]
1278795-take2.patch (v1)

Review of attachment 8809921 [details] [diff] [review]:
-----------------------------------------------------------------

I like this one better, but mostly because I don't have to try to understand why you are doing slightly different cleanup a various spots in the version 2 patch.
Attachment #8809921 - Flags: review?(rkent) → review+

Comment 53

6 months ago
Comment on attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

Review of attachment 8806504 [details] [diff] [review]:
-----------------------------------------------------------------

I'm not necessarily against this patch, but you would need to explain why you need the extra processing (that sometimes differs) at each point. So I prefer the other one.
Attachment #8806504 - Flags: review?(rkent)
(Assignee)

Comment 54

6 months ago
obslete
Comment on attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

Review of attachment 8806504 [details] [diff] [review]:
-----------------------------------------------------------------

::: db/mork/src/morkRowObject.cpp
@@ +330,5 @@
>              mdbYarn yarn;
> +            memset(&yarn, 0, sizeof(yarn));
> +            if (atom) {
> +              atom->AliasYarn(&yarn);
> +            }

Known call site where this was called with null. Need to fix. Best coding practise to zero out yarn and not just set some member variables in AliasYarn().

@@ +475,5 @@
> +      } else {
> +        outYarn->mYarn_Buf = 0;
> +        outYarn->mYarn_Fill = 0;
> +        outYarn->mYarn_Size = 0;
> +      }

Damn. My mistake, this one slipped me. Should be memset(&outYarn, 0, sizeof(outYarn)); here too, of course. So sorry!

@@ +502,5 @@
> +      } else {
> +        outYarn->mYarn_Buf = 0;
> +        outYarn->mYarn_Fill = 0;
> +        outYarn->mYarn_Size = 0;
> +      }

Another mistake. So sorry.

::: db/mork/src/morkWriter.cpp
@@ +1928,5 @@
>    mdbYarn yarn; // to ref content inside atom
> +  memset(&yarn, 0, sizeof(yarn));
> +  if (atom) {
> +    atom->AliasYarn(&yarn);
> +  }

Here it's done right.

@@ +1998,5 @@
>    mdbYarn yarn; // to ref content inside atom
> +  memset(&yarn, 0, sizeof(yarn));
> +  if (atom) {
> +    atom->AliasYarn(&yarn);
> +  }

Here it's done right.
Attachment #8806504 - Flags: review?(rkent)
Comment hidden (obsolete)
(Assignee)

Comment 56

6 months ago
Comment on attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

Review of attachment 8806504 [details] [diff] [review]:
-----------------------------------------------------------------

Ignore the previous comment. Here's the explanation.

::: db/mork/src/morkRowObject.cpp
@@ +330,5 @@
>              mdbYarn yarn;
> +            memset(&yarn, 0, sizeof(yarn));
> +            if (atom) {
> +              atom->AliasYarn(&yarn);
> +            }

Sorry again. Here we instantiate a new 'yarn' and zero it out.

@@ +480,1 @@
>      }

No mistake. Sorry again. Here we get passed a yarn into the function. So we don't want to zero it out, we need to set the fields the GetYarn() function would have set.

@@ +502,5 @@
> +      } else {
> +        outYarn->mYarn_Buf = 0;
> +        outYarn->mYarn_Fill = 0;
> +        outYarn->mYarn_Size = 0;
> +      }

No mistake. Again, outYarn passed in, we can't just zero it.

::: db/mork/src/morkWriter.cpp
@@ +1928,5 @@
>    mdbYarn yarn; // to ref content inside atom
> +  memset(&yarn, 0, sizeof(yarn));
> +  if (atom) {
> +    atom->AliasYarn(&yarn);
> +  }

Zeroing out new instance.

@@ +1998,5 @@
>    mdbYarn yarn; // to ref content inside atom
> +  memset(&yarn, 0, sizeof(yarn));
> +  if (atom) {
> +    atom->AliasYarn(&yarn);
> +  }

And again.
(Assignee)

Comment 57

6 months ago
Comment on attachment 8806504 [details] [diff] [review]
1278795.patch (v2)

I've changed my mind. It's ugly having this
+        outYarn->mYarn_Buf = 0;
+        outYarn->mYarn_Fill = 0;
+        outYarn->mYarn_Size = 0;
in the various call sites. It's better to centralise this processing in the function.
Attachment #8806504 - Attachment is obsolete: true
Attachment #8806504 - Flags: review?(rkent)
(Assignee)

Comment 58

6 months ago
Let's go with the static function.

https://hg.mozilla.org/comm-central/rev/f88a5eda49535c043f7b61cb11582b2a7c920b9f

Frederic, would you like this backported to TB 52, the next ESR?
Status: ASSIGNED → RESOLVED
Last Resolved: 6 months ago
Flags: needinfo?(fredbezies)
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 53.0
(Reporter)

Comment 59

6 months ago
(In reply to Jorg K (GMT+1) from comment #58)
> Let's go with the static function.
> 
> https://hg.mozilla.org/comm-central/rev/
> f88a5eda49535c043f7b61cb11582b2a7c920b9f
> 
> Frederic, would you like this backported to TB 52, the next ESR?

It will be great for archlinux and other distributions using gcc 6.x. So, yes I will like it to be backported to TB52.
Flags: needinfo?(fredbezies)
(Assignee)

Comment 60

6 months ago
Comment on attachment 8809921 [details] [diff] [review]
1278795-take2.patch (v1)

Let's backport this for our advanced (GCC6) (Arch)linux friends after a few days on trunk.
Attachment #8809921 - Flags: approval-comm-aurora+
Crash Signature: [@ libxul.so@0xa94024 | libxul.so@0xaa1ea0 | libxul.so@0xbac32d | thunderbird@0x12e18] [@ morkAtom::AliasYarn] → [@ libxul.so@0xa94024 | libxul.so@0xaa1ea0 | libxul.so@0xbac32d | thunderbird@0x12e18] [@ morkAtom::AliasYarn] [@ thunderbird@0x5d2b]
(Assignee)

Comment 61

6 months ago
Aurora (TB 52):
https://hg.mozilla.org/releases/comm-aurora/rev/7cec34d086b72f4b6b3a467450ca043b7a56afce
status-thunderbird51: --- → wontfix
status-thunderbird52: --- → fixed
status-thunderbird53: --- → fixed
You need to log in before you can comment on or make changes to this bug.