Closed
Bug 512940
Opened 15 years ago
Closed 15 years ago
Adding bookmarks crashes Firefox when using system SQLite newer than 3.6.16
Categories
(Firefox :: Bookmarks & History, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: a.nielsen, Unassigned)
References
Details
(Keywords: crash)
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090815 Gentoo Firefox/3.5.2 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090815 Gentoo Firefox/3.5.2 When you add a new bookmark a window pops up where you can choose a name and location. If you click the little arrow next to 'Folder' (to display the full folder list) Firefox crashes. Reproducible: Always Steps to Reproduce: 1. Go to the Bookmarks menu and choose Bookmark this page. 2. Click the right-most button on the field named "Folder:" 3. Crash Actual Results: Firefox crashes, and always says "well this is embarrassing" when reloading Expected Results: The list of bookmark folders appears, like previous versions No crash logging software seems to be installed, and I can't find instructions on how to install 'Breakpad'
Comment 1•15 years ago
|
||
(In reply to comment #0) > No crash logging software seems to be installed, and I can't find instructions > on how to install 'Breakpad' You'll need to either use Mozilla's build and get a crash ID or use GDB. Mozilla crash reporter instructions are here: http://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report which links to Gentoo specific GDB instructions here: http://www.gentoo.org/doc/en/bugzilla-howto.xml#doc_chap2 I suggest you first try testing a Mozilla build. http://getfirefox.com/
Comment 2•15 years ago
|
||
same as bug 512931?
Reporter | ||
Comment 3•15 years ago
|
||
It looks like the same bug, except mine doesn't crash until I view the folder list. Thanks Dave, I recompiled with (some) debugging info, and it looks like the crash occurs in sqlite code. I don't know where that sqlite3.c file comes from (it doesn't seem to be included in the sqlite source) so maybe it's some kind of combined file? I'm running sqlite-3.6.17. (And it must be external to Firefox because I didn't get the sqlite function names listed until I recompiled sqlite with debug info.) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffee24ae700 (LWP 15173)] 0x00007ffedea57a08 in sqlite3BtreeGetMeta (p=0x7ffecffbf108, idx=1, pMeta=0x7fffeba27510) at sqlite3.c:43941 43941 sqlite3.c: No such file or directory. in sqlite3.c (gdb) bt #0 0x00007ffedea57a08 in sqlite3BtreeGetMeta (p=0x7ffecffbf108, idx=1, pMeta=0x7fffeba27510) at sqlite3.c:43941 #1 0x00007ffedeaa0db3 in sqlite3VdbeExec (p=0x7ffece9f6928) at sqlite3.c:53728 #2 0x00007ffedea923ae in sqlite3_step (pStmt=0x7ffece9f6928) at sqlite3.c:49503 #3 0x00007ffedf7fb9cd in mozStorageStatement::ExecuteStep (this=0x7ffece755fb0, _retval=0x7fffeba279fc) at mozStorageStatement.cpp:568 #4 0x00007ffedf828aaa in nsNavBookmarks::ResultNodeForContainer (this=0x7ffee0cf2e40, aID=307, aOptions=0x7ffeabfafc40, aNode=0x7fffeba27a70) at nsNavBookmarks.cpp:2404 #5 0x00007ffedf828dc6 in nsNavBookmarks::QueryFolderChildren (this=0x7ffee0cf2e40, aFolderId=<value optimized out>, aOptions=0x7ffeabfafc40, aChildren=0x7ffea2167ee8) at nsNavBookmarks.cpp:2491 #6 0x00007ffedf81ffb4 in nsNavHistoryFolderResultNode::FillChildren (this=0x7ffea2167e40) at nsNavHistoryResult.cpp:3239 #7 0x00007ffedf82041d in nsNavHistoryFolderResultNode::OpenContainer (this=0x7ffecffbf108) at nsNavHistoryResult.cpp:3059 #8 0x00007ffedf81e566 in nsNavHistoryContainerResultNode::SetContainerOpen (this=0x7ffecffbf108, aContainerOpen=1) at nsNavHistoryResult.cpp:449 #9 0x00007ffedf914930 in NS_InvokeByIndex_P (that=0x7ffea2167ed0, methodIndex=21, paramCount=1, params=0x28) at xptcinvoke_x86_64_linux.cpp:208 #10 0x00007ffedf159088 in XPCWrappedNative::CallMethod (ccx=@0x7fffeba281f0, mode=10) at xpcwrappednative.cpp:2454 #11 0x00007ffedf160c20 in XPC_WN_GetterSetter (cx=0x7ffed31cd800, obj=<value optimized out>, argc=1, argv=0x7ffea06eac40, vp=0x7fffeba283e0) at xpcprivate.h:2326 #12 0x00007ffee078f78b in js_Invoke (cx=0x7ffed31cd800, argc=1, vp=0x7ffea06eac30, flags=2) at jsinterp.cpp:1386 #13 0x00007ffee078faea in js_InternalInvoke (cx=0x7ffed31cd800, obj=0x7ffeab97cec0, fval=140731777316416, flags=0, argc=1, argv=<value optimized out>, rval=0x7fffeba287c8) at jsinterp.cpp:1447 #14 0x00007ffee078fc27 in js_InternalGetOrSet (cx=0x7ffed31cd800, obj=0x7ffeab97cec0, id=140732402653460, fval=140731777316416, mode=JSACC_WRITE, argc=1, argv=0x7fffeba287c8, rval=0x7fffeba287c8) at jsinterp.cpp:1510 #15 0x00007ffee0796010 in js_SetSprop (cx=0x7ffed31cd800, sprop=0x7ffebd9c3be0, obj=0x1, vp=0x7fffeba287c8) at jsscope.h:390 #16 0x00007ffee079655b in js_NativeSet (cx=0x7ffed31cd800, obj=0x7ffeab97cec0, sprop=0x7ffebd9c3be0, vp=0x7fffeba287c8) at jsobj.cpp:4226 #17 0x00007ffee0797281 in js_SetPropertyHelper (cx=0x7ffed31cd800, obj=0x7ffeab97cec0, id=140732402653460, cacheResult=1, vp=0x7fffeba287c8) at jsobj.cpp:4590 #18 0x00007ffee078100a in js_Interpret (cx=0x7ffed31cd800) at jsinterp.cpp:4789 #19 0x00007ffee078f795 in js_Invoke (cx=0x7ffed31cd800, argc=1, vp=0x7ffea06ea928, flags=0) at jsinterp.cpp:1394 ... (gdb) print p $1 = (Btree *) 0x7ffecffbf108 (gdb) print *p $2 = {db = 0x7ffed03c9808, pBt = 0x7ffed03592c8, inTrans = 1 '\001', sharable = 0 '\0', locked = 0 '\0', wantToLock = 0, nBackup = 0, pNext = 0x0, pPrev = 0x0, lock = {pBtree = 0x7ffecffbf108, iTable = 1, eLock = 0 '\0', pNext = 0x0}} (gdb) print *pMeta $3 = 3489394952 (gdb) print pMeta $4 = (u32 *) 0x7fffeba27510 Let me know if I can do anything further to get some more info.
I am having exactly the same issue. I was not able to get the complete backtrace output since gdb is crashing for me as well, but this is what I got. It seems also related to sqlite 3: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7ce86e0 (LWP 20173)] 0xb6ae518d in sqlite3BtreeGetMeta () from /usr/lib/libsqlite3.so.0 (gdb) Hangup detected on fd 0 Error detected on fd 0 error detected on stdin
Comment 5•15 years ago
|
||
In about:buildconfig, what are your "Configure arguments"?
These are my "Configure arguments": --enable-application=xulrunner --prefix=/usr --libdir=/usr/lib --with-system-nspr --with-system-nss --with-system-jpeg --with-system-zlib --with-system-bz2 --with-system-png --enable-system-hunspell --enable-system-sqlite --enable-system-cairo --with-pthreads --enable-strip --disable-tests --disable-mochitest --disable-installer --disable-debug --enable-optimize --enable-default-toolkit=cairo-gtk2 --enable-pango --enable-svg --enable-canvas --disable-javaxpcom --disable-crashreporter --enable-safe-browsing --enable-startup-notification
Comment 7•15 years ago
|
||
> --enable-system-sqlite
Because you are crashing in SQLite, this is a bug with your distribution's build of Firefox. You should report it with them.
If you can reproduce this with a build released by Mozilla, please re-open.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
Given that this bug is happening in Icecat and Arch Linux's regular build of Firefox (see https://bugzilla.mozilla.org/show_bug.cgi?id=512931) and it's happening in Gentoo's build of Firefox, it really doesn't seem like this is a due to one particular distributions build of Firefox, but rather has come from Firefox itself. No?
Comment 9•15 years ago
|
||
All of those distros use system SQLite as far as I know. System SQLite isn't supported by Mozilla (in fact we discourage it's use).
Reporter | ||
Comment 10•15 years ago
|
||
I raised the issue with Gentoo (http://bugs.gentoo.org/show_bug.cgi?id=283083) and their response is that using bundled libraries is against Gentoo's policy for a number of reasons (see http://blog.flameeyes.eu/2009/01/02/bundling-libraries-for-despair-and-insecurity) I can see their point, so I guess my question is this: Why does Firefox need a bundled version of sqlite? Presumably it will have to be upgraded at some point in the future, won't this bug crop up then? Isn't it worth fixing now, to make that transition easier?
Comment 11•15 years ago
|
||
I never said that using system libraries was wrong - it's simply unsupported. We cannot test and support ever version of SQLite that comes out because behaviors change (in terms of functionality and performance) between releases. Our trunk development tends to stay within one release of SQLite's latest, but branches don't usually get upgraded unless there is some serious issue. If a release has an issue, we report the bug to SQLite and wait to upgrade until it's in a stable release. If distributions want to use system libraries, they can. I sure hope they run our unit tests before hand though to ensure that the things we have automated tests for are at least going to run as we expect them to. In the past, I know distributions have not done this much, and I'm not sure if this has changed.
Reporter | ||
Comment 12•15 years ago
|
||
Sorry if this is a silly question, but how do you run these unit tests? I can find a lot of information about the tests but no instructions on running them for a non-developer such as myself (and perhaps my distribution's package maintainer.) I have the source compiled, but the only thing I can find is an MDC page that says "just run make check" which doesn't work...
Comment 13•15 years ago
|
||
If you didn't enable tests in your .mozconfig, I'm not sure make check would work. I've gone and updated https://developer.mozilla.org/en/Mozilla_automated_testing with the right test targets for our different harnesses. All of these commands should be ran from your object directory.
Comment 14•15 years ago
|
||
Does this mean that reverting to an older version of SQLite would solve the problem? What version is Firefox bundled with now? Or does this mean that if I install Firefox from source, I'll get the bundled libraries and that will solve the problem? In Arch I can see that the package sqlite3 was updated to 3.6.17-1 on August 23rd and lib32-sqlite3 was upgraded to 3.6.17-1 on August 24th. That seems like when I started seeing the bug. And I don't really know anything about this, but I wouldn't be surprised that bundled libraries don't fit into the Arch way of doing things.
Comment 15•15 years ago
|
||
Nevermind. I figured out how to downgrade to sqlite 3.6.16 and that solved the problem.
Reporter | ||
Comment 16•15 years ago
|
||
Are you running Firefox 3.5.2? I downgraded to sqlite 3.6.16 and Firefox said it was too old and refused to run (I tried recompiling it, no change.) sqlite 3.6.17 is the only newer version, and it makes Firefox crash :-( The Mozilla source seems to include version 3.6.10, so I'm not sure what's going on there... I finally figured out how to find my object directory and run the tests and there are quite a few failures (using my distro's configure params) so I guess there are a few reasons to use the official binary...and I guess judging from that, no, my distribution doesn't run the tests :-( Although I have to say, the information about how to run the tests (and precisely what they test) is well hidden...maybe it could be highlighted a bit better to persuade the various distros to run the tests, in the interests of avoiding bug reports like this. (Especially to make it obvious which tests check for compilation correctness, because the other tests like HTML rendering aren't necessary in this situation.) But at least this explains why Firefox 3.5 seems so much less reliable than 3.0, so hopefully switching to the official release will fix that. Thanks everyone for your help (and tolerance!), I appreciate it.
Comment 17•15 years ago
|
||
Firefox 3.7pre builds run SQLite 3.6.16 Firefox 3.6pre builds run SQLite 3.6.16 Firefox 3.5 builds run SQLite 3.6.10 Firefox 3.0 builds run SQLite 3.6.10 (In reply to comment #16) > Are you running Firefox 3.5.2? I downgraded to sqlite 3.6.16 and Firefox said > it was too old and refused to run (I tried recompiling it, no change.) sqlite > 3.6.17 is the only newer version, and it makes Firefox crash :-( That's probably because your package of Firefox was compiled with 3.6.17, and we don't let you downgrade with what you compiled with (only upgrade). > I finally figured out how to find my object directory and run the tests and > there are quite a few failures (using my distro's configure params) so I guess > there are a few reasons to use the official binary...and I guess judging from > that, no, my distribution doesn't run the tests :-( Although I have to say, > the information about how to run the tests (and precisely what they test) is > well hidden...maybe it could be highlighted a bit better to persuade the > various distros to run the tests, in the interests of avoiding bug reports like > this. (Especially to make it obvious which tests check for compilation > correctness, because the other tests like HTML rendering aren't necessary in > this situation.) HTML rendering tests will end up using system libraries too, so it's a good idea to run those as well.
Comment 18•15 years ago
|
||
Huh, I'm using 3.6.16 in Arch Linux with 3.5.2, although technically I'm running Icecat, but I don't see why that would effect this issue. But others in Arch who were seeing the bookmark crashing problem also successfully downgraded to 3.6.16 running regular Firefox.
Reporter | ||
Comment 19•15 years ago
|
||
Ok my mistake, after downgrading sqlite I had to recompile XULRunner, not Firefox. Now it's working fine with sqlite 3.6.16 and no crash :-) Also in regard to the tests I was thinking more of Gentoo - since the package installer compiles everything from source on your local PC, they won't want to run tests that pop up windows for 15 minutes during the installation. But something quick like 'make check' I'm sure won't be a problem to get included in the build process, and is really the only way to go given that almost every Gentoo user will have a slightly different set up (library versions etc.)
Updated•15 years ago
|
Hardware: x86 → All
Summary: Adding bookmarks crashes Firefox → Adding bookmarks crashes Firefox when using system SQLite newer than 3.6.16
Comment 21•15 years ago
|
||
(In reply to comment #19) > Also in regard to the tests I was thinking more of Gentoo - since the package > installer compiles everything from source on your local PC, they won't want to > run tests that pop up windows for 15 minutes during the installation. But > something quick like 'make check' I'm sure won't be a problem to get included > in the build process, and is really the only way to go given that almost every > Gentoo user will have a slightly different set up (library versions etc.) It's more than 15 minutes, and just |make check| is a very very small portion of our tests.
You need to log in
before you can comment on or make changes to this bug.
Description
•