Bug 35723 - On x86_64 architecture, Libreoffice will crash (SIGSEGV) during startup in zlib library
Summary: On x86_64 architecture, Libreoffice will crash (SIGSEGV) during startup in zl...
Status: CLOSED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-27 10:27 UTC by Martin
Modified: 2011-12-23 15:38 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Segfault log (77.65 KB, text/plain)
2011-03-27 10:27 UTC, Martin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin 2011-03-27 10:27:42 UTC
Created attachment 44920 [details]
Segfault log

I can reliably trigger the bug on a 64bit version of slackware by calling libreoffice 3.3.1. It triggers a segfault caught by the Java VM according to the attached error log. Note: the bug does NOT occure when doing the same on the 32 bit version of slackware and libreoffice.

The beginning of the hs_err_*.log file:

---- insertion begin ----
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f29800b8e6b, pid=24173, tid=139816334833472
#
# JRE version: 6.0_23-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode linux-amd64 
compressed oops)
# Problematic frame:
# C  [libz.so.1+0x6e6b]  gzdirect+0xb
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread is native thread

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), 
si_addr=0x000000005c22c330

Registers:
RAX=0x0000000000000000, RBX=0x000000005c22c330, RCX=0x00007f295c000000, 
RDX=0xfffffffffff26763
RSP=0x00007fff4f1316d0, RBP=0x00007f2981285f90, RSI=0x00007f295c000768, 
RDI=0x000000005c22c330
R8 =0x00007f295c1546b8, R9 =0x00007f295c000088, R10=0x0000000000002002, 
R11=0x0000000000000001
R12=0x0000000000000001, R13=0x00007f2981285f80, R14=0x00007f295c152f00, 
R15=0x000000005c22c330
RIP=0x00007f29800b8e6b, EFL=0x0000000000010206, CSGSFS=0x0000000000000033, 
ERR=0x0000000000000004
  TRAPNO=0x000000000000000e
---- insertion end ----

The zlib binary according to GDB:

---- insertion begin ----
Dump of assembler code for function gzdirect:
   0x0000000000006e60 <+0>:     xor    %eax,%eax
   0x0000000000006e62 <+2>:     test   %rdi,%rdi
   0x0000000000006e65 <+5>:     push   %rbx
   0x0000000000006e66 <+6>:     mov    %rdi,%rbx
   0x0000000000006e69 <+9>:     je     0x6e73 <gzdirect+19>
   0x0000000000006e6b <+11>:    cmpl   $0x1c4f,(%rdi)
   0x0000000000006e71 <+17>:    je     0x6e78 <gzdirect+24>
   0x0000000000006e73 <+19>:    pop    %rbx
   0x0000000000006e74 <+20>:    retq   
   0x0000000000006e75 <+21>:    nopl   (%rax)
   0x0000000000006e78 <+24>:    mov    0x50(%rdi),%r8d
   0x0000000000006e7c <+28>:    test   %r8d,%r8d
   0x0000000000006e7f <+31>:    jne    0x6e88 <gzdirect+40>
   0x0000000000006e81 <+33>:    mov    0x38(%rdi),%edi
   0x0000000000006e84 <+36>:    test   %edi,%edi
   0x0000000000006e86 <+38>:    je     0x6e90 <gzdirect+48>
   0x0000000000006e88 <+40>:    mov    0x54(%rbx),%eax
   0x0000000000006e8b <+43>:    pop    %rbx
   0x0000000000006e8c <+44>:    retq   
---- insertion end ----

The code above has been compiled with -O2 -fPIC. The seg fault will also occur 
when I compile the zlib package with -O0 optimization.

The seg fault happens obviouslsy when evaluating state->mode in the source 
code:

---- insertion begin ----
int ZEXPORT gzdirect(file)
    gzFile file;
{
    gz_statep state;

    /* get internal structure */
    if (file == NULL)
        return 0;
    state = (gz_statep)file;

    /* check that we're reading */
    if (state->mode != GZ_READ)
        return 0;
---- insertion end ----

Looks like the function is called at runtime with an unsuitable parameter.
Comment 1 Martin 2011-03-27 10:32:23 UTC
as an additional piece of info, this is part of an strace log:

24105 stat("/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl", {st_mode=S_IFREG|0444, st_size=1180, ...}) = 0
24105 stat("/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl", {st_mode=S_IFREG|0444, st_size=1180, ...}) = 0
24105 stat("/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl", {st_mode=S_IFREG|0444, st_size=1180, ...}) = 0
24105 open("/usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl", O_RDONLY) = 53
24105 lseek(53, 0, SEEK_CUR)            = 0
24105 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Comment 2 Petr Mladek 2011-03-31 05:54:30 UTC
Many years ago, there were similar crashes caused by the fact that LO links against the system libz.so, it dlopens libjvm.so that is linked against JRE-specific libz. Though, it was fixed long time ago. All the symbols were renamed in the JRE-specifix libz.

I do not see any connection between the crash and the strace. /usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl is not a zip file, ...

I would suggest to try the very last JRE-6.0_24.

BTW: Where did you get LO-3.3.1 for Slackware? I am surprised that the backtrace points to /usr/lib64/libreoffice. The official LO linux packages are installed into /opt/libreoffice.
Comment 3 Martin 2011-03-31 13:03:08 UTC
(In reply to comment #2)
> I do not see any connection between the crash and the strace.
> /usr/lib64/libreoffice/basis3.3/help/idxcaption.xsl is not a zip file, ...

sure, strace only logs system calls. However, I noticed a certain vicinity of idxcaption.xsl and compression calls in the source code, so i thought it might be useful...

> 
> I would suggest to try the very last JRE-6.0_24.

You nailed it! After installing the new JRE the crash is gone! I shall close this ticket. Please re-open if anyone want to investigate further.

> 
> BTW: Where did you get LO-3.3.1 for Slackware? I am surprised that the
> backtrace points to /usr/lib64/libreoffice. The official LO linux packages are
> installed into /opt/libreoffice.

It's a package compiled from source by Eric Hameleers who goes by the nick of Alien Bob. He's quite a celebrity in the Slackware world. His blog can be found here: http://alien.slackbook.org/blog/
Comment 4 Petr Cerny [:hrosik] 2011-03-31 15:13:44 UTC
(In reply to comment #3)
> > BTW: Where did you get LO-3.3.1 for Slackware? I am surprised that the
> > backtrace points to /usr/lib64/libreoffice. The official LO linux packages are
> > installed into /opt/libreoffice.
> 
> It's a package compiled from source by Eric Hameleers who goes by the nick of
> Alien Bob. He's quite a celebrity in the Slackware world. His blog can be found
> here: http://alien.slackbook.org/blog/

With all due respect for Eric, building libreoffice from scratch is quite a task. I'd suggest using official LO builds (converted with rpm2txz) as these work reasonably well (on slackware(64)-current).
Comment 5 Martin 2011-04-20 10:59:50 UTC
Unfortunately the issue has re-appeared on one of my machines. I am fairly certain, after upgrading all machines to JRE 6.0_24-b07 and libreoffice 3.3.2 everything worked OK. 

However, when I was called for help today I found the zlib problem had re-appeared on one machine (same error as before).

Maybe someone has an idea?
Comment 6 Martin 2011-04-21 01:32:34 UTC
me again. I found that upgrading to the latest build of libxml2 would fix the seg fault. So I'm closing this issue again - hopefully for good.
Comment 7 Björn Michaelsen 2011-12-22 05:52:40 UTC
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.