Issue 111166 - unexpected exception from InitUpdateCheckJobThread during shut down
Summary: unexpected exception from InitUpdateCheckJobThread during shut down
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: DEV300m77
Hardware: All All
: P2 Trivial (vote)
Target Milestone: 3.4.0
Assignee: Stephan Bergmann
QA Contact: issues@framework
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-26 14:55 UTC by Stephan Bergmann
Modified: 2010-08-09 15:14 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Stephan Bergmann 2010-04-26 14:55:06 UTC
At least on DEV300_m77-based CWS sb120 (mainly making changes to the testing
framework), executing the configmgr/qa/unoapi tests at least under unxlngi6
non-pro once crashed at the below point with the below stack.

1: Failures that appeared during scenario execution:
1: 0 of 2 tests failed
1: Job run took: 6127ms  [00:00:06]
1: Job -sce module.sce done
1: terminate called after throwing an instance of
'com::sun::star::uno::RuntimeException'

#3  0x96ef868a in abort ()
#4  0x92ee5005 in _CUICopyIconURL ()
#5  0x92ee310c in _CUICopyIconURL ()
#6  0x92ee314b in _CUICopyIconURL ()
#7  0x92ee32b1 in _CUICopyIconURL ()
#8  0x18bb27cb in
dp_registry::backend::bundle::ExtensionDescription::ExtensionDescription ()
#9  0x18ba8dbc in dp_registry::backend::bundle::(anonymous
namespace)::BackendImpl::PackageImpl::getDescriptionInfoset ()
#10 0x18ba91ba in dp_registry::backend::bundle::(anonymous
namespace)::BackendImpl::PackageImpl::getIdentifier ()
#11 0x18c94b35 in dp_misc::getIdentifier ()
#12 0x18b83303 in dp_info::PackageInformationProvider::getExtensionList ()
#13 0x18b84d47 in dp_info::PackageInformationProvider::getExtensionList ()
#14 0x2640c77d in checkForPendingUpdates ()
#15 0x26404b8f in UpdateCheck::initialize ()
#16 0x2640613d in (anonymous namespace)::InitUpdateCheckJobThread::run ()
#17 0x26425a46 in threadFunc ()
#18 0x001fd5b7 in osl_thread_start_Impl ()
#19 0x96e3d155 in _pthread_start ()
#20 0x96e3d012 in thread_start ()

where the _CUICopyIconURL frames are inside libstdc++ (so this is probably
throwing the RuntimeException leading to terminate/abort), and the main thread
is just into DeInitVCL (not yet in DestroyApplicationServiceManager).
Comment 1 Stephan Bergmann 2010-07-12 13:04:35 UTC
A similar crash on DEV300_m84 based CWS sb126 unxsoli4 non-pro:

(dbx) threads
      t@1  a  l@1   ?()   LWP suspended in  mutex_unlock_queue()
      t@2  a  l@2   rtl_cache_wsupdate_all()   sleep on 0xfee3f6b0  in  __lwp_park()
      t@6  a  l@6   osl_thread_start_Impl()   LWP suspended in  ___nanosleep()
o>    t@7  a  l@7   osl_thread_start_Impl()   signal SIGSEGV in 
rtl_uString_new_WithLength()
     t@39  a l@39   osl_thread_start_Impl()   sleep on 0x8805ce0  in  __lwp_park()
(dbx) where t@7
current thread: t@7
=>[1] rtl_uString_new_WithLength(0xf162d5c8, 0x10, 0x0, 0xfeca1a7d), at 0xfec98fd9
  [2] __unnamed_KARQ_RTeNMGcj::expandMacros(0xf162da3c, 0xfec06140, 0xf162dae4,
0x0, 0x0, 0xfeccfd64, 0xf162da58, 0xfeca162a), at 0xfeca1ab6
  [3] rtl_bootstrap_expandMacros_from_handle(0x0, 0xf162dae4, 0xf162dae4,
0xfeca1694), at 0xfeca1643
  [4] rtl_bootstrap_expandMacros(0xf162dae4, 0xfecbdb80), at 0xfeca16a8
  [5] ReportCrash(0xb, 0x1, 0xfefa18c0, 0xfec8353d), at 0xfec8319f
  [6] SignalHandlerFunction(0xb, 0x0, 0xf162ea90), at 0xfec8359c
  [7] __sighndlr(0xb, 0x0, 0xf162ea90, 0xfec83530), at 0xfef275af
  [8] call_user_handler(0xb, 0x0, 0xf162ea90), at 0xfef1d290
  [9] sigacthandler(0xb, 0x0, 0xf162ea90, 0xf, 0x0, 0x0), at 0xfef1d3ba
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [10] UpdateCheckConfig::get(0xf162eda8, 0xf17e3054, 0xf162edac, 0xf1687678),
at 0xf1696fd2
  [11] checkForPendingUpdates(0xf17e3054, 0xf2058030, 0xfefc0210, 0xf168a70d),
at 0xf169e1d2
  [12] UpdateCheck::initialize(0xf2058008, 0xf17e3058, 0xf17e3054, 0xf1692fc9),
at 0xf168a88d
  [13] __unnamed_KARQ_zfhNMmom::InitUpdateCheckJobThread::run(0xf17e3048), at
0xf1693088
  [14] threadFunc(0xf17e3048, 0xf162efb0, 0xf162efd8, 0xf162efb0), at 0xf169220d
  [15] osl_thread_start_Impl(0x8805d18), at 0xfec7ba4f
  [16] _thr_setup(0xfeab3200), at 0xfef271c0
  [17] _lwp_start(0x1, 0x0, 0xf162e0f0, 0xf162e130, 0xfeccfd64, 0xf162da08), at
0xfef274b0
(dbx) where t@1
current thread: t@1
=>[1] mutex_unlock_queue(0xfec01348, 0x0), at 0xfef200d1
  [2] __mutex_unlock(0xfec01348, 0x0, 0xfee3f7b0, 0xfecac6ba), at 0xfef21265
  [3] rtl_cache_slab_free(0xfec01300, 0xf6c42a04, 0x80453f4, 0xfecac862), at
0xfecac7c0
  [4] rtl_cache_magazine_clear(0xfec01300, 0xefc27314), at 0xfecac89d
  [5] rtl_cache_deactivate(0xfec01300), at 0xfecad20b
  [6] rtl_cache_destroy(0xfec01300, 0x0, 0x2000, 0xfecabb3a), at 0xfecad547
  [7] rtl_memory_fini(0xfeffb818, 0xf37906e0, 0xfefc0210, 0x80454b8, 0xfefd4de1,
0xfeffdd98), at 0xfecabba4
  [8] _fini(0xfeffdd98, 0xfeffb28c, 0xfeffb818, 0x0, 0xfecb758c, 0x80454d4), at
0xfecb75df
  [9] call_fini(0xfeffb28c, 0xf3790518), at 0xfefd4de1
  [10] atexit_fini(0x80457fc, 0x80454d8, 0xfef9d000, 0xfefa2e40, 0x8045510,
0xfeea4d02), at 0xfefd4f70
  [11] _exithandle(0xfeffb818, 0x8050a56, 0x0, 0x8050a0d, 0x80509c0, 0x8050bf0),
at 0xfeeb2461
  [12] exit(0x8, 0x8045864, 0x80458cc, 0x80458db, 0x80458ef, 0x80458fa), at
0xfeea4d02
Comment 2 Stephan Bergmann 2010-07-14 15:59:21 UTC
raising prio, as this affects build stability (see
<http://tools.openoffice.org/servlets/ReadMsg?list=tinderbox&msgNo=398> for
enabling subsequenttests on buildbots)
Comment 3 dirk.voelzke 2010-07-22 09:19:05 UTC
Fixed in cws dv19 in extensions/source/update/check/updatecheckjob.cxx
Comment 4 Stephan Bergmann 2010-07-23 08:45:44 UTC
@dv: fix will need additional patch (cf.
<http://hg.services.openoffice.org/cws/sb127/rev/2273180ad99f>) to silence
compiler warning
Comment 5 dirk.voelzke 2010-07-26 12:17:29 UTC
Please verify.
Comment 6 dirk.voelzke 2010-07-26 12:22:18 UTC
Please verify.
Comment 7 Stephan Bergmann 2010-07-28 10:42:17 UTC
tested the fix on my buildbot-subsequenttests-enabling CWS sb127 for a while now
and looks good there
Comment 8 Stephan Bergmann 2010-08-09 15:14:06 UTC
.