CC tools-linking...
> it seems that the 15 second pause is while soffice.bin dumps core.
...
> serengeti> pstack core
> core 'core' of 101697: /opt/staroffice8/program/soffice.bin slot:5500
> ----------------- lwp# 1 / thread# 1 --------------------
> fefc9334 load_finish (feffa2dc, f65f0610, fa960678, d01, 0, 0) + 214
> fefc970c _load_path (feffa2dc, 1c, f65f06f0, fa960678, d01, 0) + 1e0
> fefc99f7 load_path (feffa2dc, 1c, f65f06f0, fa960678, d01, 0) + 203
> fefc9aae load_one (feffa2dc, 1c, f65f06f0, fa960678, d01, 0) + ae
> fefcaad9 elf_lazy_load (fa960678, 9, fce7ccf5) + 125
> fefce311 elf_lazy_find_sym (8046d60, 8046efc, 8046e54) + f9
> fefca051 _lazy_find_sym (feffcb88, 8046d60, 8046efc, 8046e54) + 5d
> fefca384 _lookup_sym (8046e10, 8046efc, 8046e54) + 31c
> fefca4dd lookup_sym (8046e10, 8046efc, 8046e54) + f9
> fefd7242 dlsym_core (fffffffe, fce7ccf5, fced0bb0, 8046efc) + 1ea
> fefd7480 dlsym_intn (fffffffe, fce7ccf5, fced0bb0, 8046efc) + 90
> fefd7542 dlsym_check (fffffffe, fce7ccf5, fced0bb0, 8046efc) + 6e
> fefd75b2 dlsym (fffffffe, fce7ccf5) + 46
> fce56cc9 __1cPDeInitAtkBridge6F_v_ (fce918d8, 8046f34, fce55161, 80c2f58,
> 80c2f58, fe2f651c) + 23
> fce54e2a ???????? (80c2f58)
> fce55161 ???????? (80c2f58, 1)
> fe2beced ???????? (80c2f58)
> fe09d9bb __1cJDeInitVCL6F_v_ (8047050, 8046fc8, fe2f651c, 0,
> 8046fa4,fefc6f24) + 544
> fe09cd8d ???????? (80afff0, feffcb88, 8047008, 8066b47, 8047050, 2)
> fe09ce0f __1cGSVMain6F_C_ (8047050, 2, 80afff0, 10000, 10000, 80c15e0) + 2e
> 08066b47 ???????? (2, 8047050)
> 08066ad1 main (2, 8047050, 804705c) + 29
> 08066a12 ???????? (2, 80471a4, 80471c9, 0, 80471d3, 804720d)
Yep, I can confirm this. I'm seeing frequent soffice.bin crashes
with SIGSEGV core dumps, when StarOffice exits.
In my case it's snv_72, bfu'ed to current opensolaris bits (~ snv_77).
According to old core dump log entries in /var/adm/messages these
core dumps started around October, 12th.
On October 10th, there has been some big putback for the linker:
PSARC/2007/559 new symbol visibilities - EXPORTED, SINGLETON, and ELIMINATE
6602451 new symbol visibilities required: EXPORTED, SINGLETON and ELIMINATE
I suspect that this change might cause the core dumps, but
I haven't verified this. This change seems to be part of snv_76.
Here's a stack trace that I get, and it looks very similar:
# pflags /cores/soffice.bin-1659
core '/cores/soffice.bin-1659' of 1659: /opt/staroffice8/program/soffice.bin
data model = _ILP32 flags = MSACCT|MSFORK
/1: flags = 0
sigmask = 0xffffbefc,0x0000ffff cursig = SIGSEGV
/2: flags = STOPPED lwp_park(0x0,0xfd27df18,0x0)
why = PR_SUSPENDED
/3: flags = STOPPED lwp_park(0x0,0xf81fde98,0x0)
why = PR_SUSPENDED
# pstack /cores/soffice.bin-1659
core '/cores/soffice.bin-1659' of 1659: /opt/staroffice8/program/soffice.bin
----------------- lwp# 1 / thread# 1 --------------------
fefe4024 memcpy (f9440fe8, 8046948, 8, a, 0) + 14
fefc791a alist_append (f9440fe8, 8046948, 8, a) + 26
fefd6b0e hdl_add (f9440fe8, fecc0780, 7) + 8a
fefca0cb load_finish (feffa2dc, f8c20e20, f9390678, d01, 0, 0) + 25b
fefca45c _load_path (feffa2dc, 1c, f8c20e50, f9390678, d01, 0) + 1e0
fefca747 load_path (feffa2dc, 1c, f8c20e50, f9390678, d01, 0) + 203
fefca7fe load_one (feffa2dc, 1c, f8c20e50, f9390678, d01, 0) + ae
fefcb829 elf_lazy_load (f9390678, 9, fce4ccf5) + 125
fefcf00d elf_lazy_find_sym (8046c20, 8046dbc, 8046d14) + f9
fefcada1 _lazy_find_sym (feffcb98, 8046c20, 8046dbc, 8046d14) + 5d
fefcb0d4 _lookup_sym (8046cd0, 8046dbc, 8046d14) + 31c
fefcb22d lookup_sym (8046cd0, 8046dbc, 8046d14) + f9
fefd7db2 dlsym_core (fffffffe, fce4ccf5, fce80210, 8046dbc) + 1ea
fefd7ff0 dlsym_intn (fffffffe, fce4ccf5, fce80210, 8046dbc) + 90
fefd80b2 dlsym_check (fffffffe, fce4ccf5, fce80210, 8046dbc) + 6e
fefd8122 dlsym (fffffffe, fce4ccf5) + 46
fce26cc9 __1cPDeInitAtkBridge6F_v_ (fce618d8, 8046df4, fce25161, 80c2f80,
80c2f80, fe2f651c) + 23
fce24e2a ???????? (80c2f80)
fce25161 ???????? (80c2f80, 1)
fe2beced ???????? (80c2f80)
fe09d9bb __1cJDeInitVCL6F_v_ (8046f10, 8046e88, fe2f651c, 0, 8046e64,
fefc7c74) + 544
fe09cd8d ???????? (80afff0, feffcb98, 8046ec8, 8066b47, 8046f10, 2)
fe09ce0f __1cGSVMain6F_C_ (8046f10, 2, 80afff0, 10000, 10000, 80c15e0) + 2e
08066b47 ???????? (2, 8046f10)
08066ad1 main (2, 8046f10, 8046f1c) + 29
08066a12 ???????? (2, 80470b8, 80470dd, 0, 80470ec, 8047134)
----------------- lwp# 2 / thread# 2 --------------------
feecefdb __lwp_park (fd529be0, fd529a80, fd27df18) + b
feec90f6 cond_wait_queue (fd529be0, fd529a80, fd27df18, 0) + 41
feec9484 cond_wait_common (fd529be0, fd529a80, fd27df18) + 1e1
feec96aa _cond_timedwait (fd529be0, fd529a80, fd27dfa0) + 4a
feec9739 cond_timedwait (fd529be0, fd529a80, fd27dfa0) + 27
feec9776 pthread_cond_timedwait (fd529be0, fd529a80, fd27dfa0) + 21
fd3875bf ???????? (a)
fd38775c ???????? (a)
feeced42 _thr_setup (fd160200) + 52
feecefa0 _lwp_start (fd160200, 0, 0, 0, 0, 0)
----------------- lwp# 3 / thread# 3 --------------------
feecefdb __lwp_park (8166390, 81663a0, f81fde98) + b
feec90f6 cond_wait_queue (8166390, 81663a0, f81fde98, 0) + 41
feec9484 cond_wait_common (8166390, 81663a0, f81fde98) + 1e1
feec96aa _cond_timedwait (8166390, 81663a0, f81fdf18) + 4a
feec9739 cond_timedwait (8166390, 81663a0, f81fdf18) + 27
feec9776 pthread_cond_timedwait (8166390, 81663a0, f81fdf18) + 21
fd3769d9 osl_waitCondition (8166390, f81fdf60) + a3
fede0620 __1cDvosKOConditionEwait6MpknJTimeValue__n0AKIConditionHTResult__
(f87d7964, f81fdf60) + 1e
fede6491 __1cDvosNOTimerManagerDrun6M_v_ (f87d7940) + a8
fede42bf __1cDvosZthreadWorkerFunction_impl6Gpv_v_ (f87d7940) + 1b
fd379d68 ???????? (816d448)
feeced42 _thr_setup (fd160a00) + 52
feecefa0 _lwp_start (fd160a00, 0, 0, 0, 0, 0)
This message posted from opensolaris.org
_______________________________________________
opensolaris-help mailing list
[email protected]
