724227 - Alpine Linux firefox-10.0 segfaults at startup within libmozsqlite3

Status: RESOLVED INVALID

(Core :: SQLite and Embedded Database Bindings, defect)

Description

[Natanael Copa]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20120112 Firefox/9.0.1
Build ID: 20120112142007

Steps to reproduce:

I removed ~/.mozilla (i.e no plugins installed at all) and  started firefox build against uClibc on Alpine Linux.



Actual results:

segfault:

(gdb) bt
#0  0x52bd05d7 in ?? () from /usr/lib/libsqlite3.so
#1  0x52c0b489 in ?? () from /usr/lib/libsqlite3.so
#2  0x52c0df16 in ?? () from /usr/lib/libsqlite3.so
#3  0x52c0f95e in ?? () from /usr/lib/libsqlite3.so
#4  0x52c0fc99 in ?? () from /usr/lib/libsqlite3.so
#5  0x51bb20ef in mozilla::storage::prepareStmt (aDatabase=0x4bbc9400, 
    aSQL=..., _stmt=0x5d610758)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/storage/src/mozStoragePrivateHelpers.cpp:319
#6  0x51ba8146 in mozilla::storage::Connection::initialize (this=0x4bb505e0, 
    aDatabaseFile=0x4bbf7c80, aVFSName=0x0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/storage/src/mozStorageConnection.cpp:555
#7  0x51ba51f9 in mozilla::storage::Service::OpenUnsharedDatabase (
    this=0x4bb54fc0, aDatabaseFile=0x4bbf7c80, _connection=0x5d610aa0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/storage/src/mozStorageService.cpp:603
#8  0x51e5ca20 in NS_InvokeByIndex_P () from /usr/lib/xulrunner-10.0/libxul.so
#9  0x519ff3a4 in Invoke (this=0x5d610a68)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/xpconnect/src/XPCWrappedNative.cpp:2882
#10 Call (this=0x5d610a68)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/xpconnect/src/XPCWrappedNative.cpp:2189
#11 XPCWrappedNative::CallMethod (ccx=..., mode=XPCWrappedNative::CALL_METHOD)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/xpconnect/src/XPCWrappedNative.cpp:2155
#12 0x51a05554 in XPC_WN_CallMethod (cx=0x52d198a0, argc=1, vp=0x4c100478)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1554
#13 0x51fc145b in CallJSNative (args=..., native=<optimized out>, 
    cx=0x52d198a0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jscntxtinlines.h:297
#14 js::InvokeKernel (cx=0x52d198a0, args=..., construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:629
#15 0x51fbb6a1 in js::Interpret (cx=0x52d198a0, entryFrame=0x4c1002b0, 
    interpMode=js::JSINTERP_NORMAL)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:3948
#16 0x51fc14ed in js::InvokeKernel (cx=0x52d198a0, args=..., 
    construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:647
#17 0x51f77d05 in js::Invoke (cx=0x52d198a0, args=..., 
    construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.h:148
#18 0x51f96837 in js_fun_apply (cx=0x52d198a0, argc=2, vp=0x4c100268)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsfun.cpp:1817
#19 0x51fc145b in CallJSNative (args=..., native=<optimized out>, 
    cx=0x52d198a0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jscntxtinlines.h:297
#20 js::InvokeKernel (cx=0x52d198a0, args=..., construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:629
#21 0x51fbb6a1 in js::Interpret (cx=0x52d198a0, entryFrame=0x4c100188, 
    interpMode=js::JSINTERP_NORMAL)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:3948
#22 0x51fc14ed in js::InvokeKernel (cx=0x52d198a0, args=..., 
    construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:647
#23 0x51f77d05 in js::Invoke (cx=0x52d198a0, args=..., 
    construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.h:148
#24 0x51f6fdcd in array_readonlyCommon<ArrayForEachBehavior> (
    args=<synthetic pointer>, cx=0x52d198a0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsarray.cpp:3369
#25 array_forEach (cx=0x52d198a0, argc=1, vp=0x4c100130)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsarray.cpp:3406
#26 0x51fc145b in CallJSNative (args=..., native=<optimized out>, 
    cx=0x52d198a0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jscntxtinlines.h:297
#27 js::InvokeKernel (cx=0x52d198a0, args=..., construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:629
#28 0x51fbb6a1 in js::Interpret (cx=0x52d198a0, entryFrame=0x4c100038, 
    interpMode=js::JSINTERP_NORMAL)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:3948
#29 0x51fc14ed in js::InvokeKernel (cx=0x52d198a0, args=..., 
    construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:647
#30 0x51f77d05 in js::Invoke (cx=0x52d198a0, args=..., 
    construct=js::NO_CONSTRUCT)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.h:148
#31 0x51fc1830 in js::Invoke (cx=0x52d198a0, thisv=..., fval=..., argc=3, 
    argv=0x5d611edc, rval=0x5d611d30)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsinterp.cpp:679
#32 0x51f67454 in JS_CallFunctionValue (cx=0x52d198a0, obj=0x4bf6c7d8, 
    fval=..., argc=3, argv=0x5d611edc, rval=0x5d611d30)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/src/jsapi.cpp:5199
#33 0x519f8a18 in nsXPCWrappedJSClass::CallMethod (this=0x4cd9d250, wrapper=
    0x4cdcee00, methodIndex=3, info=0x4e1d9dd8, nativeParams=0x5d612078)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/xpconnect/src/XPCWrappedJSClass.cpp:1530
#34 0x519f274f in nsXPCWrappedJS::CallMethod (this=0x4cdcee00, methodIndex=3, 
    info=0x4e1d9dd8, params=0x5d612078)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/js/xpconnect/src/XPCWrappedJS.cpp:611
#35 0x51e5d517 in PrepareAndDispatch (methodIndex=<optimized out>, self=
    0x4e1220e0, args=<optimized out>)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:92
#36 0x5109b722 in DoStartup (this=0x5d61223c)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/toolkit/xre/nsXREDirProvider.cpp:741
#37 nsXREDirProvider::DoStartup (this=0x5d61223c)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/toolkit/xre/nsXREDirProvider.cpp:727
#38 0x510987d9 in XRE_main (argc=1, argv=0x5d6168a4, aAppData=0x52d33380)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/toolkit/xre/nsAppRunner.cpp:3423
#39 0x11b22c6c in main (argc=1, argv=0x5d6168a4)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/xulrunner/stub/nsXULStub.cpp:516



Expected results:

start up normal, just like firefox-9 does.

Comment 1

[Natanael Copa]

The 9.0.1 release works with same setup.

Also file in Alpine Linux bugtracker:
http://bugs.alpinelinux.org/issues/995

The scripts used for the build are here:
http://git.alpinelinux.org/cgit/aports/tree/testing/xulrunner
http://git.alpinelinux.org/cgit/aports/tree/testing/firefox

I can build libsqlite3 with debugging symbols on request.

Thanks!

Comment 2

[Makoto Kato [:m_kato]]

If our build, we use libmozsqlite3.so, not libsqlite3.  So this seems to be custom build of Alpine linux issue...  You should file a bug to Alpine Linux.

Comment 3

[Natanael Copa]

(In reply to Makoto Kato from comment #2)
> If our build, we use libmozsqlite3.so, not libsqlite3.  So this seems to be
> custom build of Alpine linux issue... 

Yes, we build it with ac_add_options --enable-system-sqlite so we avoid duplicate sqlite.

> You should file a bug to Alpine Linux.

I did: http://bugs.alpinelinux.org/issues/995

It will likely be me who will have to fix it. Any ideas what have changed that possible could have caused this? As said, this worked just fine with firefox-9.

Thanks!

Comment 4

[Natanael Copa]

(In reply to Makoto Kato from comment #2)
> If our build, we use libmozsqlite3.so, not libsqlite3.  So this seems to be
> custom build of Alpine linux issue...  You should file a bug to Alpine Linux.

It happens with libmozsqlite3.so too:

(gdb) run
Starting program: /usr/lib/firefox-10.0/firefox 
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x4e685885 in sqlite3VdbeMakeReady (p=0x4879be80, pParse=0x475c9c00)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:59049
59049	/home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c: No such file or directory.
	in /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c
(gdb) bt
#0  0x4e685885 in sqlite3VdbeMakeReady (p=0x4879be80, pParse=0x475c9c00)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:59049
#1  0x4e6d2a7f in sqlite3FinishCoding (pParse=0x475c9c00)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:77539
#2  yy_reduce (yyruleno=8, yypParser=0x475fc000)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:39865
#3  sqlite3Parser (yyp=0x475fc000, yymajor=1, yyminor=..., pParse=0x475c9c00)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:41105
#4  0x4e6d6146 in sqlite3RunParser (pParse=0x475c9c00, 
    zSql=0x58c8019c "PRAGMA page_size = 32768", pzErrMsg=0x58c7ff34)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:107477
#5  0x4e6d93df in sqlite3Prepare (db=0x475c9400, 
    zSql=0x58c8019c "PRAGMA page_size = 32768", nBytes=-1, saveSqlFlag=1, 
    pReprepare=0x0, ppStmt=0x58c80098, pzTail=0x0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:90212
#6  0x4e6d971a in sqlite3LockAndPrepare (pzTail=0x0, ppStmt=0x58c80098, 
    pOld=0x0, saveSqlFlag=1, nBytes=-1, 
    zSql=0x58c8019c "PRAGMA page_size = 32768", db=0x475c9400)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:90304
#7  sqlite3LockAndPrepare (db=0x475c9400, 
    zSql=0x58c8019c "PRAGMA page_size = 32768", nBytes=-1, saveSqlFlag=1, 
    pOld=0x0, ppStmt=0x58c80098, pzTail=0x0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/db/sqlite3/src/sqlite3.c:24751
#8  0x4d56e0ef in mozilla::storage::prepareStmt (aDatabase=0x475c9400, 
    aSQL=..., _stmt=0x58c80098)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/storage/src/mozStoragePrivateHelpers.cpp:319
#9  0x4d564146 in mozilla::storage::Connection::initialize (this=0x475515e0, 
    aDatabaseFile=0x475f7c80, aVFSName=0x0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/storage/src/mozStorageConnection.cpp:555
#10 0x4d5611f9 in mozilla::storage::Service::OpenUnsharedDatabase (
    this=0x47556140, aDatabaseFile=0x475f7c80, _connection=0x58c803e0)
    at /home/buildozer/aports/testing/xulrunner/src/mozilla-release/storage/src/mozStorageService.cpp:603
#11 0x4d818a20 in NS_InvokeByIndex_P () from /usr/lib/xulrunner-10.0/libxul.so
...

Comment 5

[Natanael Copa]

Digging a little bit more, now that I have the debugging on in the sqlite code.

From the sqlite3.c file where it happens:
  ...
  /* Allocate space for memory registers, SQL variables, VDBE cursors and 
  ** an array to marshal SQL function arguments in.
  */
  zCsr = (u8*)&p->aOp[p->nOp];       /* Memory avaliable for allocation */
  zEnd = (u8*)&p->aOp[p->nOpAlloc];  /* First byte past end of zCsr[] */

  resolveP2Values(p, &nArg);
  p->usesStmtJournal = (u8)(pParse->isMultiWrite && pParse->mayAbort);
  if( pParse->explain && nMem<10 ){
    nMem = 10;
  }
  memset(zCsr, 0, zEnd-zCsr); /* here it happens, line 59049 */
  ...

The memset goes wrong. what are those pointers pointing to?

(gdb) print zCsr
$1 = (u8 *) 0x460ca014 ""
(gdb) print zEnd
$2 = (u8 *) 0x460ca000 "\006"


Note that zEnd points to an address that is lower than zCsr, which it definitively should not. How it ends up in that state I have no idea.

Comment 6

[Natanael Copa]

I would guess that commit 8b6d54721fa1 introduced this.

Comment 7

[Makoto Kato [:m_kato]]

> (In reply to Makoto Kato from comment #2)
> > If our build, we use libmozsqlite3.so, not libsqlite3.  So this seems to be
> > custom build of Alpine linux issue... 
> 
> Yes, we build it with ac_add_options --enable-system-sqlite so we avoid
> duplicate sqlite.

When they don't use --enable-system-sqlite, does this problem still occur?  If this doesn't occur, you should request that they don't use --enable-system-sqlite.

This may be compatible issue of upper version of sqlite3.  (I don't know sqlite3 version of Alpine Linux.)

Comment 8

[Natanael Copa]

(In reply to Makoto Kato from comment #7)
> > (In reply to Makoto Kato from comment #2)
> > > If our build, we use libmozsqlite3.so, not libsqlite3.  So this seems to be
> > > custom build of Alpine linux issue... 
> > 
> > Yes, we build it with ac_add_options --enable-system-sqlite so we avoid
> > duplicate sqlite.
> 
> When they don't use --enable-system-sqlite, does this problem still occur? 

Yes. Thats why I changed the summary to use libmozsqlite3. Comment #4 also includes the backtrace using libmozsqlite3, without --enable-system-sqlite.

> If this doesn't occur, you should request that they don't use
> --enable-system-sqlite.

It happens without the --enable-system-sqlite.

> This may be compatible issue of upper version of sqlite3.

Most likely not, since it happens with libmozsqlite3 too. The backtrace looks very similar. (see comment #4)

> (I don't know sqlite3 version of Alpine Linux.)

I didn't bother to mention the version number since it also happens with the libmozsqlite3, (but its the latest, 3.7.10)

Comment 9

[Makoto Kato [:m_kato]]

(In reply to Natanael Copa from comment #8)
> Yes. Thats why I changed the summary to use libmozsqlite3. Comment #4 also
> includes the backtrace using libmozsqlite3, without --enable-system-sqlite.

Can you reproduce when using official build from ftp://ftp.mozilla.org/?

If it cannot reproduce using it, is this compiler issue that Alpine Linux uses?

Comment 10

[Natanael Copa]

(In reply to Makoto Kato from comment #9)
> (In reply to Natanael Copa from comment #8)
> > Yes. Thats why I changed the summary to use libmozsqlite3. Comment #4 also
> > includes the backtrace using libmozsqlite3, without --enable-system-sqlite.
> 
> Can you reproduce when using official build from ftp://ftp.mozilla.org/?

There are no official build against uClibc, so there is nothing I can test.
 
> If it cannot reproduce using it, is this compiler issue that Alpine Linux
> uses?

I cannot run it since there are no official build that links against uClibc.

But the Alpine Linux toolchain has worked since firefox-3.6.14 so it is kind of strange that it shows up here and now. The problem happens with both with the system sqlite-3.7.10 (latest) *and* the libmozsqlite3 fork. It happens both on x86 and x86_64 and it happens on both release-build and debug build (so its most likely not an compiler optimisation bug).

That said, the Alpine Linux toolchain is hardened so it is fairly good at detecting bugs (including security bugs) early.

Comment 11

[Natanael Copa]

This bug happened due to a stupid Alpine Linux specific patch. Sorry for the noise.