openoffice.org-2.0.2.rc1 coredump - thread stack size porblem ?

Andriy Gapon avg at icyb.net.ua
Fri Mar 3 04:30:38 PST 2006


System:
FreeBSD 5.4-RELEASE i386
openoffice.org-2.0.2.rc1
cups-base-1.1.23.0_8

Sometime I am getting coredump (SIGSEGV) on OpenOffice startups even
when it is a pure openoffice.org program (no aliases, no parameters).
Here's a stack trace:

#0  0x4b46024c in ippWriteIO (dst=0x8337000, cb=0x4b45cbd0 <httpWrite>,
blocking=1, parent=0x0, ipp=0x8334ba0) at ipp.c:1418
#1  0x4b4601e6 in ippWrite (http=0x8337000, ipp=0x4b45cbd0) at ipp.c:1387
#2  0x4b46aa1f in cupsDoFileRequest (http=0x8337000, request=0x8334ba0,
resource=0x4b46d43f "/", filename=0x0) at util.c:288
#3  0x4b459c35 in cups_get_sdests (http=0x4b45cbd0, op=1262865360,
num_dests=0, dests=0xbfabdf70) at dest.c:778
#4  0x4b458f8a in cupsGetDests2 (http=0x8337000, dests=0xbfabdf70) at
dest.c:270
#5  0x4b458f0e in cupsGetDests (dests=0x4b45cbd0) at dest.c:223
#6  0x498caf99 in psp::CUPSManager::runDests () from
/usr/local/openoffice.org-2.0.2.rc1/program/libpsp680fi.so
#7  0x498caff1 in psp::CUPSManager::runDestThread () from
/usr/local/openoffice.org-2.0.2.rc1/program/libpsp680fi.so
#8  0x48ab1875 in osl_yieldThread () from
/usr/local/openoffice.org-2.0.2.rc1/program/libuno_sal.so.3
#9  0x48fd60bb in pthread_create () from /usr/lib/libpthread.so.1
#10 0x4909f55f in _ctx_start () from /lib/libc.so.5

As you can see the coredump occurs in libcups.so.2 (this time it is
hand-built with debug and without any optimizations).

Here's some disassembling:
(gdb) disas
Dump of assembler code for function ippWriteIO:
0x4b460240 <ippWriteIO+0>:      push   %ebp
0x4b460241 <ippWriteIO+1>:      mov    %esp,%ebp
0x4b460243 <ippWriteIO+3>:      push   %edi
0x4b460244 <ippWriteIO+4>:      push   %esi
0x4b460245 <ippWriteIO+5>:      push   %ebx
0x4b460246 <ippWriteIO+6>:      sub    $0x805c,%esp
0x4b46024c <ippWriteIO+12>:     call   0x4b45859c <__i686.get_pc_thunk.bx>
...

(gdb) disas 0x4b45859c
Dump of assembler code for function __i686.get_pc_thunk.bx:
0x4b45859c <__i686.get_pc_thunk.bx+0>:  mov    (%esp),%ebx
0x4b45859f <__i686.get_pc_thunk.bx+3>:  ret

(gdb) i reg
eax            0x4b45cbd0       1262865360
ecx            0xf6     246
edx            0x8337000        137588736
ebx            0x4b471240       1262948928
esp            0xbfaad06c       0xbfaad06c
ebp            0xbfab50d4       0xbfab50d4
esi            0x833a000        137601024
edi            0x8337000        137588736
eip            0x4b46024c       0x4b46024c
eflags         0x10396  66454
...

And a short snippet from ippWriteIO() function:
1418    {
1419      int                   i;                      /* Looping var */
1420      int                   n;                      /* Length of data */
1421      unsigned char         buffer[32768],          /* Data buffer */


I think that the problem is that this buffer[32768] causes stack
overflow in this place. It looks like OpenOffice creates this thread
with default stack size and default stack is something like 64k and this
is not enough for libcups.

I am not sure where and how to properly report this.

Is there any way on FreeBSD 5.4 to set system-wide default stack size ?


-- 
Andriy Gapon


More information about the freebsd-openoffice mailing list