Created attachment 183999 [details] GDB trace of assertion crash 1. Open attachment 177322 [details] from bug 146584 with a debug build 2. Go to the tables tab and double-click Table2 include/comphelper/date.hxx:39: sal_Int32 comphelper::date::YearToDays(sal_Int16): Assertion `nYear != 0' failed. Last change to that line seems to be commit febf6795f68efcdc05a4bcb19a2b6636226b026d Author: Mike Kaganski <mike.kaganski@collabora.com> Date: Thu Nov 24 09:55:08 2022 +0300 Make some date functions inline constexpr Arch Linux 64-bit Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 400e44cebd993f4b9b3d878fb9264f99e005c9fb CPU threads: 8; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 5 December 2022
On pc Debian x86-64 with master sources updated today, I could reproduce this too. I also noticed this: 52ff16771ac160d27fd7beb78a4cfba22ad84f06 Resolves: tdf#152114 Use comphelper::date algorithms ... that can actually cope with negative (BCE) proleptic Gregorian calendar dates, which already for Julian calendar dates 0001-01-01 and 0001-01-02 they are. (2022-11-22) Eike: any thoughts here?
Sure, if code sets/uses a date with year 0 (or even day=0,month=0,year=0 in this case) for the proleptic Gregorian calendar then that code is wrong ;-) That so far didn't matter because the Base code had its own and wrong conversion. Problem here seems to be a NULL value of the database that is *not* a date to be converted to relative days, entering connectivity/source/commontools/dbconversion.cxx dbtools::DBTypeConversion::toDouble() with _rVal all 0 then via dbtools::DBTypeConversion::toDays() dbtools::implRelativeToAbsoluteNull() calls the now new comphelper::date::convertDateToDaysNormalizing() that via its calls asserts. The old dbtools::implRelativeToAbsoluteNull() implementation for day=0,month=0,year=0 returned -365 for that "date", which is completely off. Whatever the old now eliminated dbtools::implBuildFromRelative() did for such..
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/da3dd48eaf9086f8ab28d6a6655f9a638e51433a Resolves: tdf#152381 Treat 0-0-0 invalid date as 0 relative days It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With the last patch, there is no assertion, but both Table1 and Table2 open (with double-click), so there are no columns displayed and no row.
I see one empty row for each, Table1 and Table2, with columns: ID, Name, Stamp and "Record 1 of 1" in the status bar.
(In reply to Eike Rathke from comment #5) > I see one empty row for each, Table1 and Table2, with columns: > ID, Name, Stamp > and "Record 1 of 1" in the status bar. That's darn strange. It's full blankness for me both on Win and Linux Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 52c75986adc2b370eb55ce918ab1db0a95831c83 CPU threads: 2; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Jumbo Arch Linux 64-bit Version: 7.5.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 705b2924a14841883b4a8cac549f7af326d7a185 CPU threads: 8; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Jumbo Built on 8 December 2022
On pc Debian x86-64 with master sources updated today, I don't reproduce the assertion but I got the same as Buovjaga, no row at all (gtk3 or gen rendering) On console, I noticed these: warn:dbaccess:111457:111457:dbaccess/source/ui/browser/unodatbr.cxx:754: DBG_UNHANDLED_EXCEPTION in InitializeGridModel exception: com.sun.star.lang.IllegalArgumentException message: "lengths do not match at /home/julien/lo/libreoffice/cppuhelper/source/propshlp.cxx:872" ArgumentPosition: -1 #0 cppu::OPropertySetHelper::setPropertyValues(com::sun::star::uno::Sequence<rtl::OUString> const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (this=0x55eca23d3b90, rPropertyNames=uno::Sequence of length 6 = {...}, rValues=uno::Sequence of length 7 = {...}) at cppuhelper/source/propshlp.cxx:872 #1 0x00007f39c7a7ecb6 in comphelper::OPropertySetAggregationHelper::setPropertyValues(com::sun::star::uno::Sequence<rtl::OUString> const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (this=0x55eca23d3b90, _rPropertyNames=uno::Sequence of length 6 = {...}, _rValues=uno::Sequence of length 7 = {...}) at comphelper/source/property/propagg.cxx:589 #2 0x00007f39ac81f057 in dbaui::SbaTableQueryBrowser::InitializeGridModel(com::sun::star::uno::Reference<com::sun::star::form::XFormComponent> const&) (this=0x55eca23b1960, xGrid=uno::Reference to (frm::OGridControlModel *) 0x55eca23d3c30) at dbaccess/source/ui/browser/unodatbr.cxx:594 #3 0x00007f39ac834d46 in dbaui::SbaTableQueryBrowser::implLoadAnything(rtl::OUString const&, rtl::OUString const&, int, bool, utl::SharedUNOComponent<com::sun::star::sdbc::XConnection, utl::DisposableComponent> const&) (this=0x55eca23b1960, _rDataSourceName="file:///tmp/Table_Default_Firebird.odb", _rCommand="Table2", nCommandType=0, _bEscapeProcessing=true, _rxConnection=...) at dbaccess/source/ui/browser/unodatbr.cxx:2384 #4 0x00007f39ac8312ee in dbaui::SbaTableQueryBrowser::implSelect(weld::TreeIter const*) (this=0x55eca23b1960, pEntry=0x55eca243bd90) at dbaccess/source/ui/browser/unodatbr.cxx:2678 #5 0x00007f39ac8343e2 in dbaui::SbaTableQueryBrowser::implSelect(rtl::OUString const&, rtl::OUString const&, int, bool, utl::SharedUNOComponent<com::sun::star::sdbc::XConnection, utl::DisposableComponent> const&, bool) (this=0x55eca23b1960, _rDataSourceName="file:///tmp/Table_Default_Firebird.odb", _rCommand="Table2", nCommandType=0, _bEscapeProcessing=true, _rxConnection=..., _bSelectDirect=true) at dbaccess/source/ui/browser/unodatbr.cxx:2445 #6 0x00007f39ac8398c5 in dbaui::SbaTableQueryBrowser::impl_initialize() (this=0x55eca23b1960) at dbaccess/source/ui/browser/unodatbr.cxx:3251 #7 0x00007f39ac7a3eee in dbaui::OGenericUnoController::initialize(com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (this=0x55eca23b1960, aArguments=uno::Sequence of length 17 = {...}) at dbaccess/source/ui/browser/genericcontroller.cxx:259 #8 0x00007f39ac718dd7 in (anonymous namespace)::DBContentLoader::load(com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XLoadEventListener> const&) (this=0x55eca23aacf0, rFrame=uno::Reference to ((anonymous namespace)::XFrameImpl *) 0x55eca1f13750, rURL=".component:DB/DataSourceBrowser", rArgs=uno::Sequence of length 16 = {...}, rListener=uno::Reference to (framework::(anonymous namespace)::LoadEnvListener *) 0x55eca23b0828) at dbaccess/source/ui/browser/dbloader.cxx:230 #9 0x00007f39c65f5f13 in framework::LoadEnv::impl_loadContent() (this=0x7fff7788a6e8) at framework/source/loadenv/loadenv.cxx:1154 I'm gonna submit a patch related to this.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0390479ccf454cd87997fe97d640caf9f8c45a13 Related tdf#152381: fix "lengths do not match" It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/5c98abd873124b5cc883b3755f45b91fc238dc90 Related tdf#152381: fix "lengths do not match" It will be available in 7.5.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
According to https://wiki.documentfoundation.org/ReleasePlan/7.5, there won't be 7.5.0.0 beta 2.
I only checked this now, but I guess Julien's patch fixed the remaining weirdness. Thanks! Arch Linux 64-bit, X11 Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b844605b101bd752c8a0c07117b5d3faf2b2aebb CPU threads: 8; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Jumbo Built on 22 December 2022