Bug 89643

Please provide sample ODB file with test report and detailed instructions on how to reproduce

Setting to NEEDINFO pending requested information.

Please set back to UNCONFIRMED once information has been provided.

When using a POSTGRESQL connection to create a report using REPORT BUILDER and try adding a formula field if you type = COUNT () the program crashes and closes without reporting any error. The error you can play with any database .... created from scratch. work with Ubuntu 14.10.

Created attachment 113703 [details]
DB

DB whitout tables....

Created attachment 113717 [details]
Database with a report and a free field to test

Could confirm the buggy behavior.
Open the attached database.
Open the report for editing.
Click on the field without any content (under "=value")
In properties click on Data → DataFiled.
Click on the button with the three point. The Function Wizard will appear.
Doubleclick on "COUNT".
LO will crash immediately.
Last worked here with LO 4.3.1.2, first crashing version is LO 4.3.2.2

My System: OpenSUSE 13.2 64bit rpm Linux with many different LO-versions.

Confirmed by Robert as a regression

Created attachment 113866 [details]
Apple crash trace

The problem is far worse in my master build on OSX :

- no data is displayed in the table view mode at all, just a blank grid and column headers ;

- as soon as I right mouse button click on the empty field indicated in Robert's instructions, LO waits, then crashes

In a production release of LO 

Process 83749 launched: '/Applications/LibreOffice.app/Contents/MacOS/soffice' (x86_64)
Process 83749 stopped
* thread #1: tid = 0x2dfa85, 0x000000010a710a83 libgcc3_uno.dylib`cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) + 1299, queue = 'com.apple.main-thread', stop reason = signal SIGSEGV
    frame #0: 0x000000010a710a83 libgcc3_uno.dylib`cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) + 1299
libgcc3_uno.dylib`cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) + 1299:
-> 0x10a710a83:  callq  *0x10(%rdi)
   0x10a710a86:  cmpq   $0x0, -0x68(%rbp)
   0x10a710a8b:  je     0x10a710b65               ; cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) + 1525
   0x10a710a91:  movq   -0x78(%rbp), %rax

Tested on 

Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale : fr_

OSX 10.10.2

Created attachment 113870 [details]
bt from non debug build

Seems not specific to COUNT(), happens with all functions.

Created attachment 113892 [details]
Valgrind trace with master sources

Created attachment 113893 [details]
bt with debug symbols

I noticed these logs during tests:
warn:i18nlangtag:14851:1:i18nlangtag/source/languagetag/languagetag.cxx:1380: LanguageTagImpl::convertLocaleToLang: with bAllowOnTheFlyID invalid 'de-'
warn:legacy.osl:14851:1:reportdesign/source/core/sdr/RptObject.cxx:368: OUnoObject::EndListening: not listening currently!
warn:legacy.osl:14851:1:reportdesign/source/core/sdr/RptObject.cxx:351: OUnoObject::StartListening: already listening!

Since that "formula" module is shared with Calc, would our Calc "FindTheExpert"s have some clue on what change could have caused this?


In the backtrace, the problematic line is:

        if( pFuncPage->GetCategory() != static_cast<sal_Int32>(pFuncDesc->getCategory()->getNumber() + 1) )


The problem is that pFuncDesc->getCategory() returns some kind of "smart pointer" that contains a null raw pointer, so ->getNumber() segfaults. IFunctionCategory seems to be an abstract class with two implementations:
reportdesign/source/ui/inc/FunctionHelper.hxx: class FunctionCategory
sc/inc/funcdesc.hxx: class ScFunctionCategory

To chase this I suppose we should follow how/when these are created and filled out, or maybe how/when a meaningful "category" member is filled in pFuncDesc.

What strikes me is that just before the crash, the display of the formula is e.g.
 =COUNT( ) )
instead of
 =COUNT( )

Maybe that's linked...

*** Bug 89769 has been marked as a duplicate of this bug. ***

*** Bug 90067 has been marked as a duplicate of this bug. ***

*** Bug 89567 has been marked as a duplicate of this bug. ***

I noticed this function http://opengrok.libreoffice.org/xref/core/formula/source/ui/dlg/funcpage.cxx#65
     65 inline sal_uInt16 Lb2Cat( sal_uInt16 nLbPos )
     66 {
     67     // Category 0 == LRU, otherwise Categories == LbPos-1
     68     if ( nLbPos > 0 )
     69         nLbPos -= 1;
     70 
     71     return nLbPos;
     72 }
whereas the only location where this function is called is this:
    114 void FuncPage::UpdateFunctionList()
    115 {
    116     sal_Int32  nSelPos   = m_pLbCategory->GetSelectEntryPos();
    117     const IFunctionCategory* pCategory = static_cast<const IFunctionCategory*>(m_pLbCategory->GetEntryData(nSelPos));
    118     sal_Int32  nCategory = ( LISTBOX_ENTRY_NOTFOUND != nSelPos )
    119                             ? Lb2Cat( nSelPos ) : 0;

so shouldn't it be:
inline sal_Int32 Lb2Cat( sal_Int32 nLbPos )
to begin with?

Just noticed that nCategory isn't used, so this part + inline function could be removed.

This seems to have been variously broken and fixed on several different occasions during 4.4 master, but the crash at issue is I think the one that started at the below commit.
(Not Cc'ing Markus Mohrhard on bugs by his request)

    commit 3d6521280929ecacc53b7c358d29d0b5d31b3462
    Author:     Markus Mohrhard <markus.mohrhard@googlemail.com>
    AuthorDate: Thu Jul 31 21:43:59 2014 +0200
    Commit:     Markus Mohrhard <markus.mohrhard@googlemail.com>
    CommitDate: Thu Jul 31 22:14:25 2014 +0200
    
        fix memory leak around function descriptions
    
        Found by Lsan.
    
        Change-Id: Ia443ed6eb2a20854998a615f3c2bd9fdac156a8c

*** Bug 90383 has been marked as a duplicate of this bug. ***

*** Bug 90880 has been marked as a duplicate of this bug. ***

Changed the Hardware to "All". Bug appears for Windows, Mac and Linux ...

Win7 64 bit system. 
Crash happens as of 4.3.2.1 version. (tested also on 4.3.2.2, 4.3.5.1, 4.3.7.2 and 4.4.3.2).
Works fine up to 4.3.1.2 version (also tested on 4.3.0.4 and 4.3.1.1).

In a nutshell, problem occurs since 4.3.2 versions.

There are two implementations of getCategory, one (sc) returns a new one each time (hence the leak fix) and the other (reportdesign) returns a pointer to one that belongs to the manger (hence the crash).

The code in formula really looks to me to expect that the getCategory return a pointer that "someone else" needs to look after, i.e. the reportdesign variant is the more correct and the sc "gets away with it" because its IFunctionCategory impl is so thin that the guts of ScFunctionCategory live on past the death of ScFunctionCategory.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7c3abee29c742593206b755b20a718c46f0780fa

Resolves: tdf#89643 report builder function wizard segfaults

It will be available in 5.1.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.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=73107eb3375f1671f549f0467be2812df9223848&h=libreoffice-5-0

Resolves: tdf#89643 report builder function wizard segfaults

It will be available in 5.0.0.0.beta4.

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.

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4e3d54fc9542af87d718b24bcd76a0529133f45f&h=libreoffice-4-4

Resolves: tdf#89643 report builder function wizard segfaults

It will be available in 4.4.5.

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.