Bug 1312635 - crash at startup
crash at startup
Status: CLOSED DUPLICATE of bug 1309593
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Martin Stransky
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2016-02-28 05:49 EST by Stas Sergeev
Modified: 2016-02-29 06:55 EST (History)
4 users (show)

See Also:
Fixed In Version: thunderbird-38.6.0-6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-02-29 03:48:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stas Sergeev 2016-02-28 05:49:16 EST
Description of problem:
thunderbird doesn't start

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. run thunderbird

Actual results:

Expected results:
should work

Additional info:

Thread 1 "thunderbird" received signal SIGSEGV, Segmentation fault.
0x00007ffff1a8ef1c in morkAtom::AliasYarn (this=0x0, 
    at /usr/src/debug/thunderbird-38.6.0/comm-esr38/db/mork/src/morkAtom.cpp:145
145	  outYarn->mYarn_Form = 0;
(gdb) bt
#0  0x00007ffff1a8ef1c in morkAtom::AliasYarn(mdbYarn*) const (this=0x0, outYarn=outYarn@entry=0x7fffffff7518)
    at /usr/src/debug/thunderbird-38.6.0/comm-esr38/db/mork/src/morkAtom.cpp:145
#1  0x00007ffff1a9ac6d in morkRowObject::AliasCellYarn(nsIMdbEnv*, unsigned int, mdbYarn*) (this=0x7fffbef2f4a0, mev=<optimized out>, inColumn=136, outYarn=0x7fffffff7518)
    at /usr/src/debug/thunderbird-38.6.0/comm-esr38/db/mork/src/morkRowObject.cpp:492
#2  0x00007ffff1bb6b44 in nsMsgDatabase::RowCellColumnToUInt32(nsIMdbRow*, unsigned int, unsigned int*, unsigned int) (this=<optimized out>, hdrRow=<optimized out>, columnToken=<optimized out>, uint32Result=uint32Result@entry=0x7fffbf065ff8, defaultValue=defaultValue@entry=0)
    at /usr/src/debug/thunderbird-38.6.0/comm-esr38/mailnews/db/msgdb/src/nsMsgDatabase.cpp:3742

Please note "this=0x0" in the beginning.

(gdb) disas
Dump of assembler code for function morkAtom::AliasYarn(mdbYarn*) const:
   0x00007ffff1a8ef0e <+0>:	movl   $0x0,0x10(%rsi)
   0x00007ffff1a8ef15 <+7>:	movl   $0x0,0x14(%rsi)
=> 0x00007ffff1a8ef1c <+14>:	mov    (%rdi),%al
   0x00007ffff1a8ef1e <+16>:	cmp    $0x62,%al
   0x00007ffff1a8ef20 <+18>:	jne    0x7ffff1a8ef28 <morkAtom::AliasYarn(mdbYarn*) const+26>
(gdb) p /x $rdi
$7 = 0x0

So we are accessing the NULL ptr here.

(gdb) up
#1  0x00007ffff1a9ac6d in morkRowObject::AliasCellYarn (this=0x7fffbef2f4a0, 
    mev=<optimized out>, inColumn=136, outYarn=0x7fffffff7518)
    at /usr/src/debug/thunderbird-38.6.0/comm-esr38/db/mork/src/morkRowObject.cpp:492
492	      atom->AliasYarn(outYarn);
(gdb) list
487	  if ( ev )
488	  {
489	    if ( mRowObject_Store && mRowObject_Row)
490	    {
491	      morkAtom* atom = mRowObject_Row->GetColumnAtom(ev, inColumn);
492	      atom->AliasYarn(outYarn);
493	      // note nil atom works and sets yarn correctly

Note the comment that "nil atom works".
Sorry but whoever thinks NULL pointer derefs should always
work, should not write code. Maybe gcc did some optimization here,
or maybe this method became virtual and therefore needs vtbl -
whi knows?
The NULL check should be added.
Comment 1 Stas Sergeev 2016-02-28 06:12:06 EST
Much betetr fix would be to make AliasYarn static,
and pass atom as a parameter. Currently the first
thing it doesn, is:

const morkAtom* atom = this;

So it just asks for being static.

Of course this all may also indicate some gcc-6 bug.
So lets involve Jakub to CC.
Comment 2 Jakub Jelinek 2016-02-28 06:53:38 EST
See http://gcc.gnu.org/gcc-6/porting_to.html
You can use -fno-delete-null-pointer-checks as a workaround, but definitely fix the buggy app.
// note nil atom works and sets yarn correctly
// note nil atom is invalid C++, so can't work "correctly"
and adjust the code correspondingly.
Comment 3 Stas Sergeev 2016-02-28 07:14:44 EST
OK so thunderbird should use -Wnonnull-compare to
get the warning for this problem.
Comment 4 Jakub Jelinek 2016-02-28 07:56:19 EST
Or developers should build it with -fsanitize=undefined and the bugs would be reported at runtime.
Comment 5 Martin Stransky 2016-02-29 03:48:22 EST
Thanks. This is a dupe of Bug 1309593. Updated package thunderbird-38.6.0-6 is already in koji...not sure if I need to submit a F24 update after branching.

*** This bug has been marked as a duplicate of bug 1309593 ***
Comment 6 Stas Sergeev 2016-02-29 06:38:42 EST
> not sure if I need to submit a F24 update after branching.
What do you mean by this?
Will I get an F24 update if you don't?
Comment 7 Martin Stransky 2016-02-29 06:55:22 EST
(In reply to Stas Sergeev from comment #6)
> > not sure if I need to submit a F24 update after branching.
> What do you mean by this?
> Will I get an F24 update if you don't?

I just checked by F24 system and the fixed package is available in updates. AFAIK One may need to submit an updated package by Bodhi later in the F24 release cycle, maybe after Alpha/Beta.

Note You need to log in before you can comment on or make changes to this bug.