Bug 88268 - EDITING: Report builder cause LO to quit unexpectedly when drag resizing header and detail or footer controls together in OSX
Summary: EDITING: Report builder cause LO to quit unexpectedly when drag resizing head...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.3.5.2 release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace
Depends on:
Blocks: Database-Reports-Builder
  Show dependency treegraph
 
Reported: 2015-01-10 14:24 UTC by James B. Byrne
Modified: 2019-09-04 10:28 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
APPLE system report on forced exit (36.49 KB, text/plain)
2015-01-10 14:52 UTC, James B. Byrne
Details
Apple crash trace (101.52 KB, text/plain)
2015-02-11 17:58 UTC, Alex Thurgood
Details
full backtrace (39.83 KB, text/plain)
2015-02-11 18:20 UTC, Alex Thurgood
Details
bt with debug symbols (5.73 KB, text/plain)
2018-08-22 18:10 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description James B. Byrne 2015-01-10 14:24:15 UTC
LO quits unexpectedly when resizing a header section label control and a shift selected associated detail section line text box control by dragging on one of the grouped outline handles.
Comment 1 James B. Byrne 2015-01-10 14:52:48 UTC
Created attachment 112059 [details]
APPLE system report on forced exit
Comment 2 James B. Byrne 2015-01-10 15:10:58 UTC
Overview: More detailed restatement of summary.

    Drag-resizing a group of controls from different report sections causes  LO to become non-responsive.

Steps to Reproduce: 

    1) Create or open a simple report in report builder.

    2) Add a label control to the header section and a text box to detail section.

    3) Using the shift key and mouse select both.

    4) Using the alignment control left align both.

    5) Using the sizing handles displayed on the grouped selection attemp to resize the group.


Actual Results: 

    The application entered a tight loop condition consuming between 50 and 90% of available CPU.  The spinning circle of death displayed whenever an open LO window was selected.  No LO controls reponded to activation or selection.

Expected Results: 

    1.  If the operation is not supported (resizing grouped objects) then that should be reported to the user and the control unchanged.

    2. If the operation is supported then all controls in the selected group should acquire the resized values of the entire selection.

    3. If 2 and an error occurs then the error should be reported and control returned to the user.


Build Date & Hardware:

  See attached Apple system report on forced exit.

    Build 2006-08-10 on Mac OS 10.4.3

Additional Builds and Platforms:

  Unknown at this time

Additional Information:

  This issue does not occur if the new sizes are keyed into the multi-control property box.  

  This issue occurs reliably and often immediately.  If the two controls are aligned and are initially the same size then resizing operations may work for a limited number of attempts but will eventually trigger a tight loop condition.

TOP display:

ID    COMMAND      %CPU   TIME     #TH  #WQ  #PORT #MREG MEM    RPRVT  PURG
91677  soffice      62.6  10:07.42 21/1 0    193-  1516- 156M-  135M-  20K
Comment 3 raal 2015-01-12 10:09:10 UTC
I can not confirm with LO 4.3.5.2, win7
Comment 4 Alex Thurgood 2015-01-12 10:59:18 UTC
@James : comment 2 suggests that you are using  OSX 10.4. This is no longer supported officially by the project, so even if there is a bug, it won't be fixed, and this report would have to be closed as wontfix.

Could you please re-confirm the OS you are using ?

Setting to NEEDINFO in the meantime.
Comment 5 Alex Thurgood 2015-01-12 11:07:42 UTC
Additionally, I see no crash in release build 

Version: 4.3.5.2
Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5

64bit for OSX 10.10.1
Comment 6 James B. Byrne 2015-01-12 14:36:00 UTC
(In reply to Alex Thurgood from comment #4)
> @James : comment 2 suggests that you are using  OSX 10.4. This is no longer
> supported officially by the project, so even if there is a bug, it won't be
> fixed, and this report would have to be closed as wontfix.
> 
> Could you please re-confirm the OS you are using ?
> 
> Setting to NEEDINFO in the meantime.

I have no idea where the crash reporter is getting its information, unless it is reporting about itself.  I am running OSX-10.9.5 I believe.  In any case, it was whatever OSX release that immediately preceded Yosemite.

As to whether it crashed or not I cannot say.  All I can report is that the LO program in its entirety closed when I tired to resize the controls and that it regularly happens.

I can also report that this problem is not evidenced on LO-4.3.5 running on CentOS-6.6.  I have not tried it on a windows box.
Comment 7 Alex Thurgood 2015-01-12 18:54:19 UTC
Hmm, I see this in your trace :

48 rptui::DlgEdFuncSelect::MouseMove(MouseEvent const&) + 304 (librptuilo.dylib) [0x129006c90]
                                            48 ??? [0xffffffffffffffff]
                                              48 _sigtramp + 26 (libsystem_platform.dylib) [0x7fff8dc465aa]
                                                48 JVM_handle_bsd_signal + 1083 (libjvm.dylib) [0x11d208169]
                                                  48 VMError::report_and_die() + 2308 (libjvm.dylib) [0x11d3122a8]
                                                    48 ??? [0x11cdd0e20]

What version(s) of Java are you using ?
Comment 8 Alex Thurgood 2015-01-12 18:56:21 UTC
You need to install Apple's own JavaforOSX, prior to, any other Oracle supplied version.
Comment 9 Alex Thurgood 2015-02-11 17:57:47 UTC
I can now confirm this bug on OSX 10.10.2 with my master 4500alpha build.

I put a label in the header section and a text box in the footer section.
Then I selected both with the mouse and Cmd button.
Next, I tried to enlarge the size of both controls simultaneously by dragging a corner handle diagonally.

LO hangs and beachball of aplication wait starts spinning
Apple crash trace enclosed.
Comment 10 Alex Thurgood 2015-02-11 17:58:27 UTC
Created attachment 113318 [details]
Apple crash trace
Comment 11 Alex Thurgood 2015-02-11 18:20:56 UTC
Created attachment 113319 [details]
full backtrace

Notice that there are at least two sigsegv points here.
The first occurred when I just opened a report in Edit mode.
The second when I tried enlarging the controls selected together, as per bug report - I only ran the bt on the second sigsegv as LO was incapable of recovering from that.
Comment 12 Julien Nabet 2015-02-11 20:09:12 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this, part of bt:
0x00002aaacaa100ef in SdrDragResize::GetSdrDragPointer (this=0x69f5bf0)
    at /home/julien/compile-libreoffice/libreoffice/svx/source/svdraw/svddrgmt.cxx:2100
2100	        return pHdl->GetPointer();
(gdb) bt
#0  0x00002aaacaa100ef in SdrDragResize::GetSdrDragPointer (this=0x69f5bf0)
    at /home/julien/compile-libreoffice/libreoffice/svx/source/svdraw/svddrgmt.cxx:2100
#1  0x00002aaacabba0fa in SdrView::GetPreferredPointer (this=0x31848a0, 
    rMousePos=Point = {...}, pOut=0x3010a70, nModifier=0, bLeftDown=false)
    at /home/julien/compile-libreoffice/libreoffice/svx/source/svdraw/svdview.cxx:962
#2  0x00002aaae0566950 in rptui::DlgEdFuncSelect::MouseMove (this=0x68b89b0, 
    rMEvt=...)
    at /home/julien/compile-libreoffice/libreoffice/reportdesign/source/ui/report/dlgedfunc.cxx:913
#3  0x00002aaae05a9d7c in rptui::OReportSection::MouseMove (this=0x3010a70, 
    rMEvt=...)
    at /home/julien/compile-libreoffice/libreoffice/reportdesign/source/ui/report/ReportSection.cxx:402
#4  0x00002aaab1ae6410 in ImplHandleMouseEvent (pWindow=0x31049b0, 
    nSVEvent=MOUSEMOVE, bMouseLeave=false, nX=431, nY=193, nMsgTime=49069011, 
    nCode=1, nMode=DRAGMOVE)
    at /home/julien/compile-libreoffice/libreoffice/vcl/source/window/winproc.cxx:720
#5  0x00002aaab1aec543 in ImplHandleSalMouseMove (pWindow=0x31049b0, 
    pEvent=0x7fffffff4770)

I had to resize several times to have the crash.
Comment 13 Julien Nabet 2015-02-11 20:28:30 UTC
Putting a breakpoint in svx/source/svdraw/svddrgmt.cxx:2100, I made some tests and got this:
SdrHdl::GetPointer (this=0x71d37c0) at /home/julien/compile-libreoffice/libreoffice/svx/source/svdraw/svdhdl.cxx:798
798	{
(gdb) n
799	    PointerStyle ePtr=POINTER_MOVE;
(gdb) 
...
=> OK

But at another moment:
(gdb) s
drawinglayer::primitive2d::BasePrimitive2D::getDecomposition (this=0x7fffffff41a0, rViewParameters=uno::Sequence of length 10922 = {...})
    at /home/julien/compile-libreoffice/libreoffice/drawinglayer/source/primitive2d/baseprimitive2d.cxx:60
60	        {
(gdb) n
61	            const geometry::ViewInformation2D aViewInformation(rViewParameters);
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaad610f57 in cppu::_copyConstructAnyFromData (pDestAny=0x2aaae8731028, 
    pSource=0x2aaab6221bd6 <non-virtual thunk to drawinglayer::primitive2d::BasePrimitive2D::getRange(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&)>, 
    pType=0x2aaab6221b02 <non-virtual thunk to drawinglayer::primitive2d::BasePrimitive2D::getDecomposition(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&)>, pTypeDescr=0x0, acquire=0x2aaab6217080 <com::sun::star::uno::cpp_acquire(void*)>, mapping=0x0)
    at /home/julien/compile-libreoffice/libreoffice/cppu/source/uno/copy.hxx:109
109	    TYPE_ACQUIRE( pType );

=> KO
Comment 14 QA Administrators 2016-02-21 08:35:28 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2017-03-06 15:17:20 UTC Comment hidden (obsolete)
Comment 16 Alex Thurgood 2017-08-18 12:46:02 UTC
Reproduced with LO 5403 release MacOS 10.12.6
Comment 17 QA Administrators 2018-08-19 02:37:00 UTC Comment hidden (obsolete)
Comment 18 Alex Thurgood 2018-08-21 15:06:17 UTC
Still reproducible with LO 6103
Comment 19 Julien Nabet 2018-08-22 18:10:42 UTC
Created attachment 144374 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, I gave a new try and had an assert.

I provided bt + some gdb session
Comment 20 Julien Nabet 2018-08-22 18:13:22 UTC
Noel: noticing cdd211d0a3f8bf977ecca67e72afbc63d53a72ee and 331e2e5ed3bf4e0b2c1fab3b7bca836170317827, thought you might be interested in the assertion retrieved in previous comment.

Should Point be changed to use sal_Int32 instead of long? If yes, I suppose it may have an important impact.
Comment 21 Noel Grandin 2018-08-22 20:04:43 UTC
Julien, those very large numbers you saw in the gdb session in SdrDragStat indicate that something went wrong earlier in the code, we should never (except for pathalogical documents with ridiculourly large page sizes) see large numbers like that in there.
Comment 22 QA Administrators 2019-09-02 09:23:57 UTC Comment hidden (obsolete)
Comment 23 Alex Thurgood 2019-09-04 10:28:32 UTC
Still reproducible in 

Version: 6.4.0.0.alpha0+
Build ID: e04b6f3c0cdacf2a3cdcd3f34bad54c8764ff1ed
CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; 
Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US
Calc: threaded