Created attachment 42412 [details]
Contains problem details and system config
1. Open a spreadsheet.
2. Enter data with different formats.
3. Select one cell using Format Paintbrush.
4. Click on top cell to highlight full spreadsheet to apply format to complete spreadsheet.
LO becomes unresponsive and hangs. Need to force quit.
(Maybe the user isn't supposed to be able to do this, but if so, then it shouldn't be something the user can select.)
Problem details and system config attached.
nice catch!! Kohei,
I reproduced on linux with slight variation in the steps ( probably I missed something when trying the orig steps ) but... pretty sure the hang is the same
1) open spreadsheet
2) select format paintbrush
3) click the top left corner to select all the sheet
4) click on sheet
That also happens when copying and pasting formats manually thru "Paste special":
1.Select a cell (or a bunch of);
3.Select all cells (clicking the left top button);
5.Leave only "Format" box checked.
Office hangs at 100% CPU (glad I'm using a dual CPU...) for over 20 minutes (well, it's still hung - had to pkill it).
Pasting formats in smaller areas (like a column) works OK.
Kernel 2.6.32-5-686 i686 (32 bit)
Distro Linux Mint Debian Edition
Created attachment 43724 [details]
Here's a backtrace* from a Calc session. Steps:
Opened a new spreadsheet by clicking in the spreadsheet icon inside an empty LibreOffice window;
Copied the first cell thru Ctrl-C;
Selected all cells thru Ctrl-A;
Paste special thru Ctrl-Shift-V;
Check "Format" and unckeck all other options in paste special dialog;
*I don't have *buginfo packages installed, because I just couldn't find sources or Debian installers. If someone helps me finding installable sources or the like, I'm willing to redo the backtrace, if needed.
BTW, I use Gnome (if of any help).
(In reply to comment #3)
> *I don't have *buginfo packages installed...
Yes, I really meant *debuginfo. Sorry for the distraction...
Backtrace is not usable, I'm afraid.
(In reply to comment #5)
> Backtrace is not usable, I'm afraid.
Because of nature of bug of lack of info in the backtrace itself?
Either way, let's not say "has backtrace" when we don't. I didn't mean to hurt your feeling.
(In reply to comment #7)
> Either way, let's not say "has backtrace" when we don't. I didn't mean to hurt
> your feeling.
Nope, I just wanted to know what is lacking, so I can be of real help (I really thought we had an useful bactrace). If the problem is the backtrace format, I'll do my best to get an useful one.
(In reply to comment #8)
> Nope, I just wanted to know what is lacking, so I can be of real help (I really
> thought we had an useful bactrace). If the problem is the backtrace format,
> I'll do my best to get an useful one.
So, when you look at your backtrace for thread 1 (we are almost always interested in thread 1), you see a bunch of "0xad146fc3 in ?? ()"
#0 0xb73bf7f4 in SfxItemSet::GetItemState(unsigned short, unsigned char, SfxPoolItem const**) const ()
#1 0xad146fc3 in ?? ()
#2 0xad147140 in ?? ()
#3 0xad0a69ce in ?? ()
#4 0xad0a6f89 in ?? ()
#5 0xad0a87ab in ?? ()
#6 0xad0c84fa in ?? ()
#7 0xad16866e in ?? ()
and we need to have names instead of those '??' marks. Gdb can't show names because it didn't have access to debug symbols.
Usable backtrace contains lines like #0 and #11 for the entire stack. This one is not really usable because of these '??'s. For you to get a meaningful trace, you need to install debug symbols packages or something similar, if your distro provides them.
OpenSUSE provides libreoffice-*-debuginfo and -debugsource. I don't know about Debian.
(In reply to comment #9)
> ... For you to get a meaningful trace, you need to install debug symbols
> packages or something similar, if your distro provides them.
> OpenSUSE provides libreoffice-*-debuginfo and -debugsource. I don't know about
Debian doesn't seem to have it. Do you (or anybody else) know about installable debug symbols stuff, even in source? I could try to rpm->deb it, but dunno how reliable the trace would be (or if it would ever work).
Just for the record:
I followed the steps to get a backtrace from here:
I downloaded rpm libreoffice*-debuginfo packages from:
Then I converted all of them to deb with alien and installed them with dpkg. But 3 packages gave errors:
I tried to open a debug session anyway, and had this disencouraging warning:
Reading symbols from /opt/libreoffice/program/soffice.bin...(no debugging symbols found)...done.
Went all the way thru anyway, and my gdb.log didn't have thread names again.
That is: I can't get a backtrace in Debian (actually, Debian Mint). But I'm still willing to try if someone more knowledgeable has a hint.
Confirmed in 3.4 RC1 one as well.
(In reply to comment #12)
> Confirmed in 3.4 RC1 one as well.
On x86_64 Mandriva Linux 2010.2 that is.
Created attachment 47296 [details]
Backtrace from libreoffice-3-4.
A bit more information, just tell me if this is still inferior.
(In reply to comment #14)
> Created attachment 47296 [details]
> Backtrace from libreoffice-3-4.
> A bit more information, just tell me if this is still inferior.
The backtrace looks good. Thanks.
(In reply to comment #2)
> 1.Select a cell (or a bunch of);
> 3.Select all cells (clicking the left top button);
> 4.Paste special;
> 5.Leave only "Format" box checked.
Build ID: 2013-06-24 own debug build
Windows 7 Professional SP1 64 bit
Calc is not responding, no crash.
*** Bug 81891 has been marked as a duplicate of this bug. ***
Created attachment 105829 [details]
bt with master sources
On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.
I attached a bt at random. I thought it might help to have a recent bt.
Kohei: sorry to put you back in cc but it's just to know if there could be some possible fix with the new way to deal with cells. Any thoughts? (I attached a new bt from master sources)
** 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.1 or preferably 184.108.40.206 or later)
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)
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: 2015-10-14
Appears to be fixed now.
I can't select the full sheet and try to paste format or use Format Painter and select the complete spreadsheet.
Tested using: LibreOffice for Mac
Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe
Locale: en-CA (en.UTF-8)
Migrating Whiteboard tags to Keywords: (perf )