[JBoss JIRA] (JBTM-1743) Added JAVA_HOME note to Readme
by Mark Little (JIRA)
Mark Little created JBTM-1743:
---------------------------------
Summary: Added JAVA_HOME note to Readme
Key: JBTM-1743
URL: https://issues.jboss.org/browse/JBTM-1743
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Build System
Affects Versions: 5.0.0.M3
Reporter: Mark Little
Assignee: Mark Little
Priority: Minor
Fix For: 5.0.0.M4
When building on Mac OS 10 it appears that JAVA_HOME must be set with the current build system. Add that note to the readme.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1742) Tidy up the JTS IDL
by Mark Little (JIRA)
Mark Little created JBTM-1742:
---------------------------------
Summary: Tidy up the JTS IDL
Key: JBTM-1742
URL: https://issues.jboss.org/browse/JBTM-1742
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: JTS
Affects Versions: 5.0.0.M3
Reporter: Mark Little
Assignee: Mark Little
The IDL hasn't been updated for over a decade and has preprocessor directives in there that are probably no longer needed, unless we want to be backwardly compatible for ORBs that are no longer produced.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1147:
--------------------------------
Original Estimate: (was: 3 days)
Remaining Estimate: (was: 3 days)
> Refactor ParticipantCompletion recovery tests to remove duplicate rules
> -----------------------------------------------------------------------
>
> Key: JBTM-1147
> URL: https://issues.jboss.org/browse/JBTM-1147
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Ondřej Chaloupka
> Priority: Minor
> Fix For: 5.0.0.M4
>
>
> The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example:
> The following rules in BACrashDuringCommit could be refactored into a single rule
> {code}
> #####################################################################
> # Setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> These can be re-factored in to a rule like this:
> {code}
> RULE setup counter
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT ENTRY
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> This assumes that we have the same numbers for each use of:
> {code}
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> {code}
> Which is *usually* the case:
> {code}
> grep -r createCounter\(\"closes\" .
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> {code}
> Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated.
> Also, the following similar rules are also present in this file:
> {code}
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> Which could be replaced with something like this:
> {code}
> RULE wait for closes
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Paul Robinson resolved JBTM-1147.
---------------------------------
Resolution: Deferred
Deferring until we next need to work with these scripts.
> Refactor ParticipantCompletion recovery tests to remove duplicate rules
> -----------------------------------------------------------------------
>
> Key: JBTM-1147
> URL: https://issues.jboss.org/browse/JBTM-1147
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Ondřej Chaloupka
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example:
> The following rules in BACrashDuringCommit could be refactored into a single rule
> {code}
> #####################################################################
> # Setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> These can be re-factored in to a rule like this:
> {code}
> RULE setup counter
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT ENTRY
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> This assumes that we have the same numbers for each use of:
> {code}
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> {code}
> Which is *usually* the case:
> {code}
> grep -r createCounter\(\"closes\" .
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> {code}
> Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated.
> Also, the following similar rules are also present in this file:
> {code}
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> Which could be replaced with something like this:
> {code}
> RULE wait for closes
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-924) recovery leaks xaresources
by Julien Kronegg (JIRA)
[ https://issues.jboss.org/browse/JBTM-924?page=com.atlassian.jira.plugin.s... ]
Julien Kronegg commented on JBTM-924:
-------------------------------------
I got this issue under JBoss EAP 5.3.0.GA_SOA (a flavor of JBoss AS 6) and solved it by applying patch JBPAPP-10703.
> recovery leaks xaresources
> --------------------------
>
> Key: JBTM-924
> URL: https://issues.jboss.org/browse/JBTM-924
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery
> Affects Versions: 4.6.1.CP12, 4.15.3, 5.0.0.M1
> Reporter: Jonathan Halliday
> Assignee: Jonathan Halliday
> Fix For: 4.6.1.CP13, 4.16.0.Beta1, 4.17.0
>
>
> XARecoveryModule._xidScans may grow without limit in cases where an xa recovery plugin is both a) returning new XAResources rather than validiating and reusing the previous one and b) the isSameRM implementation provided by the driver is unable to recognize the equivalence of two such XAResources.
> To prevent such leakage we should remove any scan entries that have not been updated recently, thus ensuring expiration of entries that are not refreshed by the refreshXidScansForEquivalentXAResourceImpl correlation mechanism.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (JBTM-1665) Remove dependency on TAO
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1665?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1665:
-------------------------------------
Thanks Crispin, that looks like it will be a much appreciated contribution. When you think you are ready, feel free to raise a pull request and that will run our CI tests on your contribution on all our dev supported platforms (linux el5 32 64, linux el6 32 64 and windows 2008 32) which should give us enough confidence to merge it.
Plus, as Amos says, he and I can review it too.
Thanks again!
> Remove dependency on TAO
> ------------------------
>
> Key: JBTM-1665
> URL: https://issues.jboss.org/browse/JBTM-1665
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.0.M4
>
>
> Part of the purpose of adding the socket server was to reduce the dependency on TAO, e.g.:
> ==6038== 20 bytes in 1 blocks are still reachable in loss record 7 of 54
> ==6038== at 0x4026011: calloc (vg_replace_malloc.c:593)
> ==6038== by 0x55C90A5: _dlerror_run (in /lib/libdl-2.12.so)
> ==6038== by 0x55C8B70: dlopen@(a)GLIBC_2.1 (in /lib/libdl-2.12.so)
> ==6038== by 0x40E2875: ACE_DLL_Handle::open(char const*, int, void*) (OS_NS_dlfcn.inl:124)
> ==6038== by 0x40E2D2B: ACE_DLL_Manager::open_dll(char const*, int, void*) (DLL_Manager.cpp:575)
> ==6038== by 0x40A3943: ACE_DLL::open_i(char const*, int, bool, void*) (DLL.cpp:167)
> ==6038== by 0x40A3AAA: ACE_DLL::open(char const*, int, bool) (DLL.cpp:127)
> ==6038== by 0x40A4C0A: ACE_Location_Node::open_dll(int&) (Parse_Node.cpp:479)
> ==6038== by 0x40A4D4B: ACE_Function_Node::symbol(ACE_Service_Gestalt*, int&, void (**)(void*)) (Parse_Node.cpp:657)
> ==6038== by 0x40A5627: ACE_Service_Type_Factory::make_service_type(ACE_Service_Gestalt*) const (Parse_Node.cpp:880)
> ==6038== by 0x40ACEA6: ACE_Service_Gestalt::initialize(ACE_Service_Type_Factory const*, char const*) (Service_Gestalt.cpp:552)
> ==6038== by 0x40A5555: ACE_Dynamic_Node::apply(ACE_Service_Gestalt*, int&) (Parse_Node.cpp:326)
> ==6038== by 0x40B3302: ace_yyparse(void*) (Svc_Conf_y.cpp:1440)
> ==6038== by 0x40AA5C7: ACE_Service_Gestalt::process_directives_i(ACE_Svc_Conf_Param*) (Service_Gestalt.cpp:800)
> ==6038== by 0x40AD407: ACE_Service_Gestalt::process_directive(char const*) (Service_Gestalt.cpp:940)
> ==6038== by 0x4287A65: TAO::ORB::open_global_services(int, char**) (Service_Config.inl:154)
> ==6038== by 0x4247EB3: CORBA::ORB_init(int&, char**, char const*) (ORB.cpp:1254)
> ==6038== by 0x49172F6: initOrb(char*) (OrbManagement.cxx:73)
> ==6038== by 0x4AB97C4: atmibroker::tx::OTSTxManager::OTSTxManager(char*) (OTSTxManager.cxx:39)
> ==6038== by 0x4ABA054: atmibroker::tx::OTSTxManager::create(char*) (OTSTxManager.cxx:57)
> ==6038== by 0x4AB0BDC: atmibroker::tx::TxManager::get_instance() (TxManager.cxx:63)
> ==6038== by 0x4AE7D06: txManager_open() (TxManagerAvoid.cxx:23)
> ==6038== by 0x4AD74D4: tx_open (TxAvoid.cxx:53)
> ==6038== by 0x804FF8D: TestXAStompConnection::test() (TestXAStompConnection.cxx:79)
> ==6038== by 0x805945B: CppUnit::TestCaller<TestXAStompConnection>::runTest() (TestCaller.h:166)
> ==6038== by 0xA5DC76: CppUnit::TestCaseMethodFunctor::operator()() const (TestCase.cpp:32)
> ==6038== by 0xA4F53D: CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (DefaultProtector.cpp:15)
> ==6038== by 0xA59812: CppUnit::ProtectorChain::ProtectFunctor::operator()() const (ProtectorChain.cpp:20)
> ==6038== by 0xA59544: CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (ProtectorChain.cpp:77)
> ==6038== by 0xA65EF0: CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::string const&) (TestResult.cpp:178)
> ==6038== by 0xA5D97C: CppUnit::TestCase::run(CppUnit::TestResult*) (TestCase.cpp:92)
> ==6038== by 0xA5E2DE: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64)
> ==6038== by 0xA5E219: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23)
> ==6038== by 0xA5E2DE: CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) (TestComposite.cpp:64)
> ==6038== by 0xA5E219: CppUnit::TestComposite::run(CppUnit::TestResult*) (TestComposite.cpp:23)
> ==6038== by 0xA6850F: CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) (TestRunner.cpp:47)
> ==6038== by 0xA65C89: CppUnit::TestResult::runTest(CppUnit::Test*) (TestResult.cpp:145)
> ==6038== by 0xA6834F: CppUnit::TestRunner::run(CppUnit::TestResult&, std::string const&) (TestRunner.cpp:96)
> ==6038== by 0xA6BA7A: CppUnit::TextTestRunner::run(CppUnit::TestResult&, std::string const&) (TextTestRunner.cpp:140)
> ==6038== by 0xA6BAF4: CppUnit::TextTestRunner::run(std::string, bool, bool, bool) (TextTestRunner.cpp:64)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years