Bug 84315 - Numeric values are "not" shown and displayed as "0" when using --enable-mergedlibs
Summary: Numeric values are "not" shown and displayed as "0" when using --enable-merge...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.2.2 release
Hardware: Other Linux (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
: 84332 86036 (view as bug list)
Depends on: 88710
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-25 08:31 UTC by Rico Tzschichholz
Modified: 2015-12-17 10:58 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Example hsqldb database (3.32 KB, application/vnd.oasis.opendocument.database)
2014-09-25 08:31 UTC, Rico Tzschichholz
Details
Displayed with 4.2.6.3 (29.41 KB, image/png)
2014-09-25 08:31 UTC, Rico Tzschichholz
Details
Displayed with 4.3.2.2 (28.92 KB, image/png)
2014-09-25 08:32 UTC, Rico Tzschichholz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rico Tzschichholz 2014-09-25 08:31:29 UTC
Created attachment 106836 [details]
Example hsqldb database

Numeric are not correctly display and either an empty field or "0" is shown.
Comment 1 Rico Tzschichholz 2014-09-25 08:31:54 UTC
Created attachment 106837 [details]
Displayed with 4.2.6.3
Comment 2 Rico Tzschichholz 2014-09-25 08:32:13 UTC
Created attachment 106838 [details]
Displayed with 4.3.2.2
Comment 3 Rico Tzschichholz 2014-09-25 08:34:00 UTC
As reported to me this was working as expected in 4.3.1.2 as well.
Comment 4 Björn Michaelsen 2014-09-25 09:16:46 UTC
UNCONFIRMED->NEW: was confirmed by an independent party.
Comment 5 Björn Michaelsen 2014-09-25 09:22:11 UTC
Severity Critical unless this is a 4.3.0->4.3.2 regression.
Comment 6 tim 2014-09-25 11:23:20 UTC
I reported this to Rico this morning, assuming it was a new ubuntu release problem.  I was previously running 4.3.1.2 from the ubuntu ppa.


I was also running 4.3.2 development version direct from libreoffice to test another issue, version:  

Version: 4.3.2.0.0+ Build ID:
b2d54aa61607e477cb4b81f1a70e555ee3adb0af
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time:
2014-08-20_23:12:37

This was OK, which is why I assumed it was an ubuntu release problem.



I am a little concerned.  If this applies on all platforms, then no databases at all will work with 4.3.2.2, with all that implies.
Comment 7 tim 2014-09-25 12:09:57 UTC
I have done a little more investigation.

First, on the libreoffice website 4.3.2.2 still seems to be a pre-release, so I am a little surprised it was release to the ubuntu normal release ppa.

Secondly, on Windows 64 bit I downloaded 4.3.2.2 from the LO website and it is OK.

Thirdly, I thought I should download the linux deb 4.3.2.2 from the libreoffice website.  I did, and it works.

So after a very brief series of tests this appears to be an ubuntu release problem, not a libreoffice problem.  Please forgive me if I've made an error in my checking somewhere, but this issue seemed so serious for database users that I thought I should progress it as fast as possible.
Comment 8 Björn Michaelsen 2014-09-25 13:04:21 UTC
(In reply to comment #7)
> First, on the libreoffice website 4.3.2.2 still seems to be a pre-release,
> so I am a little surprised it was release to the ubuntu normal release ppa.

"This PPA might contain the release candidate that is assumed to become the final release even before it is declared so by the Document Foundation (e.g. usually release candidate 2 for minor updates)."
https://launchpad.net/~libreoffice/+archive/ubuntu/ppa

So nothing surprising there at all, if you read the PPA description.

> Secondly, on Windows 64 bit I downloaded 4.3.2.2 from the LO website and it
> is OK.
> 
> Thirdly, I thought I should download the linux deb 4.3.2.2 from the
> libreoffice website.  I did, and it works.

This is certainly interesting. Normally I would close the bug as NOTOURBUG here then (because it would be a distro bug only). I have an idea about the reason though, as I enabled mergedlibs on 4.3.2 and had to move some lib into it to get rid of circular deps: dbtools -- which sounds like it could cause this trouble.
 
Adding distro bug reference.
Comment 9 tim 2014-09-25 13:13:55 UTC
Björn,

So much to read, so little time :-)   Apologies - I should have re-read all of the PPA description.  My mistake.

Tim
Comment 10 Matúš Kukan 2014-09-25 20:47:01 UTC
Ah, in 8165fc23014c8044c131cb6e1fd0c5e06fd0da2d I've added dbtools to libmerged just to fix circular dependency without checking it's OK.

git grep '"dbtools"' finds
svx/source/form/dbtoolsclient.cxx
sw/source/uibase/dbui/swdbtoolsclient.cxx
there might be more but hopefully this is all.

One option is fix similar to 'git grep CUI_DLL_NAME vcl/'

But in this case, since svxcore already links against dbtools, we either want to link also sw properly and fix those files.

Or, get dbtools out of libmerged and create some hack for whatever was the reason to link against dbtools in 86bdb13704d9d85a247339071a86d301ce86cd7f "fdo#67615 TextField in table should use same formatting as floating TextField"

I don't know what's in dbtools library. I would think it's not core functionality to be really needed and used in libmerged (svxcore) but maybe it is? It's also not the smallest one, 2.2MB

This also could be an easy hack.
Comment 11 Robinson Tryon (qubit) 2014-09-25 21:30:14 UTC
NO REPRO with (TDF-built) LO 4.3.2.2 + Ubuntu 14.04

(In reply to comment #0)
> Example hsqldb database
> 
> Numeric are not correctly display and either an empty field or "0" is shown.

Repro Steps:

1) Open test.odb
2) Database -> Tables -> (double click on) test-table
3) See that the numeric values are empty/0 as described by OP

Here's what I see:

id  name  count
0   foo   42
1   bar   4711

(In reply to comment #8)
> This is certainly interesting. Normally I would close the bug as NOTOURBUG
> here then (because it would be a distro bug only).

Agreed.

> I have an idea about the
> reason though, as I enabled mergedlibs on 4.3.2 and had to move some lib
> into it to get rid of circular deps: dbtools -- which sounds like it could
> cause this trouble.
>  
> Adding distro bug reference.

Okay, leaving this one for you, Bjoern. Feel free to assign it to yourself, given that it's not something we can repro with current TDF builds.
Comment 12 Robinson Tryon (qubit) 2014-09-26 00:50:28 UTC
*** Bug 84332 has been marked as a duplicate of this bug. ***
Comment 13 Lionel Elie Mamane 2014-09-26 11:53:57 UTC
(In reply to comment #10)
> Ah, in 8165fc23014c8044c131cb6e1fd0c5e06fd0da2d I've added dbtools to
> libmerged just to fix circular dependency without checking it's OK.

> Or, get dbtools out of libmerged and create some hack for whatever was the
> reason to link against dbtools in 86bdb13704d9d85a247339071a86d301ce86cd7f
> "fdo#67615 TextField in table should use same formatting as floating
> TextField"

The reason what that LibreOffice contains two implementations of the same "feature", namely in a database context to format a value. I ripped out the use of one (svxform::OTypeConversionClient, which was buggy in the way described in bug 67615) in the favour of the other (dbtools::FormattedColumnValue).

> I don't know what's in dbtools library.

Utilities and base classes that are useful in a database context.

> I would think it's not core functionality

What is "core functionality" and what is not "core functionality" in LibreOffice? Do we have a clear policy about that?

> to be really needed and used in libmerged (svxcore) but maybe
> it is?

Well, parts of svxcore *do* deal with database stuff, so *if* svxcore is to be considered as completely "core functionality", then dealing with database stuff is "core functionality". If this contradicts in some way the yet-unknown-to-me policy about "core functionality", and *parts* of svxcore need to be considered "core feature" then maybe we can/should rip out the non-core parts of svxcore out of svxcore and place them into another library?

More hackishly, there is some infrastructure in place (namely connectivity::ODataAccessStaticTools) to handle this kind of things as a "dlopen at runtime instead of build-time link". We could extend that, but I'd much rather we solved the root cause rather than extending a band-aid (which I'd rather see destroyed).
Comment 14 Lionel Elie Mamane 2014-09-26 11:55:27 UTC
My meaning was "if svxcore deals with database stuff, it is normal it uses a database stuff utility functions library".

Another approach would be to tailor what's in dbtools. Maybe we can move stuff from it to another library if it helps?
Comment 15 Björn Michaelsen 2014-09-26 14:05:15 UTC
Just confirming quickly: I reproduce this bug with --enable-mergedlibs and it goes away without mergedlibs. Reducing severity to normal as --enable-mergedlibs is currently not used for upstream builds.
Comment 16 tim 2014-09-26 15:14:52 UTC
I see the severity has been reduced.  

Now I don't understand these things, so forgive me for asking.  However, why is this less severe now, since the current ubuntu ppa release for BASE users is still unusable?
Comment 17 Björn Michaelsen 2014-09-26 15:41:33 UTC
(In reply to comment #16)
> I see the severity has been reduced.  
> 
> Now I don't understand these things, so forgive me for asking.  However, why
> is this less severe now, since the current ubuntu ppa release for BASE users
> is still unusable?

This bug tracker tracks the severity of bug for the upstream LibreOffice project. Ubuntu-only packaging bugs are tracked on Launchpad. Note that even there a ppa-only issue isnt as critical as one in the main distro repository. Running the latest and greatest always has its tradeoff.

Also: Please direct further general bugtracking questions to the QA-list at http://nabble.documentfoundation.org/QA-f3613148.html or http://www.libreoffice.org/community/qa/. Please keep the bug tracker only for comments directly relevant to the specific issue at hand. Thanks.
Comment 18 tim 2014-09-26 15:55:36 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > I see the severity has been reduced.  
> > 
> > Now I don't understand these things, so forgive me for asking.  However, why
> > is this less severe now, since the current ubuntu ppa release for BASE users
> > is still unusable?
> 
> This bug tracker tracks the severity of bug for the upstream LibreOffice
> project. Ubuntu-only packaging bugs are tracked on Launchpad. Note that even
> there a ppa-only issue isnt as critical as one in the main distro
> repository. Running the latest and greatest always has its tradeoff.
> 
> Also: Please direct further general bugtracking questions to the QA-list at
> http://nabble.documentfoundation.org/QA-f3613148.html or
> http://www.libreoffice.org/community/qa/. Please keep the bug tracker only
> for comments directly relevant to the specific issue at hand. Thanks.
OK, thanks.  I'll await information on launchpad #1373928.
Comment 19 Matúš Kukan 2014-09-26 18:31:42 UTC
(In reply to comment #14)
> Another approach would be to tailor what's in dbtools. Maybe we can move
> stuff from it to another library if it helps?

Ah, no, it's fine.
Sorry, I should not ask that much.
I am not really against dbtools in libmerged, it surely has its reasons.
Main reason I've added you to cc was, just so that you know about this bug - which probably was not necessary :-)

Thanks for explanations!
Comment 20 tim 2014-09-27 08:11:41 UTC
I have downloaded and tested the most recent ubuntu build - 1:4.3.2~rc2-0ubuntu1~trusty2 - and the problem is fixed.

Thanks to all.

I have not changed the status of this report since I'm not sure if a final decision has been made on the correct set of libraries to be used.

I have also updated the launchpad report #1373928.
Comment 21 Michael Meeks 2014-09-30 15:51:23 UTC
Worth checking for symbol conflicts between dbaccess and mergedlibs I guess; I did a quick:

objdump -T instdir/program/libdbtoolslo.so   | c++filt | grep -v '\*UND\*' | grep -v '    connectivity::' | grep -v '    dbtools::' | grep -v 'non-virtual thunk to connectivity::' | grep -v 'non-virtual thunk to dbtools::' | grep -v '  vtable ' | grep -v '   typeinfo ' | less

And I spotted:

createDataAccessToolsFactory

which looks unusual to me.

I suggest someone with a bit of a clue - go on Bjoern you know you want to does:

git grep -10 createDataAccessToolsFactory

and applies the obvious fixup =)
Comment 22 Lionel Elie Mamane 2014-09-30 16:34:27 UTC
(In reply to comment #21)
> Worth checking for symbol conflicts between dbaccess and mergedlibs I guess;

> And I spotted:
 
> createDataAccessToolsFactory
 
> which looks unusual to me.

OTOH, it seems to be defined only there, and only used / declared in other places.

My guess is more in the direction that now dbtools is both linked *and* dlopen()ed from libsvxcore (and thus mergedlibs), and when dbtools is in mergedlibs, the svxcore code does not find libdbtoolslo.so/dylib/dll to dlopen(). So we should change the dlopen() mechanism in the mergedlibs case to not try to do dlopen() and just assume the symbols are there? Something like that.

Is there an "#ifdef" we can do to detect mergedlibs case?
Comment 23 Matúš Kukan 2014-10-01 09:15:12 UTC
Sorry, I was probably not clear enough in my first comment. :-/

(In reply to comment #22)
> So we should change the dlopen() mechanism in the mergedlibs case

Ideally we would just kill this dlopen.

> Is there an "#ifdef" we can do to detect mergedlibs case?

I guess it was removed because it's not necessary..
git grep CUI_DLL_NAME vcl/ shows

-DCUI_DLL_NAME=\"$(call gb_Library_get_runtime_filename,$(call gb_Library__get_name,cui))\" \

in makefile, and you can then use in source CUI_DLL_NAME instead of just "cui" without any #ifdefs
It expands to the exact platform specific name, so no need for SVLIBRARY then.

But really, we should kill that ugly createDataAccessToolsFactory mess and benefit. :-)
Comment 24 Lionel Elie Mamane 2014-10-01 09:45:03 UTC
(In reply to comment #23)
> Sorry, I was probably not clear enough in my first comment. :-/
> 
> (In reply to comment #22)
> > So we should change the dlopen() mechanism in the mergedlibs case
> 
> Ideally we would just kill this dlopen.

That's a good plan for master, and WiP is at https://gerrit.libreoffice.org/11737

*But* I wouldn't do that in the stable branch... Additionally to timing issues (that is, when will the full "kill the dlopen()" be done?), it is a rather bigger change, and instead of making many changes everywhere, I'd rather the dlopen mechanism (that is, the whole svx/dbtoolsclient) just didn't do the dlopen(); that's *one* change in *one* place, "neutering" the mechanism instead of killing it (that is, essentally making it a no-op instead of changing every place that calls it to not call it).

>> Is there an "#ifdef" we can do to detect mergedlibs case?

> git grep CUI_DLL_NAME vcl/ shows

> -DCUI_DLL_NAME=\"$(call gb_Library_get_runtime_filename,$(call
> gb_Library__get_name,cui))\" \

> in makefile, and you can then use in source CUI_DLL_NAME instead of just
> "cui" without any #ifdefs
> It expands to the exact platform specific name, so no need for SVLIBRARY
> then.

You mean "$(call gb_Library__get_name,cui)" will expand to "mergedlib" (or something like that) in the --enable-mergedlib case?
Comment 25 Matúš Kukan 2014-10-01 09:48:12 UTC
(In reply to comment #24)
> You mean "$(call gb_Library__get_name,cui)" will expand to "mergedlib" (or
> something like that) in the --enable-mergedlib case?

Sure, (e.g. to libmergedlo.so) and to libcuilo.so in --disable-mergelibs case.
Comment 26 Stefan Gruber 2014-10-18 21:20:55 UTC
I encountered this bug on my opensuse 13.1 system with LO 4.3.2.2 from factory-repo/OBS.
Therefore it is not only ubuntu and might be an upstream issue.

BTW if I create a simple form within the example database, it will not show any data at all.

On an another similar machine the table view of a mysql database showed all text values wrong as "0" (the other way round!) when the form displayed only text fields correctly...

LO 4.3.1.2 as it comes with opensuse 13.2 RC1 works properly here.
Comment 27 Dan Lewis 2014-10-18 22:59:04 UTC
   Yesterday, I downloaded LibreOffice from the PPA to test this problem on a 32 bit laptop using Ubuntu 14.04. (Mine was associated with the possibility of the mysql native connector might be the cause of this problem when using MySQL with LibreOffice. (Stefan Gruber and I have been on the LibreOffice user mailing list about it.)
   Today he gave me a link to this bug. So this evening, I have down the example database and opened it using LibreOffice from the PPA. I saw the following results:

0   foo   42
1   bar   4711

LibreOffice information: 
Version: 4.3.2.2
Build ID: 430m0(Build: 2)

     Have they fixed the problem with a newer version of the download file?
Comment 28 tim 2014-10-19 10:41:47 UTC
(In reply to Dan Lewis from comment #27)
>    Yesterday, I downloaded LibreOffice from the PPA to test this problem on
> a 32 bit laptop using Ubuntu 14.04. (Mine was associated with the
> possibility of the mysql native connector might be the cause of this problem
> when using MySQL with LibreOffice. (Stefan Gruber and I have been on the
> LibreOffice user mailing list about it.)
>    Today he gave me a link to this bug. So this evening, I have down the
> example database and opened it using LibreOffice from the PPA. I saw the
> following results:
> 
> 0   foo   42
> 1   bar   4711
> 
> LibreOffice information: 
> Version: 4.3.2.2
> Build ID: 430m0(Build: 2)
> 
>      Have they fixed the problem with a newer version of the download file?
That display looks correct to me.
Comment 29 Björn Michaelsen 2014-10-23 14:47:16 UTC
(In reply to Dan Lewis from comment #27)
>      Have they fixed the problem with a newer version of the download file?


https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1373928/comments/23

This bug shall remain open though until this works again with --mergedlibs
Comment 30 Julien Nabet 2014-11-09 09:56:39 UTC
*** Bug 86036 has been marked as a duplicate of this bug. ***
Comment 31 Julien Nabet 2014-11-09 10:01:07 UTC
I increase the importance of this since even if it's not a crash:
- it's a regression
- it's not a corner case
- there's no clear error or warning messages on UI to indicate there's a problem

Matus/Lionel: any advance on this one?
Comment 32 Stefan Gruber 2014-11-09 10:45:56 UTC
Seems that LO 4.3.3.2 displays values correctly again.
Tested with opensuse factory build.
Comment 33 Matthew Francis 2014-12-29 07:00:28 UTC
Adding Whiteboard:notBibisectable as this bug appears to depend on specific compile options
Comment 34 Alex Thurgood 2015-01-03 17:39:00 UTC
Adding self to CC if not already on
Comment 35 Björn Michaelsen 2015-03-07 16:00:39 UTC
resolved as per comment 32.
Comment 36 Robinson Tryon (qubit) 2015-12-17 10:58:03 UTC
Migrating Whiteboard tags to Keywords: (notBibisectable)
[NinjaEdit]