Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1597683 - clucene-2.3.3.4-32.20130812.e8e3d20git.fc29.i686 built with "typedef long double float_t"?
Summary: clucene-2.3.3.4-32.20130812.e8e3d20git.fc29.i686 built with "typedef long dou...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: clucene
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-03 12:27 UTC by Stephan Bergmann
Modified: 2018-07-23 14:25 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-18 15:29:49 UTC


Attachments (Terms of Use)

Description Stephan Bergmann 2018-07-03 12:27:29 UTC
Debugging the failed LibreOffice rawhide i686 build <https://koji.fedoraproject.org/koji/taskinfo?taskID=27975925>, it looks like the CLucene that LibreOffice builds against has been built with float_t (from math.h) being a typedef for (80 bit) long double instead of the usual (32 bit) float:

/usr/include/CLucene/document/Field.h defines a class Field with last data member

> 	float_t boost;

and LibreOffice creates a Field instance on the heap with

>     doc->add(*_CLNEW Field(_T("path"), &aPath[0], Field::STORE_YES | Field::INDEX_UNTOKENIZED));

(HelpIndexer::helpDocument in helpcompiler/source/HelpIndexer.cxx).  LibreOffice calls ::operator new with its idea of sizeof(Field) based on float_t being a typedef for float, but CLucene's Field ctor writes a long double into the boost member, witness the "fstpt 0x18(%esi)" instruction in _ZN6lucene8document5FieldC2EPKwPNS_4util6ReaderEi (/lib/libclucene-core.so.1), which causes a write of 10 - 4 = 6 bytes past the end of the allocated memory.

And running the code under valgrind (`LD_LIBRARY_PATH=/builddir/build/BUILD/libreoffice-6.0.5.2/instdir/program valgrind workdir/LinkTarget/Executable/HelpIndexer -lang en-US -mod help -dir /builddir/build/BUILD/libreoffice-6.0.5.2/workdir/Extension/nlpsolver/root/help/en-US`) shows

> ==88== Invalid write of size 4
> ==88==    at 0x4AFADEA: lucene::document::Field::Field(wchar_t const*, wchar_t const*, int, bool) (in /usr/lib/libclucene-core.so.2.3.3.4)
> ==88==    by 0x4CE5DC3: HelpIndexer::helpDocument(rtl::OUString const&, lucene::document::Document*) const (HelpIndexer.cxx:118)
> ==88==    by 0x4CE6649: HelpIndexer::indexDocuments() (HelpIndexer.cxx:64)
> ==88==    by 0x10985F: main (HelpIndexer_main.cxx:81)
> ==88==  Address 0x7541404 is 0 bytes after a block of size 28 alloc'd
> ==88==    at 0x4831829: operator new(unsigned int) (vg_replace_malloc.c:328)
> ==88==    by 0x4CE5DA5: HelpIndexer::helpDocument(rtl::OUString const&, lucene::document::Document*) const (HelpIndexer.cxx:118)
> ==88==    by 0x4CE6649: HelpIndexer::indexDocuments() (HelpIndexer.cxx:64)
> ==88==    by 0x10985F: main (HelpIndexer_main.cxx:81)
> ==88== 
> ==88== Invalid write of size 2
> ==88==    at 0x4AFADEA: lucene::document::Field::Field(wchar_t const*, wchar_t const*, int, bool) (in /usr/lib/libclucene-core.so.2.3.3.4)
> ==88==    by 0x4CE5DC3: HelpIndexer::helpDocument(rtl::OUString const&, lucene::document::Document*) const (HelpIndexer.cxx:118)
> ==88==    by 0x4CE6649: HelpIndexer::indexDocuments() (HelpIndexer.cxx:64)
> ==88==    by 0x10985F: main (HelpIndexer_main.cxx:81)
> ==88==  Address 0x7541408 is 4 bytes after a block of size 28 alloc'd
> ==88==    at 0x4831829: operator new(unsigned int) (vg_replace_malloc.c:328)
> ==88==    by 0x4CE5DA5: HelpIndexer::helpDocument(rtl::OUString const&, lucene::document::Document*) const (HelpIndexer.cxx:118)
> ==88==    by 0x4CE6649: HelpIndexer::indexDocuments() (HelpIndexer.cxx:64)
> ==88==    by 0x10985F: main (HelpIndexer_main.cxx:81)
[...]

(CLucene's cmake machinery has a src/shared/cmake/DefineFloat.cmake that would "SET ( _FLT_EVAL_METHOD 2 )" if "NOT HAVE_SYMBOL_FLOAT_T".  In the C standard, if the value of FLT_EVAL_METHOD (float.h) is 2, float_t (math.h) will be a typedef for long double.)

Comment 1 Rex Dieter 2018-07-09 03:36:37 UTC
Unfortunately, the upstream's history of src/shared/cmake/DefineFloat.cmake is... unhelpful.  No idea why they think FLT_EVAL_METHOD=2 is needed here.

I assume you're suggesting to not do that, and effectively do FLT_EVAL_METHOD 0, where float matches what libreoffice expects?

Comment 2 Caolan McNamara 2018-07-18 07:19:58 UTC
Seeing as libreoffice in rawhide now builds on i686 again I presume this issue is now moot

Comment 3 Rex Dieter 2018-07-18 15:29:49 UTC
OK, I'll close this for now.

Please re-open if you have any reason to believe issues need fixing.

Comment 4 Stephan Bergmann 2018-07-23 14:25:29 UTC
(In reply to Caolan McNamara from comment #2)
> Seeing as libreoffice in rawhide now builds on i686 again I presume this
> issue is now moot

Maybe those builds were done against clucene-2.3.3.4-33.20130812.e8e3d20git.fc29, which was recently built (2018-07-13)?  From the symptoms, this smells like an issue with the build env of the old clucene-2.3.3.4-32.20130812.e8e3d20git.fc29, so may well have been solved with that fresh build.


Note You need to log in before you can comment on or make changes to this bug.