LibreOffice Spreadsheet crashes while try to set border to cell(s)

[DeivAstra]

Version: 5.0.1.2.0+
Build ID: 00m0(Build:2)

[7c6f434c]

Could we have more details:

What LO versions crash? What architecture (i686 or amd64)? What channel are you using? Does it matter what borders to set? I ask because I tried with the latest master (5.0.4.2 LibreOffice) and a random border for a random cell worked fine.

[DeivAstra]

amd64
nixos-15.09 b85b8a as I understand it's stable version
libreoffice-5.0.1.2

[7c6f434c]

amd64
nix-env -iA nixos.pkgs.libreoffice
libreoffice-5.0.1.2
Where you get 5.0.4.2?

This is the version in NixPkgs git master.

It has not been built by Hydra, though. A pity. So for now the only way
to get it is to build it.

If you have some disk space to spare, you can get a one-click install
from http://hydra.nixos.org/build/29628063 (5.0.2.2)

Some 5.0.2.2 is also in unstable channel.

I am currently downloading 5.0.1.2 from cache…

[7c6f434c]

Got /nix/store/94ix7j27fzp26i72vc3bdz06py5gxm7v-libreoffice-5.0.1.2 from Hydra, set a random border, doesn't crash for me (amd64, Intel i7)

[DeivAstra]

I think your system libs different that my..
for example my glibc is 2.21
(gdb) backtrace
#0 0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0

What version of your glibc?

[7c6f434c]

I think your system libs different that my..
for example my glibc is 2.21
(gdb) backtrace
#0 0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0

What version of your glibc?

I have multiple. Well, what is the path to your LibreOffice? Maybe I can
get the exact same closure from cache…

I think when I ran LibreOffice from 15.09 release, it got glibc 2.21.

/nix/store/r5kd93xi2pwpycaj1jlimfgzrhslyryl-glibc-2.21 to be precise.

I do hope the problem is not about video driver difference (there are
two actually global things: session like DBus etc., as I am on
not-exactly-NixOS, and video stack where rolling back is some amount of
hassle, although unlike NixOS I can try rebuilding and running a second
X11 session).

[DeivAstra]

(gdb) backtrace
#0 0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0
#1 0x00007f16106c013e in osl_waitCondition () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-5.0.1.2/lib/libreoffice/program/libuno_sal.so.3
#2 0x00007f16106c79a8 in osl_joinProcessWithTimeout () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-5.0.1.2/lib/libreoffice/program/libuno_sal.so.3
#3 0x0000000000406257 in sal_main_with_args ()
#4 0x00000000004033ca in main ()

I am not guru, but can suggest to you get binded libraries by gdb:

$ soffice --calc &
[1] 10190
$ gdb --pid=10190

About the video driver...May be it's idea..For example, now the Firefox has some artifacts on the toolbar icons. The web pages renders correctly as I see and other apps also correctly. I seen before like that when try to switch to SNA from UXA on the other distros.

Now SNA(i915) is enabled, so, I will try to switch to UXA.

[7c6f434c]

(gdb) backtrace
#0 0x00007f160f220cc8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libpthread.so.0
#1 0x00007f16106c013e in osl_waitCondition () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-5.0.1.2/lib/libreoffice/program/libuno_sal.so.3
#2 0x00007f16106c79a8 in osl_joinProcessWithTimeout () from /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-5.0.1.2/lib/libreoffice/program/libuno_sal.so.3
#3 0x0000000000406257 in sal_main_with_args ()
#4 0x00000000004033ca in main ()

This is the segfault backtrace for setting the border? I hoped there
would be more hints about what went wrong…

I am not guru, but can suggest to you get binded libraries by gdb:

$ soffice --calc &
[1] 10190
$ gdb --pid=10190

strace -f -s 9999 -o /tmp/log /nix/store/jd0ddqiaby37v367vfq0smrj2d311hd2-libreoffice-5.0.1.2/bin/scalc

I can see very well that

/nix/store/npfsi1d9ka8zwnxzn3sr08hbwvpapyk7-glibc-2.21/lib/libc.so.6
gets opened, yes.

Still doesn't change the behaviour.

About the video driver...May be it's idea..For example, now the Firefox has some artifacts on the toolbar icons. The web pages renders correctly as I see and other apps also correctly. I seen before like that when try to switch an acceleration(SNA) from UXA method on the other distros.

Now SNA(i915) is enabled, so, I will try to switch to UXA.

I have SNA and i915. Not artifacts in Firefox, though.

[7c6f434c]

Hm, your mentioning toolbars reminded me that I have a relatively narrow LibreOffice window by default and don't see the entire toolbar.

Reproduced the crash by using the toolbar button (previously I only tried borders via cell formatting)

scalc --backtrace seems to give a nice backtrace via gdb. Will try to understand whether it is a unique problem now…

[7c6f434c]

OK, there is a very similar upstream problem, and an alleged fix for it is included into our LibreOffice build, and still 5.0.4.2 crashes in the same place.

[DeivAstra]

It's my imperfection that I did't give complete path to reproduce.
We had waste time, sorry.

Setting borders via cell formatting also working well.

[7c6f434c]

It's my imperfection that I did't give complete path to reproduce.
We had waste time, sorry.

You could reasonably expect that I would not have the crucial button
just behind the edge of the window…

What surprises me is that apparently the problem is slightly different
from the problem recently fixed in upstream… At least with 5.0.4.2,
where it should have been fixed.

[Profpatsch]

(triage) has this been fixed @danykey @7c6f434c?

[7c6f434c]

My impression is that current LibreOffice-still (which is from the next branch) lacks this problem. Can you reproduce it now. @danykey ?

[jpierre03]

(triage) maybe not a problem anymore @danykey @7c6f434c ?

[7c6f434c]

I cannot reproduce it with 5-series.

[7c6f434c]

I guess there has been enough pings… reopening is not hard anyway.