Summary: | database connection is lost after a while | ||
---|---|---|---|
Product: | [Applications] KEXI | Reporter: | Mathieu Jobin <opensource> |
Component: | General | Assignee: | Jarosław Staniek <staniek> |
Status: | CLOSED LATER | ||
Severity: | crash | ||
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Mathieu Jobin
2005-03-19 20:49:42 UTC
full error message (same error number as my small mysql isolated testcase) Creating table failed. Error while executing SQL statement. Message from server: No Database Selected SQL statement: CREATE TABLE table1 (id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, efefe VARCHAR(200)) Server result number: 1046 another backtrace.... I reopen my mysql connection (new kexi instance) and wait until it times out. then create a new table and try save to save it. same error. exit kexi, ask for saving changes (the table) :) Sure I said. can't save, same errror message, kexi crashed out. Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 24401)] [KCrash handler] #5 0x4001a481 in QString::length() const (this=0x0) at qstring.h:880 #6 0x403a3992 in KexiDB::Connection::isDatabaseUsed() (this=0x0) at connection.cpp:183 #7 0x403b7a94 in KexiDB::Connection::beginTransaction() (this=0x0) at connection.cpp:1564 #8 0x403dda07 in TransactionGuard (this=0xbfffe780, conn=@0x0) at transaction.cpp:133 #9 0x4022ccf2 in KexiProject::removeObject(KexiMainWindow*, KexiPart::Item&) ( this=0x82280c0, wnd=0x0, item=@0x815aa40) at kexiproject.cpp:427 #10 0x40063f93 in KexiMainWindowImpl::removeObject(KexiPart::Item*, bool) ( this=0x81592e8, item=0x815aa40, dontAsk=32) at keximainwindowimpl.cpp:2778 #11 0x400622a0 in KexiMainWindowImpl::closeDialog(KexiDialogBase*, bool) ( this=0x81592e8, dlg=0x82cc538, layoutTaskBar=true) at keximainwindowimpl.cpp:2313 #12 0x40061f0f in KexiMainWindowImpl::closeDialog(KexiDialogBase*) (this=0x0, dlg=0x0) at keximainwindowimpl.cpp:2268 #13 0x4005d163 in KexiMainWindowImpl::closeProject() (this=0x81592e8) at keximainwindowimpl.cpp:967 #14 0x40058742 in ~KexiMainWindowImpl (this=0x81592e8) at keximainwindowimpl.cpp:424 #15 0x4125e9d6 in QObject::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at kernel/qobject.cpp:750 #16 0x412a466f in QWidget::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at kernel/qwidget.cpp:4655 #17 0x41386222 in QMainWindow::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at widgets/qmainwindow.cpp:1686 #18 0x402a7f39 in KMdiMainFrm::event(QEvent*) (this=0x81592e8, e=0x82ffb20) at kmdimainfrm.cpp:1166 #19 0x411f15a9 in QApplication::internalNotify(QObject*, QEvent*) ( this=0xbfffefb0, receiver=0x81592e8, e=0x82ffb20) at kernel/qapplication.cpp:2635 #20 0x411f121b in QApplication::notify(QObject*, QEvent*) (this=0xbfffefb0, receiver=0x81592e8, e=0x82ffb20) at kernel/qapplication.cpp:2523 #21 0x40cf734d in KApplication::notify(QObject*, QEvent*) (this=0xbfffefb0, receiver=0x81592e8, event=0x82ffb20) at kapplication.cpp:549 #22 0x401ae9ed in QApplication::sendEvent(QObject*, QEvent*) (receiver=0x0, event=0x5c) at qapplication.h:491 #23 0x411f25f2 in QApplication::sendPostedEvents(QObject*, int) (receiver=0x0, event_type=52) at kernel/qapplication.cpp:3261 #24 0x41208a40 in QEventLoop::enterLoop() (this=0x810d270) at kernel/qeventloop.cpp:213 #25 0x41208892 in QEventLoop::exec() (this=0x810d270) at kernel/qeventloop.cpp:145 #26 0x411f174b in QApplication::exec() (this=0xbfffefb0) at kernel/qapplication.cpp:2758 #27 0x4001a15a in kdemain (argc=8, argv=0xbffff104) at main.cpp:199 #28 0x0804888f in main (argc=0, argv=0x0) at kexi.la.cpp:2 In your backtrace: #12 0x40061f0f in KexiMainWindowImpl::closeDialog(KexiDialogBase*) (this=0x0, dlg=0x0) at keximainwindowimpl.cpp:2268 This=0x0 is weird here. Could not reproduce... Regarding to your "kexi should check if the connection is still well establish and well working" wish: that's right and requires nontrivial architecture changes, so I wouldn't do this for 1.0, while stabilization process started. |