Bug 33435

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);
2.Copy;
3.Select all cells (clicking the left top button);
4.Paste special;
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.

BrOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Kernel 2.6.32-5-686 i686 (32 bit)
Distro Linux Mint Debian Edition

Created attachment 43724 [details]
Backtrace

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;
Hit OK.

*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 ()
   from /opt/libreoffice/program/../basis-link/program/libsvlli.so
#1  0xad146fc3 in ?? ()
   from /opt/libreoffice/program/../basis-link/program/libscli.so
#2  0xad147140 in ?? ()
   from /opt/libreoffice/program/../basis-link/program/libscli.so
#3  0xad0a69ce in ?? ()
   from /opt/libreoffice/program/../basis-link/program/libscli.so
#4  0xad0a6f89 in ?? ()
   from /opt/libreoffice/program/../basis-link/program/libscli.so
#5  0xad0a87ab in ?? ()
   from /opt/libreoffice/program/../basis-link/program/libscli.so
#6  0xad0c84fa in ?? ()
   from /opt/libreoffice/program/../basis-link/program/libscli.so
#7  0xad16866e in ?? ()
   from /opt/libreoffice/program/../basis-link/program/libscli.so
---

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.

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:
http://wiki.documentfoundation.org/BugReport#How_to_get_backtrace_.28on_Linux.29

I downloaded rpm libreoffice*-debuginfo packages from:
http://download.opensuse.org/repositories/LibreOffice:/Unstable/openSUSE_11.3/i586/

Then I converted all of them to deb with alien and installed them with dpkg. But 3 packages gave errors:
 libreoffice-libs-core-devel-debuginfo_3.3.1.2-19.2_i386.deb
 libreoffice-libs-extern-devel-debuginfo_3.3.1.2-19.2_i386.deb
 libreoffice-ure-devel-debuginfo_3.3.1.2-20.2_i386.deb

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);
> 2.Copy;
> 3.Select all cells (clicking the left top button);
> 4.Paste special;
> 5.Leave only "Format" box checked.

Confirmed with:
LO 4.2.0.0.alfa0
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)