Bug Hunting Session
Bug 37529 - crash - Browsing Tables in data source navigator from table with more columns to empty table with less columns
Summary: crash - Browsing Tables in data source navigator from table with more columns...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.4.0 RC1
Hardware: x86-64 (AMD64) Mac OS X (All)
: high critical
Assignee: Lionel Elie Mamane
URL:
Whiteboard: target:3.7.0 target:3.6.2 target:3.5.7
Keywords:
: 54457 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2011-05-24 00:00 UTC by Alex Thurgood
Modified: 2012-09-20 10:12 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
apple trace for crash in libreoffice using mysqljdbc connector and datasource navigator (61.53 KB, text/plain)
2011-05-24 00:00 UTC, Alex Thurgood
Details
newer stack trace with master build (66.12 KB, text/plain)
2011-10-28 01:48 UTC, Alex Thurgood
Details
apple crash trace from 3.5 beta 2 (67.54 KB, text/plain)
2012-01-09 07:43 UTC, Alex Thurgood
Details
apple crash trace on master with mysql jdbc connector (89.44 KB, text/plain)
2012-07-20 14:58 UTC, Alex Thurgood
Details
crash trace from master 21/08 with OSX 10.8 (83.76 KB, text/plain)
2012-08-21 14:14 UTC, Alex Thurgood
Details
Apple crash trace report (79.29 KB, text/plain)
2012-08-24 13:09 UTC, Alex Thurgood
Details
bt + console logs on master (6.65 KB, text/plain)
2012-08-24 17:25 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2011-05-24 00:00:08 UTC
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
Comment 1 Alex Thurgood 2011-05-24 00:25:07 UTC
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
Comment 2 Alex Thurgood 2011-05-24 00:25:49 UTC
Upping priority/severity.
Comment 3 Alex Thurgood 2011-05-24 00:46:51 UTC
Can reproduce also in OOo-dev 3.4.0m0.

Alex
Comment 4 Alex Thurgood 2011-05-24 00:55:52 UTC
Also occurs with OOo 3.2.1.

Alex
Comment 5 Yifan Jiang 2011-05-24 02:22:24 UTC
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.
Comment 6 Alex Thurgood 2011-05-24 02:28:31 UTC
Hi Yifan,

Thanks for confirming, I thought it might be just a Mac problem. Changing platform to all as a result.

Alex
Comment 7 Jan Holesovsky 2011-07-01 08:20:56 UTC
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!
Comment 8 Michael Meeks 2011-09-05 07:59:36 UTC
#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.
Comment 9 Alex Thurgood 2011-09-05 08:33:44 UTC
(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
Comment 10 Alex Thurgood 2011-09-05 08:34:34 UTC
Ah, I see that it has already been changed back,:-))

Alex
Comment 11 Alex Thurgood 2011-09-05 08:37:00 UTC
(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
Comment 12 Alex Thurgood 2011-10-28 01:48:32 UTC
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.
Comment 13 Björn Michaelsen 2011-12-23 12:02:52 UTC
[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
Comment 14 Rainer Bielefeld Retired 2011-12-24 00:22:45 UTC
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.
Comment 15 Alex Thurgood 2012-01-09 07:43:04 UTC
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.
Comment 16 Alex Thurgood 2012-02-26 11:19:35 UTC
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
Comment 17 Rainer Bielefeld Retired 2012-03-27 01:25:17 UTC
3.4 lifecycle is terminated, so shifted to “Bug 37361 - LibreOffice 3.5 most annoying bugs”
Comment 18 Alex Thurgood 2012-07-20 14:52:38 UTC
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
Comment 19 Alex Thurgood 2012-07-20 14:58:46 UTC
Created attachment 64452 [details]
apple crash trace on master with mysql jdbc connector
Comment 20 Alex Thurgood 2012-07-21 09:01:06 UTC
As per the enclosed stack trace yesterday, the parameter trick still does not prevent the crash.


Alex
Comment 21 Alex Thurgood 2012-08-21 14:14:40 UTC
Created attachment 65886 [details]
crash trace from master 21/08 with OSX 10.8
Comment 22 Julien Nabet 2012-08-23 21:28:15 UTC
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? :-(
Comment 23 Alex Thurgood 2012-08-24 12:50:22 UTC
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
Comment 24 Alex Thurgood 2012-08-24 13:08:49 UTC
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
Comment 25 Alex Thurgood 2012-08-24 13:09:43 UTC
Created attachment 66065 [details]
Apple crash trace report
Comment 26 Alex Thurgood 2012-08-24 13:15:12 UTC
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
Comment 27 Alex Thurgood 2012-08-24 13:27:51 UTC
FWIW, the same operation also causes AOO 341 to crash.


Alex
Comment 28 Julien Nabet 2012-08-24 17:25:10 UTC
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.
Comment 29 Julien Nabet 2012-08-24 17:31:12 UTC
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?
Comment 30 Alex Thurgood 2012-08-25 09:23:08 UTC
(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
Comment 31 Alex Thurgood 2012-08-25 09:25:25 UTC
(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
Comment 32 Not Assigned 2012-09-13 14:36:07 UTC
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.
Comment 33 Not Assigned 2012-09-13 14:47:43 UTC
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.
Comment 34 Lionel Elie Mamane 2012-09-13 14:50:07 UTC
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.
Comment 35 Lionel Elie Mamane 2012-09-13 14:56:21 UTC
Just to be clear: there seems to be nothing MySQL-specific, nor JDBC-specific in this.
Comment 36 Lionel Elie Mamane 2012-09-13 14:59:57 UTC
*** Bug 54457 has been marked as a duplicate of this bug. ***
Comment 37 Alex Thurgood 2012-09-13 15:18:04 UTC
Dude, that is so twisted ;-)

I hope you're right, coz if so, I'm gonna be one happy hunter :-)) yeah!

Alex
Comment 38 Julien Nabet 2012-09-13 20:08:31 UTC
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.
Comment 39 Lionel Elie Mamane 2012-09-15 20:25:52 UTC
*** Bug 54457 has been marked as a duplicate of this bug. ***
Comment 40 Not Assigned 2012-09-17 07:45:35 UTC
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.
Comment 41 Michael Meeks 2012-09-18 10:12:53 UTC
Marking fixed - thanks so much Lionel ! :-)
I wonder - did you want to propose this for 3.6.2 ?
Comment 42 Lionel Elie Mamane 2012-09-19 14:21:48 UTC
(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!
Comment 43 Not Assigned 2012-09-20 10:12:29 UTC
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.