Re: [dev] Dev builds m92 and m93 core dumps

2010-11-16 Thread Stephan Bergmann

On 11/16/10 17:06, Paul Gress wrote:

My platform OS - Solaris Express 11 (b151a)
Hardware - HP Z800 Dual 5590 processors, 24 gig ram

When I start OOO exactly 55 seconds later I get a core dump, leaving the
program alone, non-interactive, it happens by itself. The core dumps
started with m92 on Opensolaris b134. I upgraded today to Solaris
Express 11 and installed m93 and still the same core dump.


pstack on core file"


bash-4.0$ pstack core
core 'core' of 1711: /opt/ooo-dev3/program/soffice.bin -writer
- lwp# 12 / thread# 12 
f8cb69ed xmlFreeNodeList (90ca948, 0) + 9d
f8cb2931 xmlFreeDoc (9295640, fef7, ef6de7c8, f0073906) + 161
f0073921  (efa4d6f0, fec564b4, ef6de7e8, f007a4d0)
f007a4e2  (efa4d6f0, 1, ef6de838, fe499332)
fe499377 __1cEcppuLOWeakObjectHrelease6M_v_ (efa4d6f0, ef439d40,
f002d8dc, f007d3fc) + 53
f007d40e  (efa4d6f0, fab91834, ef6de8a8, f0090752)
f00907cf  (efa7e8d4, fab91834, ef6de8d8, f008af40)
f008af52  (efa7e8d4, 1, ef6de8f8, fe499332)
fe499377 __1cEcppuLOWeakObjectHrelease6M_v_ (efa7e8d4, 11, ef43ce16,
f008be84) + 53
f008be96  (efa7e8d4, ef6de968, 85fb6e8, ef439d40)
ef43a6a1  (ef6de9f0, efa703e0, ef6deacc, ef6dead0)
ef43776c  (ef6deac8, ef896c0c, ef6deacc, ef6dead0)
f724d759  (ef6deac8, efa6d684, ef6deacc, ef6dead0, ef6deb00, 0)
f724e391  (efa6d680, efa6d684, ef6deba0, ef6ded20)
f724f948
__1cHdp_miscUgetOnlineUpdateInfos6FrknDcomDsunEstarDunoJReference4n0ERXComponentContext___rkn0EJReference4n0DKdeploymentRXExtensionManager___rkn0EJReference4n0HbAXUpdateInformationProvider___pknE_STLGvector4n0EJReference4n0HIXPackage___n0MJalloc


"ExtensionManager" and "UpdateInformationProvider" -> indeed appears to 
be a problem with the thread that polls for extension updates, as 
already suggested by Mathias.  Dirk (on cc) might know more.


-Stephan


(ef6ded60, efa6d680, ef6dec90, efa6d684, 0, ef6ded20) + 600
f040505a  (ef6dedc8, efa6d660, ef6dedcc, efe4cf8a)
efe4d108  (efa7d0f4, efa7d0f4, ef6dee48, ef6dee54)
efe38b72  (efa7d0dc, ef6deef7, ef6def14, efe38f45)
efe3911c  (efa7d0dc)
efe41619  (efa7d0dc, ef6defa0, ef6defc8, ef6defa0)
fec0ac87  (85dc2c8, fef7, ef6defe8, feeed61e)
feeed673 _thrp_setup (fea33a40) + 9b
feeed920 _lwp_start (fea33a40, 0, 0, 0, 0, 0)


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org



Re: [dev] Dev builds m92 and m93 core dumps

2010-11-16 Thread Paul Gress

On 11/16/10 04:08 AM, Mathias Bauer wrote:

On 11/16/2010 12:01 AM, Paul Gress wrote:

Hi all,

My platform OS - Solaris Express 11 (b151a)
Hardware - HP Z800 Dual 5590 processors, 24 gig ram

When I start OOO exactly 55 seconds later I get a core dump, leaving the
program alone, non-interactive, it happens by itself. The core dumps
started with m92 on Opensolaris b134. I upgraded today to Solaris
Express 11 and installed m93 and still the same core dump.


Just a wild guess (the exactly timed crash makes we wonder): do you have 
auto-update notification enabled? If yes, maybe it helps to deactivate it and 
immediately shut down OOo and restart.




You hit the nail on the head.  I turned off "check for updates automatically", 
it doesn't crash any more.

Thanks,

Paul


Re: [dev] Dev builds m92 and m93 core dumps

2010-11-16 Thread Paul Gress

On 11/16/10 04:55 AM, Joost Andrae wrote:

Hi,

could you please generate a callstack ? You could use the command 'pstack' to 
generate it from the core file.


My platform OS - Solaris Express 11 (b151a)
Hardware - HP Z800 Dual 5590 processors, 24 gig ram

When I start OOO exactly 55 seconds later I get a core dump, leaving the
program alone, non-interactive, it happens by itself. The core dumps
started with m92 on Opensolaris b134. I upgraded today to Solaris
Express 11 and installed m93 and still the same core dump.




OK, this is a different core file, it appears Adobe Flash crashed last night 
and over written the OOO core file.  But is was easy to recreate.

Thanks for any help.

Paul

End of "truss" command:

1711/12:Incurred fault #6, FLTBOUNDS  %pc = 0xF8CB69ED
1711/12:  siginfo: SIGSEGV SEGV_MAPERR addr=0x0058
1711/12:Received signal #11, SIGSEGV [default]
1711/12:  siginfo: SIGSEGV SEGV_MAPERR addr=0x0058
1704:Received signal #18, SIGCLD, in waitid() [caught]
1704:  siginfo: SIGCLD CLD_DUMPED pid=1711 status=0x000B
1704:waitid(P_ALL, 0, 0x08046FB0, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) 
Err#4 EINTR
1704:lwp_sigmask(SIG_SETMASK, 0x0002, 0x, 0x, 
0x) = 0xFFBFFEFF [0x]
1704:setcontext(0x08046AA0)
1704:waitid(P_ALL, 0, 0x08046FB0, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) = 0
1704:waitid(P_ALL, 0, 0x08046FB0, 
WEXITED|WTRAPPED|WSTOPPED|WCONTINUED|WNOHANG) Err#10 ECHILD
1704:write(2, " / o p t / o o o - d e v".., 71)= 71
1704:waitid(P_ALL, 0, 0x08046FB0, 
WEXITED|WTRAPPED|WSTOPPED|WCONTINUED|WNOHANG) Err#10 ECHILD
1704:sigaction(SIGCLD, 0x08046F80, 0x08047000)= 0
1704:ioctl(2, TIOCGSID, 0x0804705C)= 0
1704:getsid(0)= 1686
1704:ioctl(2, TIOCGPGRP, 0x0804708C)= 0
1704:read(10, 0x080746A8, 8192)= 0
1704:fcntl(10, F_GETFL)= 8192
1704:fstat64(1, 0x080476A8)= 0
1704:fstat64(2, 0x080476A8)= 0
1704:_exit(11)



pstack on core file"


bash-4.0$ pstack core
core 'core' of 1711:/opt/ooo-dev3/program/soffice.bin -writer
-  lwp# 1 / thread# 1  
 feef2455 __pollsys (85f6098, 7, 8047308, 0, fee12a40, fef7) + 15
 fee96e06 poll (85f6098, 7, 10a, fb8c81c8, 808c274) + 4c
 fb8c81e0 g_poll   (85f6098, 7, 10a, fb8b9d66) + 24
 fb8ba19b g_main_context_iterate (808c270, 1, 1, 8064ea8) + 443
 fb8ba415 g_main_context_iteration (0, 1, 82fc2ff, fbb9c13e) + 81
 fbb9c1e5  (8066f80, 1, 0, fb8218a4)
 fb8218cd __1cOX11SalInstanceFYield6Mbb_v_ (8061f18, 1, 0, fccd9fd6) + 35
 fccda039 __1cLApplicationFYield6Fb_v_ (0, feb926f4, 0, fccd9ed6) + 71
 fccd9eff __1cLApplicationHExecute6F_v_ (fe6c0118, 80474a0, fe601ab8, fe601af4, 
80fc830, 1) + 33
 fe56aef3  (80478b0, 15a, 9d5c28f, fcce1af6)
 fcce1b3f  (fe5a1f7e, fec59608, feb9b530, 1, 8047908)
 fcce1d01 __1cGSVMain6F_C_ (fefa06b0, 65, e11fb0e, 8047890, 80504e4, fe5e4518) 
+ 31
 fe5a1f7e soffice_main (2) + ae
 08050b28  (8047914, feffb8f4, 804794c, 8050a4d, 2, 8047958)
 08050b03 main (2, 8047958, 8047964, 8050a0d) + 27
 08050a4d _start   (2, 8047a80, 8047aa2, 0, 8047aaa, 8047ad4) + 7d
-  lwp# 2 / thread# 2  
 feeed979 __lwp_park (fedc59e8, fedc5888) + 19
 feee6f4d cond_wait_queue (fedc59e8, fedc5888, feb3eef8, feee7196) + 60
 feee7373 cond_wait_common (fedc59e8, fedc5888, feb3eef8, feee75b6) + 1eb
 feee760e __cond_timedwait (fedc59e8, fedc5888, feb3ef78, feee76a0) + 66
 feee76b1 cond_timedwait (fedc59e8, fedc5888, feb3ef78, feee76e4) + 27
 feee76fc pthread_cond_timedwait (fedc59e8, fedc5888, feb3ef78, fec384a1) + 24
 fec384ec  (a, fee12000, 208, fec3867a)
 fec386c5  (a, fef7, feb3efe8, feeed61e)
 feeed673 _thrp_setup (fea30240) + 9b
 feeed920 _lwp_start (fea30240, 0, 0, 0, 0, 0)
-  lwp# 4 / thread# 4  
 feef1b15 __so_accept (9, 0, 0, 1, f982f548) + 15
 faebc9cf accept   (9, 0, 0, fec118f6) + 23
 fec11912 osl_acceptPipe (85402e8, 854071c) + 2a
 fe69abbe __1cDvosFOPipeGaccept6Mrn0ALOStreamPipe__n0BKTPipeError__ (f9967c8c, 
f9967ca0, 0, fe59daa1) + 36
 fe59dbc4  (f9967c78, 8540710, f982ffc8, fe6955c4)
 fe6955d9 __1cDvosZthreadWorkerFunction_impl6Gpv_v_ (f9967c78, f982ffa0, 
f982ffc8, f982ffa0) + 21
 fec0ac87  (8540700, fef7, f982ffe8, feeed61e)
 feeed673 _thrp_setup (fea31a40) + 9b
 feeed920 _lwp_start (fea31a40, 0, 0, 0, 0, 0)
-  lwp# 5 / thread# 5  
 feef2455 __pollsys (f9961ce8, 2, 0, 0, 8548268, f9961ce8) + 15
 fee96e06 poll (f9961ce8, 2, , fb824fe4) + 4c
 fb824ff2  (0, f84defa0, f84defc8, f84defa0)
 fec0ac87  (854df68, fef7, f84defe8, feeed61e)
 feeed673 _thrp_setup (fea32240) + 9b
 feeed920 _lwp_start (fea32240, 0, 0, 0, 0, 0)
-  lwp# 6 / thread# 6  

Re: [dev] Dev builds m92 and m93 core dumps

2010-11-16 Thread Joost Andrae

Hi,

could you please generate a callstack ? You could use the command 
'pstack' to generate it from the core file.



My platform OS - Solaris Express 11 (b151a)
Hardware - HP Z800 Dual 5590 processors, 24 gig ram

When I start OOO exactly 55 seconds later I get a core dump, leaving the
program alone, non-interactive, it happens by itself. The core dumps
started with m92 on Opensolaris b134. I upgraded today to Solaris
Express 11 and installed m93 and still the same core dump.


Kind regards, Joost

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org



Re: [dev] Dev builds m92 and m93 core dumps

2010-11-16 Thread Mathias Bauer

On 11/16/2010 12:01 AM, Paul Gress wrote:

Hi all,

My platform OS - Solaris Express 11 (b151a)
Hardware - HP Z800 Dual 5590 processors, 24 gig ram

When I start OOO exactly 55 seconds later I get a core dump, leaving the
program alone, non-interactive, it happens by itself. The core dumps
started with m92 on Opensolaris b134. I upgraded today to Solaris
Express 11 and installed m93 and still the same core dump.


Just a wild guess (the exactly timed crash makes we wonder): do you have 
auto-update notification enabled? If yes, maybe it helps to deactivate 
it and immediately shut down OOo and restart.


Regards,
Mathias

--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org



Re: [dev] Dev builds m92 and m93 core dumps

2010-11-15 Thread Stephan Bergmann

On 11/16/10 00:10, Paul Gress wrote:

On 11/15/10 06:01 PM, Paul Gress wrote:
I should of at least attached the relevant text of the core dump:

8611/12: Incurred fault #6, FLTBOUNDS %pc = 0xF8C869ED
8611/12: siginfo: SIGSEGV SEGV_MAPERR addr=0x0058
8611/12: Received signal #11, SIGSEGV [default]
8611/12: siginfo: SIGSEGV SEGV_MAPERR addr=0x0058


This truss output shows that soffice.bin crashed due to a SEGV.  What 
would be needed to track this down is a stack trace obtained from the 
generated core file.


-Stephan

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org



Re: [dev] Dev builds m92 and m93 core dumps

2010-11-15 Thread Paul Gress

On 11/15/10 06:01 PM, Paul Gress wrote:

Hi all,

My platform OS - Solaris Express 11 (b151a)
Hardware - HP Z800 Dual 5590 processors, 24 gig ram

When I start OOO exactly 55 seconds later I get a core dump, leaving the 
program alone, non-interactive, it happens by itself.  The core dumps started 
with m92 on Opensolaris b134.  I upgraded today to Solaris Express 11 and 
installed m93 and still the same core dump.

I've entered the command:

bash-4.0$ truss -f -o /export/home/Rad/ooo.err.txt /opt/ooo-dev3/program/swriter
/opt/ooo-dev3/program/soffice[119]: wait: 8611: Memory fault(coredump)
bash-4.0$

I have compressed ooo.err.txt to approximately 120 kb.

I would be happy to attach it if anybody is interested, or unless someone knows 
what is bothering OOO.

As a workaround I've reinstalled m91, no problems, just a slow startup.




I should of at least attached the relevant text of the core dump:

8611/12:Incurred fault #6, FLTBOUNDS  %pc = 0xF8C869ED
8611/12:  siginfo: SIGSEGV SEGV_MAPERR addr=0x0058
8611/12:Received signal #11, SIGSEGV [default]
8611/12:  siginfo: SIGSEGV SEGV_MAPERR addr=0x0058
8604:Received signal #18, SIGCLD, in waitid() [caught]
8604:  siginfo: SIGCLD CLD_DUMPED pid=8611 status=0x000B
8604:waitid(P_ALL, 0, 0x08046FB0, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) 
Err#4 EINTR
8604:lwp_sigmask(SIG_SETMASK, 0x0002, 0x, 0x, 
0x) = 0xFFBFFEFF [0x]
8604:setcontext(0x08046AA0)
8604:waitid(P_ALL, 0, 0x08046FB0, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) = 0
8604:waitid(P_ALL, 0, 0x08046FB0, 
WEXITED|WTRAPPED|WSTOPPED|WCONTINUED|WNOHANG) Err#10 ECHILD
8604:write(2, " / o p t / o o o - d e v".., 71)= 71
8604:waitid(P_ALL, 0, 0x08046FB0, 
WEXITED|WTRAPPED|WSTOPPED|WCONTINUED|WNOHANG) Err#10 ECHILD
8604:sigaction(SIGCLD, 0x08046F80, 0x08047000)= 0
8604:ioctl(2, TIOCGSID, 0x0804705C)= 0
8604:getsid(0)= 8573
8604:ioctl(2, TIOCGPGRP, 0x0804708C)= 0
8604:read(10, 0x080746A8, 8192)= 0
8604:fcntl(10, F_GETFL)= 8192
8604:fstat64(1, 0x080476A8)= 0
8604:fstat64(2, 0x080476A8)= 0
8604:_exit(11)


Paul