Bug 90029 - Crash with form (frm::TimeFieldColumn)
Summary: Crash with form (frm::TimeFieldColumn)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: high major
Assignee: Stephan Bergmann
URL:
Whiteboard: target:4.5.0
Keywords: haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2015-03-15 19:55 UTC by Julien Nabet
Modified: 2015-03-16 11:25 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
bt + additional gdb (6.63 KB, text/plain)
2015-03-15 19:55 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2015-03-15 19:55:34 UTC
Created attachment 114116 [details]
bt + additional gdb

On pc Debian x86-64 with master sources updated 2 days ago, I've got a crash when opening 1st form of this attachment https://bugs.freedesktop.org/attachment.cgi?id=94532

I attached bt + interesting lines from gdb session.
DbTimeField::updateFromModel (this=0x3187c80, _rxModel=uno::Reference to (frm::TimeFieldColumn *) 0x3326d38)
    at /home/julien/compile-libreoffice/libreoffice/svx/source/fmcomp/gridcell.cxx:2386
2386	{
(gdb) n
2387	    OSL_ENSURE( _rxModel.is() && m_pWindow, "DbTimeField::updateFromModel: invalid call!" );
(gdb) n
2389	    util::Time aTime;
(gdb) n
2390	    if ( _rxModel->getPropertyValue( FM_PROP_DATE ) >>= aTime )
(gdb) n
Comment 1 Julien Nabet 2015-03-15 19:57:11 UTC
Stephan: I remember your patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=fa6c09877ed6502593de2f73541d91f31c8feea1 which fixed the regression 5d05f7ed8582193c39e29b7dc16767fb850e9f28
I wonder if it could be the same kind of regression.
Comment 2 raal 2015-03-15 20:55:13 UTC
I can confirm crash with Version: 4.5.0.0.alpha0+
Build ID: 7f3628e54d4470cac6d51659d1b1bec5fb4f4e70
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-03-14_00:35:32

I can open report but LO crashes when click Next record.
Comment 3 Julien Nabet 2015-03-15 21:30:40 UTC
Thank you Raal for the confirmation.

I don't reproduce this with LO Debian package 4.3.3.2->regression.
Comment 4 Stephan Bergmann 2015-03-16 11:05:51 UTC
The call to DbTimeField::updateFromModel from DbCellControl::Init (both in svx/source/fmcomp/gridcell.cxx) got introduced with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=42b809228dc0971c4280871728e37261abab62da> "On init of DbCellControl, load value from Model."

What is odd about DbTimeField::updateFromModel is that it uses FM_PROP_DATE (aka "Date") instead of FM_PROP_TIME (aka "Time") as DbTimeField::commitControl does, and that "Date" then causes the uncaught UnknownPropertyException.  Looks like this is a copy/paste error between DbDateField::updateFromModel and DbTimeField::updateFromModel ever since <http://cgit.freedesktop.org/libreoffice/core/commit/?id=fba11e39f9f5b7d418969d414093ea7f7e1000ca> "#98012# #98171# some major changes - no, the DbCellControl (and derivees) is (are) a listener at the relevant model properties like ReadOnly, Text, Value aso."
Comment 5 Commit Notification 2015-03-16 11:08:44 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=144b5e68106415d2e9a4a6a51e259d329a695d5f

tdf#90029: FM_PROP_DATE/TIME confusion

It will be available in 4.5.0.

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 6 Lionel Elie Mamane 2015-03-16 11:16:06 UTC
This rings a bell, I get the impression I recently fixed exactly the same confusion betweeen Time and Date property, certainly at another place in the code.
Comment 7 Lionel Elie Mamane 2015-03-16 11:23:59 UTC
(In reply to Lionel Elie Mamane from comment #6)
> This rings a bell, I get the impression I recently fixed exactly the same
> confusion betweeen Time and Date property, certainly at another place in the
> code.

It was exactly there, it is in my uncommitted changes... My bad.