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.
Created attachment 112059 [details] APPLE system report on forced exit
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
I can not confirm with LO 4.3.5.2, win7
@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.
Additionally, I see no crash in release build Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 64bit for OSX 10.10.1
(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.
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 ?
You need to install Apple's own JavaforOSX, prior to, any other Oracle supplied version.
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.
Created attachment 113318 [details] Apple crash trace
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.
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.
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
Reproduced with LO 5403 release MacOS 10.12.6
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with LO 6103
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
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.
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.
Dear James B. Byrne, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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
Dear James B. Byrne, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
On pc Debian x86-64 with master sources updated today, I don't reproduce this but perhaps I missed something. Indeed after 3) (having select both elements, label + textbox), I don't succeed in aligning label to the left as described in 4). Indeed, when selecting both it becomes a group and if textbox is already at left, it won't change anything. So I must select only label which wasn't at left then put it at left. Finally, when selecting both and resizing the group, no crash even after undoing and trying again. Could someone give a new try?
No repro with Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Mac OS X 13.4; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Calc: threaded