Closed Bug 461311 Opened 17 years ago Closed 17 years ago

Firefox crashes on DB writes (using old SQLite 3.4.x system library) [@ mozStorageStatement::ExecuteStep ]

Categories

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

Product:
Core
Component:
SQLite and Embedded Database Bindings
Version:
1.9.0 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: marek78uk, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.0.3) Gecko/2008092416 Firefox/3.0.3 after an upgrade from 3.0.1 to 3.0.3 Firefox started to crash every couple of minutes (it is a third time I am trying to complete this bug report) Reproducible: Always Steps to Reproduce: 1. Start firefox 2. Try to do something or don't touch firefox 3. after 0-3 minutes firefox will crash Actual Results: firefox crashes Expected Results: keeps working [marek@Mareg home]$ firefox LoadPlugin: failed to initialize shared library /opt/Firefox3/plugins/libunixprintplugin.so [libxpcom_core.so: cannot open shared object file: No such file or directory] LoadPlugin: failed to initialize shared library /opt/Firefox3/plugins/libunixprintplugin.so [libxpcom_core.so: cannot open shared object file: No such file or directory] LoadPlugin: failed to initialize shared library /opt/Firefox3/plugins/libunixprintplugin.so [libxpcom_core.so: cannot open shared object file: No such file or directory] /opt/Firefox3/run-mozilla.sh: line 131: 7529 Segmentation fault "$prog" ${1+"$@"} [marek@Mareg home]$ winscard_clnt.c:3349:SCardCheckDaemonAvailability() PCSC Not Running LoadPlugin: failed to initialize shared library /opt/Firefox3/plugins/libunixprintplugin.so [libxpcom_core.so: cannot open shared object file: No such file or directory]
a quick and dirty solution: create a new profile and suddenly everything works fine, but all your passwords / websites / bookmarks are gone.
Need a stack to investigate: http://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report If you can reproduce this easily, see if an add-on is at fault: http://support.mozilla.com/en-US/kb/Troubleshooting+extensions+and+themes You could always just move over your passwords and places to the new profile and see if that works. Try the above first, though.
bp-97d30111-a0e5-11dd-900e-001321b13766 0 libc-2.7.so libc-2.7.so@0x713d7 1 libsqlite3.so libsqlite3.so@0xa788 2 libsqlite3.so libsqlite3.so@0x1d34c 3 libsqlite3.so libsqlite3.so@0x2fa40 4 libsqlite3.so libsqlite3.so@0x4fab5 5 libsqlite3.so libsqlite3.so@0x52686 6 libxul.so mozStorageStatement::ExecuteStep mozilla/storage/src/mozStorageStatement.cpp:472 7 libxul.so mozStorageStatement::Execute mozilla/storage/src/mozStorageStatement.cpp:448 8 libxul.so nsUrlClassifierStore::WriteEntry mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:1887 9 libxul.so nsUrlClassifierDBServiceWorker::AddChunk mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:2438 10 libxul.so nsUrlClassifierDBServiceWorker::ProcessChunk mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:2567 11 libxul.so nsUrlClassifierDBServiceWorker::UpdateStream mozilla/toolkit/components/url-classifier/src/nsUrlClassifierDBService.cpp:2944 12 libxul.so NS_GetXPTCallStub_P 13 libxul.so nsProxyObjectCallInfo::Run mozilla/xpcom/proxy/src/nsProxyEvent.cpp:181 14 libxul.so nsThread::ProcessNextEvent mozilla/xpcom/threads/nsThread.cpp:510 15 libxul.so NS_ProcessNextEvent_P nsThreadUtils.cpp:227 16 libxul.so nsThread::ThreadFunc mozilla/xpcom/threads/nsThread.cpp:254 17 libnspr4.so _pt_root mozilla/nsprpub/pr/src/pthreads/ptthread.c:221 18 libpthread-2.7.so libpthread-2.7.so@0x550a The other ones (that load right now, at least) all look about the same. It's dying on database access.
Summary: Firefox randomly crashes without any reason (not flash related) → Firefox randomly crashes without any reason (not flash related) [ mozStorageStatement::ExecuteStep ]
but, with a clear profile firefox seems to work fine... firefox hasn't crashed since I've created a new profile.
Severity: critical → normal
Version: unspecified → 3.0 Branch
Severity is for the bug, not your experience of it. Crash always means critical.
Severity: normal → critical
ok... sorry :-) thought if there is a solution (make a new profile) severity shouldn't be critical. thanks.
Here's what I want you to try: 1. Go to your broken profile folder: ~/.mozilla/firefox/whatever 2. Take a look at urlclassifier3.sqlite and urlclassifierkey3.txt a. Make sure they're there, first of all b. See how big they are 3. Rename them to *.old (i.e. delete and backup) 4. Load up that profile and see what happens.
Oh, and 2.c: check their permissions; make sure you're allowed to write there
hm... I think, I have deleted old profile :-/
:sigh: If you deleted the old profile then you deleted your old bookmarks, passwords, etc. Please make sure it's gone. (run: firefox -profilemanger) If it is... well, then that's the end here, as I have nothing left to go on. Hopefully you took anything you wanted to save out before deleting it, otherwise you shot yourself in the foot.
Component: General → Storage
Product: Firefox → Toolkit
QA Contact: general → storage
Version: 3.0 Branch → unspecified
Version: unspecified → 1.9.0 Branch
I've copied bookmarks, but didn't copy passwords. Also - for a long time I had a problem with flash crashing my browser - now it seems to be fixed to :-o don't know if it was related, but I can browse youtube now and firefox is not crashed by flash.
Well, glad things work now, even if we didn't get to the bottom of why. If you have problems in the future, please don't jump right to deletion. This is not a tech support forum; we're interested in finding out the cause so it can be fixed. In any case, closing as WORKSFORME.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
does the lack of symbols for sqlite mean that we're using a system library or that stabs is still lame?
Summary: Firefox randomly crashes without any reason (not flash related) [ mozStorageStatement::ExecuteStep ] → Firefox randomly crashes without any reason (not flash related) [@ mozStorageStatement::ExecuteStep ]
Knowing what version of sqlite you have would be helpful with this as well
(In reply to comment #14) > does the lack of symbols for sqlite mean that we're using a system library or > that stabs is still lame? yes it does, which is why I asked what version they have in comment 14.
[marek@Mareg ~]$ rpm -q sqlite sqlite-3.4.2-3.fc8 [marek@Mareg ~]$
Well that is lovely. What is your distro? We require a newer version than that for the 1.9.0.x branch...
(In reply to comment #18) > Well that is lovely. What is your distro? (In reply to comment #17) > sqlite-3.4.2-3.fc8 fc8 => Fedora 8, would be my guess
Fedora 8 - cannot update to Fedora 9 as iwl4965 does not want to connect with my router at work... so waiting for Fedora 10, which should be released around end of November. at home I use Fedora 9 with Firefox compiled by fedora, works fine.
You could check to see if there's a Fedora 8 backport package for sqlite that might be newer. I think FF3 wants sqlite 3.5.4+. (correct me if I'm wrong)
(In reply to comment #21) > You could check to see if there's a Fedora 8 backport package for sqlite that > might be newer. I think FF3 wants sqlite 3.5.4+. (correct me if I'm wrong) For 3.0 that was sufficient, but as of 3.0.1+, we want 3.5.9 or newer.
so I've upgraded from 3.0 to 3.0.3 and got a problem with sqlite, now I've got a fresh profile and everything seems to work fine. I don't know where to look for a backport packages for Fedora 8.
(In reply to comment #23) > a fresh profile and everything seems to work fine. Yeah, but if you continue to use an old version of sqlite you may trigger this again.
Should I downgrade back to Firefox 3.0 then? I can keep using Firefox 3.0.3 - if problem re-appears, it might be useful to track it down to the roots.
(In reply to comment #25) > Should I downgrade back to Firefox 3.0 then? Firefox 3 wants sqlite 3.5.x (different x depending on different updates) and you have 3.4.x. I don't think a downgrade would matter. Doesn't the official build include sqlite? Is there some way to make it just not use your libs? (I don't know enough about this)
(In reply to comment #26) > Doesn't the official build include sqlite? Is there some way to make it just > not use your libs? (I don't know enough about this) Yes - by default we do not use system sqlite. Some distros change this so that we do.
(In reply to comment #27) > (In reply to comment #26) > > Doesn't the official build include sqlite? Is there some way to make it just > > not use your libs? (I don't know enough about this) > Yes - by default we do not use system sqlite. Some distros change this so that > we do. Then how does one change this? (or is that question entirely distro-specific?)
Summary: Firefox randomly crashes without any reason (not flash related) [@ mozStorageStatement::ExecuteStep ] → Firefox crashes on DB writes (using old SQLite 3.4.x system library) [@ mozStorageStatement::ExecuteStep ]
(In reply to comment #28) > Then how does one change this? (or is that question entirely distro-specific?) It is a compile time option that distros can enable. I've filed bug 461344 for us to be more strict about having the right version so this does not happen in the future.
I am using Firefox downloaded from mozilla.org website - there is no Firefox 3 for Fedora 8 available in repos.
(In reply to comment #30) > I am using Firefox downloaded from mozilla.org website - there is no Firefox 3 > for Fedora 8 available in repos. Then it isn't using the system libs and the symbols are missing for some other reason? (all the stacks in comment 3 are accessible now and none have anything useful for libsqlite3)
Ted - can you respond to comment 14 please? comment 30 seems to indicate that it isn't a system sqlite library, so now I am confused.
That would be bug 415316. The stabs debugging format uses a short int for line numbers, so the 65k+ line sqlite3.c overflows that and we don't get debug info. (In fact, it uses a short signed int, so we overflowed at 32k, but I made Breakpad cheat and cast it to an unsigned int because it seemed to work anyway.)
how can I check which version of sqlite is being used?
Product: Toolkit → Core
You need to log in before you can comment on or make changes to this bug.