Created attachment 47094 [details] apple trace for crash in libreoffice using mysqljdbc connector and datasource navigator How to reproduce : 1) Start LibreOffice, open new Writer document. 2) Activate data source navigator (press F4) or click on the database icon in Writer toolbar. 3) An upper window appears within the main application window. This is called the datasource navigator (or datasource browser, or something like that). 4) In the left hand pane is a tree view with the list of databases and tables known to the LibreOffice application (i.e. previously declared or connected). 5) Enter name/password if required. 6) Now use the arrow cursor keys to move down the table entries. If any of your tables has a timestamp field in it, an error will be thrown if you have NULL entries in any date or timestamp fields within the table because the JDBC driver doesn't know how to parse NULL date or timestamps. Click on OK to make the error message go away. No data or table structure will be displayed for that table. 7) Now attempt to move down the tree to the next table. No structure or data will be displayed for this table subsequent to the error message. 8) Move once again down the table list. LibreOffice crashes. Systematically. The problem exists in both 3.3.2 and 3.4rc1. Attaching Apple trace. Alex
Comparison to NeoOffice 3.2 patch2 : no crash under the same circumstances, even though the JDBC driver throws a NULL value error for empty date and timestamp fields. Alex
Upping priority/severity.
Can reproduce also in OOo-dev 3.4.0m0. Alex
Also occurs with OOo 3.2.1. Alex
I used a mysql local server to reproduce with 3.4 RC1 / SLED 11 sp1. (In reply to comment #0) > 6) Now use the arrow cursor keys to move down the table entries. If any of your > tables has a timestamp field in it, an error will be thrown if you have NULL > entries in any date or timestamp fields within the table because the JDBC > driver doesn't know how to parse NULL date or timestamps. Click on OK to make > the error message go away. No data or table structure will be displayed for > that table. > 7) Now attempt to move down the tree to the next table. No structure or data > will be displayed for this table subsequent to the error message. Yes, I can reproduce both of the problems above. > 8) Move once again down the table list. LibreOffice crashes. Systematically. > I can't see the crash after couple of arrow key navigating. It is more like a refresh problem to me from my observation.
Hi Yifan, Thanks for confirming, I thought it might be just a Mac problem. Changing platform to all as a result. Alex
Alex: > 4) In the left hand pane is a tree view with the list of databases and tables > known to the LibreOffice application (i.e. previously declared or connected). Can you please describe even the 'previously declared or connected' step? Thank you!
#c5 suggest that the other issues are reproducible on Linux, but not the crash. We must have one bug per bug - and this is the crash issue => this seems mac specific (if I read yifan right). Again - getting a full gdb trace of this crash for a build built with symbols would be extremely helpful in debugging this.
(In reply to comment #8) > #c5 suggest that the other issues are reproducible on Linux, but not the crash. > We must have one bug per bug - and this is the crash issue => this seems mac > specific (if I read yifan right). > Hi Michael, The null timestamp display issue is, AFAICR, NOTOURBUG, it is a problem with the JDBC driver provided by mysql and has been like this for donkey's years. I recently closed a separate bug report opened by someone who had raised this issue for that very reason. As for Yifan's comment, I have just realised that I misread "can't" for "can", hence my motivation for changing to all platforms. I will change this back to MacOSX specific only. > Again - getting a full gdb trace of this crash for a build built with symbols > would be extremely helpful in debugging this. On Mac, that is currently a problem for me... Alex
Ah, I see that it has already been changed back,:-)) Alex
(In reply to comment #7) > Alex: > > 4) In the left hand pane is a tree view with the list of databases and tables > > known to the LibreOffice application (i.e. previously declared or connected). > > Can you please describe even the 'previously declared or connected' step? > Thank you! Hi Jan, The left hand pane represents the databases and included tables that have either been bound to LO or to which a connection has already been made, as in when a new ODB file is created, or when an existing ODB file has been opened and a connection to the database made (be it a server or file). Is that clearer ? Alex
Created attachment 52842 [details] newer stack trace with master build I tried this again with a build from master 28/10/2011. The problem is still present. Attached is the stack trace.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I can't see any NEEDINFO reason. @Lionel: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Created attachment 55337 [details] apple crash trace from 3.5 beta 2 Enclosed is the crash trace report produced by the Apple Crash Reporter, tested with 3.5 beta 2.
This bug still occurs in 3.5 final. Systematically reproducible. 3 button down clicks through tables with null date values is enough to cause the crash. Alex
3.4 lifecycle is terminated, so shifted to “Bug 37361 - LibreOffice 3.5 most annoying bugs”
A possible workaround (haven't tested yet) : The mysql jdbc connector driver allows parameters to be concatenated at connection time, and apparently there is the following : ?zeroDateTimeBehavior=convertToNull which is supposed to obviate the problem with "0000-00-00" date/datetime strings (and which previous versions of mysql unfortunately allowed as valid default datetime strings, hence the problem today). The additional problem with this is that neither the connection wizard, nor the Advanced Properties dialog provides a user entry field for adding any additional driver parameters. Most users would naturally consider these parameters to be added to the driver identification string field, however, they would soon find out that the driver could then no longer be loaded... Only by guesswork and trial and error, might one come to the conclusion that the driver parameters need to be added to the "Database" identification field in the Advanced Properties dialog or the wizard connection setup dialog. Definitely room for improvement here, and could possibly be made the object of an easy hack (UI dialog modification, corresponding addition to driver string connection parameters in connection statement) ? Alex
Created attachment 64452 [details] apple crash trace on master with mysql jdbc connector
As per the enclosed stack trace yesterday, the parameter trick still does not prevent the crash. Alex
Created attachment 65886 [details] crash trace from master 21/08 with OSX 10.8
On pc Debian x86-64 testing (updated today) with master sources updated today, I tried to reproduce the problem. config : Mysql 5.5.24-7 libmysql-java: 5.1.16-2 First the db: CREATE TABLE IF NOT EXISTS `Tab1` ( `ID` int(11) NOT NULL AUTO_INCREMENT, `testTimestamp` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`ID`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ; INSERT INTO `Tab1` (`ID`, `testTimestamp`) VALUES (1, NULL); CREATE TABLE IF NOT EXISTS `Tab2` ( `id` int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; On LO Base: I created a test.odb by using Mysql Connection, then JDBC (click Test Connection OK) and registered db option checked. On LO Writer: followed your initial comment and didn't have neither crash nor error message. Did I miss anything? :-(
Hi Julien, Yes, you need at least 3 tables ;-) _However_, I've only managed to reproduce this systematically on Mac OSX :-/ As Yifan mentioned, he couldn't reproduce the crash on Linux SLED, and neither could anyone else, so it would seem to be a "Mac only" problem (yet again). Alex
Just tested on a clean OSX 10.8 Server. Reproducible. I recreated a new ODB file, using ConnectorJ 5.1.21. The ODB file connected from the OSX Server to another machine having an instance of mysql server on the local lan. Tested with LO 3.5.5 Crash trace is enclosed Alex
Created attachment 66065 [details] Apple crash trace report
First table : CREATE TABLE `action_type` ( `type` varchar(15) NOT NULL DEFAULT '', `comments` varchar(40) DEFAULT NULL, `action_type_id` tinyint(3) unsigned NOT NULL AUTO_INCREMENT, `chg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`action_type_id`) ) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=latin1 Second table : CREATE TABLE `address` ( `address_id` int(11) NOT NULL AUTO_INCREMENT, `LNAME` varchar(35) DEFAULT NULL, `FNAME` varchar(35) DEFAULT NULL, `TITLE` varchar(35) DEFAULT NULL, `COMPANY` varchar(35) DEFAULT NULL, `COADDR1` varchar(50) NOT NULL DEFAULT '', `COADDR2` varchar(50) DEFAULT NULL, `COADDR3` varchar(50) DEFAULT NULL, `COCITY` varchar(35) NOT NULL DEFAULT '', `COSTATE` varchar(35) DEFAULT NULL, `COZIP` varchar(12) DEFAULT NULL, `COCOUNTRY` varchar(35) NOT NULL DEFAULT '', `SALUT` varchar(20) DEFAULT NULL, `CUSTOM3` varchar(35) DEFAULT NULL, `TEL1` varchar(40) DEFAULT NULL, `FAX1` varchar(40) DEFAULT NULL, `FAX2` varchar(40) DEFAULT NULL, `MOBILE` varchar(40) DEFAULT NULL, `EMAIL` varchar(75) DEFAULT NULL, `WEBSITE` varchar(75) DEFAULT NULL, `NOTES` mediumtext, `chg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`address_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 Third table : CREATE TABLE `applicant` ( `applicant_id` int(11) unsigned NOT NULL AUTO_INCREMENT, `applicant_short` char(3) NOT NULL DEFAULT '', `applicant_long` varchar(30) NOT NULL DEFAULT '', `address_id` int(11) unsigned DEFAULT NULL, `chg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`applicant_id`) ) ENGINE=MyISAM AUTO_INCREMENT=972 DEFAULT CHARSET=latin1 Fourth table : CREATE TABLE `assistant` ( `assistant_id` tinyint(3) unsigned NOT NULL AUTO_INCREMENT, `assistant` varchar(7) NOT NULL DEFAULT '', `chg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`assistant_id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1
FWIW, the same operation also causes AOO 341 to crash. Alex
Created attachment 66076 [details] bt + console logs on master I had made a third table, just forgot to attach the script. The most important is, I reproduced the pb with your tables! I attached the bt + console logs.
Following the previous comment, the pb is line 1246, dbaccess/source/core/api/RowSet.cxx: 1240 void ORowSet::impl_restoreDataColumnsWriteable_throw() 1241 { 1242 TDataColumns::iterator aIter = m_aDataColumns.begin(); 1243 ::std::vector<bool, std::allocator<bool> >::iterator aReadIter = m_aReadOnlyDataColumns.begin(); 1244 for(;aReadIter != m_aReadOnlyDataColumns.end();++aIter,++aReadIter) 1245 { 1246 (*aIter)->setPropertyValue(PROPERTY_ISREADONLY,makeAny((sal_Bool)*aReadIter )); 1247 } 1248 m_aReadOnlyDataColumns.clear(); 1249 } Just before the function above, there's this one: 1224 void ORowSet::impl_setDataColumnsWriteable_throw() 1225 { 1226 impl_restoreDataColumnsWriteable_throw(); 1227 TDataColumns::iterator aIter = m_aDataColumns.begin(); 1228 m_aReadOnlyDataColumns.resize(m_aDataColumns.size(),false); 1229 ::std::vector<bool, std::allocator<bool> >::iterator aReadIter = m_aReadOnlyDataColumns.begin(); 1230 for(;aIter != m_aDataColumns.end();++aIter,++aReadIter) 1231 { 1232 sal_Bool bReadOnly = sal_False; 1233 (*aIter)->getPropertyValue(PROPERTY_ISREADONLY) >>= bReadOnly; 1234 *aReadIter = bReadOnly; 1235 1236 (*aIter)->setPropertyValue(PROPERTY_ISREADONLY,makeAny(sal_False)); 1237 } 1238 } I noticed line 1228: m_aReadOnlyDataColumns.resize(m_aDataColumns.size(),false); I put the same on the buggy function and it worked. patch: diff --git a/dbaccess/source/core/api/RowSet.cxx b/dbaccess/source/core/api/RowSet.cxx index 7b21b40..c4af5f4 100644 --- a/dbaccess/source/core/api/RowSet.cxx +++ b/dbaccess/source/core/api/RowSet.cxx @@ -1240,6 +1240,7 @@ void ORowSet::impl_setDataColumnsWriteable_throw() void ORowSet::impl_restoreDataColumnsWriteable_throw() { TDataColumns::iterator aIter = m_aDataColumns.begin(); + m_aReadOnlyDataColumns.resize(m_aDataColumns.size(),false); ::std::vector<bool, std::allocator<bool> >::iterator aReadIter = m_aReadOnlyDataColumns.begin(); for(;aReadIter != m_aReadOnlyDataColumns.end();++aIter,++aReadIter) { Now I'm not sure at all if the fix is buggy or not but it prevents the crash. lionel: any idea?
(In reply to comment #29) Hi Julien, > I put the same on the buggy function and it worked. > patch: > diff --git a/dbaccess/source/core/api/RowSet.cxx > b/dbaccess/source/core/api/RowSet.cxx > index 7b21b40..c4af5f4 100644 > --- a/dbaccess/source/core/api/RowSet.cxx > +++ b/dbaccess/source/core/api/RowSet.cxx > @@ -1240,6 +1240,7 @@ void ORowSet::impl_setDataColumnsWriteable_throw() > void ORowSet::impl_restoreDataColumnsWriteable_throw() > { > TDataColumns::iterator aIter = m_aDataColumns.begin(); > + m_aReadOnlyDataColumns.resize(m_aDataColumns.size(),false); > ::std::vector<bool, std::allocator<bool> >::iterator aReadIter = > m_aReadOnlyDataColumns.begin(); > for(;aReadIter != m_aReadOnlyDataColumns.end();++aIter,++aReadIter) > { > > Now I'm not sure at all if the fix is buggy or not but it prevents the crash. If this patch _IS_ the (correct) solution, then I'm eternally grateful, this bug has been plaguing me for ages now :-)) Alex
(In reply to comment #28) > > The most important is, I reproduced the pb with your tables! > I attached the bt + console logs. So, what is so "special" about my table definitions that causes LO to die ? There are no constraints, no dependencies on other tables, the only possible thing I can see is the AUTOINCREMENT start value in two of the tables, the rest of the definitions seem "bog-standard" to me ? Alex
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=522b4c65dcc90719288b4f7aa7eb565c15b64e86 fdo#37529 clear DataColumns read-only information when we clear DataColumns The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=77e0a04561f271d87a14d6a8b6bfe20c93ef7e5d&g=libreoffice-3-6 fdo#37529 clear DataColumns read-only information when we clear DataColumns It will be available in LibreOffice 3.6.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The crash I reproduced (and fixed) (which seems to be same as the crash reproduced by Julien) happens because when clearing m_aDataColumns for a changed command (query), m_aReadOnlyDataColumns was not cleared to. From there, the next call to gotoInsertRow (through impl_setDataColumnsWriteable_throw, then impl_restoreDataColumnsWriteable_throw) tried to restore read-only information of the *old* columns (columns of the previous query) to the *new* columns, which is obviously utterly pointless. This happened not to crash (but to do inane things wrt to the read-only bit) in cases where there were fewer new columns than old columns. In other words, it only crashed if the new selected table in the browser has less columns than the one that was selected before. It also happened not to crash if the table had some data, because then gotoInsertRow is not called. (It is called if we are allowed to insert rows AND the table has no row, because then insertion is the only thing one can possibly do with the table). So it is still possible that Alex is actually experiencing *another* crash than the one Julien and I reproduced and I fixed. I'm hoping that not :) Alex, if a version claiming to have this bug fixed still crashes for you, please clone this bug. Thanks.
Just to be clear: there seems to be nothing MySQL-specific, nor JDBC-specific in this.
*** Bug 54457 has been marked as a duplicate of this bug. ***
Dude, that is so twisted ;-) I hope you're right, coz if so, I'm gonna be one happy hunter :-)) yeah! Alex
I don't reproduce this bug with master sources updated today (so it includes Lionel's fix). Alex: you should give it a try when your build will be ok or wait for a daily build.
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4c700dfc0b3909b11a0711c2d64c779fab19070b&g=libreoffice-3-5 fdo#37529 clear DataColumns read-only information when we clear DataColumns It will be available in LibreOffice 3.5.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Marking fixed - thanks so much Lionel ! :-) I wonder - did you want to propose this for 3.6.2 ?
(In reply to comment #41) > Marking fixed - thanks so much Lionel ! :-) > I wonder - did you want to propose this for 3.6.2 ? Yes, I did: http://lists.freedesktop.org/archives/libreoffice/2012-September/038317.html If you add your review to http://lists.freedesktop.org/archives/libreoffice/2012-September/038322.html, it will be good to go!
Lionel Elie Mamane committed a patch related to this issue. It has been pushed to "libreoffice-3-6-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2fca05d5e4dee32feb6f9c9ba5f2c3792b72d5d1&g=libreoffice-3-6-2 fdo#37529 clear DataColumns read-only information when we clear DataColumns It will be available already in LibreOffice 3.6.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.