Bug Hunting Session
Bug 89643 - report builder: function wizard segfaults as soon as a function is inserted
Summary: report builder: function wizard segfaults as soon as a function is inserted
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.2.2 release
Hardware: x86-64 (AMD64) All
: high critical
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.1.0 target:5.0.0.0.beta4 tar...
Keywords: bibisected, bisected, regression
: 89567 89769 90067 90383 90880 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-25 10:11 UTC by xantitxo
Modified: 2016-10-25 19:21 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:


Attachments
DB (1.71 KB, application/vnd.oasis.opendocument.database)
2015-02-26 08:05 UTC, xantitxo
Details
Database with a report and a free field to test (7.94 KB, application/vnd.oasis.opendocument.database)
2015-02-26 19:55 UTC, Robert Großkopf
Details
Apple crash trace (96.28 KB, text/plain)
2015-03-04 08:14 UTC, Alex Thurgood
Details
bt from non debug build (28.86 KB, text/plain)
2015-03-04 09:10 UTC, Alex Thurgood
Details
Valgrind trace with master sources (30.15 KB, application/x-bzip)
2015-03-04 21:00 UTC, Julien Nabet
Details
bt with debug symbols (4.81 KB, text/plain)
2015-03-04 21:01 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description xantitxo 2015-02-25 10:11:48 UTC
When creating a report, try to add a field that is COUNT () or counta () the program automatically closes when writing the last parenthesis.
Comment 1 Alex Thurgood 2015-02-25 15:31:03 UTC
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.
Comment 2 xantitxo 2015-02-26 08:05:09 UTC
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.
Comment 3 xantitxo 2015-02-26 08:05:57 UTC
Created attachment 113703 [details]
DB

DB whitout tables....
Comment 4 Robert Großkopf 2015-02-26 19:55:04 UTC
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.
Comment 5 Alex Thurgood 2015-03-04 08:03:01 UTC
Confirmed by Robert as a regression
Comment 6 Alex Thurgood 2015-03-04 08:14:31 UTC
Created attachment 113866 [details]
Apple crash trace
Comment 7 Alex Thurgood 2015-03-04 08:17:13 UTC
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
Comment 8 Alex Thurgood 2015-03-04 08:56:46 UTC
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
Comment 9 Alex Thurgood 2015-03-04 09:09:07 UTC
Tested on 

Version: 4.4.0.3
Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7
Locale : fr_

OSX 10.10.2
Comment 10 Alex Thurgood 2015-03-04 09:10:09 UTC
Created attachment 113870 [details]
bt from non debug build
Comment 11 Lionel Elie Mamane 2015-03-04 09:20:50 UTC
Seems not specific to COUNT(), happens with all functions.
Comment 12 Julien Nabet 2015-03-04 21:00:40 UTC
Created attachment 113892 [details]
Valgrind trace with master sources
Comment 13 Julien Nabet 2015-03-04 21:01:27 UTC
Created attachment 113893 [details]
bt with debug symbols
Comment 14 Julien Nabet 2015-03-04 22:26:27 UTC
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!
Comment 15 Lionel Elie Mamane 2015-03-05 06:36:30 UTC
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...
Comment 16 Julien Nabet 2015-03-05 19:02:13 UTC
*** Bug 89769 has been marked as a duplicate of this bug. ***
Comment 17 Julien Nabet 2015-03-17 17:54:47 UTC
*** Bug 90067 has been marked as a duplicate of this bug. ***
Comment 18 Julien Nabet 2015-03-21 07:57:34 UTC
*** Bug 89567 has been marked as a duplicate of this bug. ***
Comment 19 Julien Nabet 2015-03-21 12:59:36 UTC
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?
Comment 20 Julien Nabet 2015-03-21 13:06:21 UTC
Just noticed that nCategory isn't used, so this part + inline function could be removed.
Comment 21 Matthew Francis 2015-03-31 02:40:11 UTC
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
Comment 22 Alex Thurgood 2015-04-01 08:36:17 UTC
*** Bug 90383 has been marked as a duplicate of this bug. ***
Comment 23 Robert Großkopf 2015-04-27 13:59:06 UTC
*** Bug 90880 has been marked as a duplicate of this bug. ***
Comment 24 Robert Großkopf 2015-04-27 14:01:55 UTC
Changed the Hardware to "All". Bug appears for Windows, Mac and Linux ...
Comment 25 agojc 2015-05-24 18:22:23 UTC
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.
Comment 26 Caolán McNamara 2015-06-11 15:31:32 UTC
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.
Comment 27 Commit Notification 2015-06-11 16:11:13 UTC
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.
Comment 28 Commit Notification 2015-06-11 16:12:39 UTC
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.
Comment 29 Commit Notification 2015-06-15 10:26:25 UTC
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.
Comment 30 Robinson Tryon (qubit) 2015-12-17 08:47:17 UTC Comment hidden (obsolete)