Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

* Add CppUnit/WinTestRunner to Visual Studio build components #5

Closed
wants to merge 1 commit into from
Closed

* Add CppUnit/WinTestRunner to Visual Studio build components #5

wants to merge 1 commit into from

Conversation

RangelReale
Copy link
Contributor

No description provided.

@aleks-f
Copy link
Member

aleks-f commented Nov 11, 2012

If a solution with the same name as project exists, VS will pick it up and build everything in it (regardless of attempt/intent to build project only). The problem with WinTestRunner is that it depends on MFC (VC Express and MsBuild come without it).

@RangelReale
Copy link
Contributor Author

But when compiling using the buildwin.cmd script and tests enabled, all test compilation fails because of missing WinTestRunner.lib, that was the motivation for this patch.

@aleks-f
Copy link
Member

aleks-f commented Nov 11, 2012

Ah, yes, you are right because name is different from CppUnit. I guess we can accept it.

@RangelReale
Copy link
Contributor Author

I tested it, this makes the build compile cleanly.

@aleks-f
Copy link
Member

aleks-f commented Nov 11, 2012

Now that I think about it, I think it'll mess up other platforms. Need to look at it.

@RangelReale
Copy link
Contributor Author

But isn't buildwin.cmd only used for Visual Studio in Windows?

EDIT: the "components" file might be used in other platforms, ok.

@aleks-f
Copy link
Member

aleks-f commented Nov 11, 2012

yes:
rules/global:209:COMPONENTS := $(shell cat $(POCO_BASE)/components)
script/makeldpath:15:projectList=cat ${POCO_BASE}/components

I agree with you, building should be out of the box. We'll need to look into how to do this right but I'm still not clear why it does not build because WinTestRunner is included in CppUnit solution. Günter has done some changes this weekend, he may be able to shed some light on it ...

@aleks-f aleks-f closed this Mar 31, 2013
@aleks-f aleks-f mentioned this pull request Jul 19, 2013
Closed
kostya-lnk-ms pushed a commit to kostya-lnk-ms/poco that referenced this pull request May 19, 2015
Merge pull request pocoproject#5 in FSF_POCO/upstream from ~LUTKOS/up…
ad31fb7 
…stream:ms-develop to ms-develop

* commit '335631b64f9557d5ff4dac54bf916e0b61280fd8':
  MSTKPROJ-1466 Fixed posgres error reporting
@DEvil0000 DEvil0000 mentioned this pull request Nov 25, 2015
Closed
@sujov sujov mentioned this pull request Jul 12, 2016
Closed
@Smiley2306 Smiley2306 mentioned this pull request Sep 13, 2016
Closed
This was referenced May 1, 2017
Closed
Merged
sebastien-guay added a commit to sebastien-guay/poco that referenced this pull request May 1, 2017
@sebastien-guay
"SocketReactor::addEventHandler" and "SocketReactor::removeEventHandl…
ceac31f 
…er" must protect the access to "NotifierPtr pNotifier"

Those two methods already use FastMutex::ScopedLock lock(_mutex), but
the scope is not large enough to protect "NotifierPtr pNotifier" that is
accessed by calling SocketNotifier::addObserver() and
SocketNotifier::removeObserver().

It is mentioned in SocketReator.h that it is safe to call
addEventHandler() and removeEventHandler() from another thread while the
SocketReactor is running. My current use of the SocketReactor
encountered an issue where the SocketNotifier::_events has been
corrupted by a concurent write access done by
SocketReactor::addEventHandler() and
SocketReactor::removeEventHandler().
The call stack show that the SocketReactor::addEventHandler is stuck in
a while loop in gcc/libstdc++/tree.cc Rb_tree_insert_and_rebalance()

I clearly see in my logs that it happened while my
SocketConnector::unregisterConnector() and
SocketConnector::registerConnector() were called by two different
threads.

#0 0x00a80a7b in std::_Rb_tree_insert_and_rebalance () from
/usr/lib/libstdc++.so.6
pocoproject#1 0x06ccb430 in std::_Rb_tree<Poco::Net::SocketNotification*,
Poco::Net::SocketNotification*,
std::_IdentityPoco::Net::SocketNotification*,
std::lessPoco::Net::SocketNotification*,
std::allocatorPoco::Net::SocketNotification* >::_M_insert
(this=0xac75dc90, __x=0x0, __p=0xac7ed0c8, __v=@0xb5fb0c40) at
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_tree.h:816
pocoproject#2 0x06ccb15d in std::_Rb_tree<Poco::Net::SocketNotification*,
Poco::Net::SocketNotification*,
std::_IdentityPoco::Net::SocketNotification*,
std::lessPoco::Net::SocketNotification*,
std::allocatorPoco::Net::SocketNotification* >::insert_equal
(this=0xac75dc90, __v=@0xb5fb0c40) at
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_tree.h:858
pocoproject#3 0x06ccad86 in std::multiset<Poco::Net::SocketNotification*,
std::lessPoco::Net::SocketNotification*,
std::allocatorPoco::Net::SocketNotification* >::insert (this=0xac75dc90,
__x=@0xb5fb0c40)
at
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_multiset.h:306
pocoproject#4 0x06cca72b in Poco::Net::SocketNotifier::addObserver
(this=0xac75dc70, pReactor=0x8d27958, observer=@0xb5fb0cd0) at
src/SocketNotifier.cpp:45
pocoproject#5 0x06cd060f in Poco::Net::SocketReactor::addEventHandler
(this=0x8d27958, socket=@0xac7f5a74, observer=@0xb5fb0cd0) at
src/SocketReactor.cpp:178

SocketReactor::run() is already protecting the access to the
SocketNotifier.
aleks-f pushed a commit that referenced this pull request Aug 10, 2017
@sebastien-guay @aleks-f
"SocketReactor::addEventHandler" and "SocketReactor::removeEventHandl…
a9982e6 
…er" must protect the access to "NotifierPtr pNotifier" (#1709)

Those two methods already use FastMutex::ScopedLock lock(_mutex), but
the scope is not large enough to protect "NotifierPtr pNotifier" that is
accessed by calling SocketNotifier::addObserver() and
SocketNotifier::removeObserver().

It is mentioned in SocketReator.h that it is safe to call
addEventHandler() and removeEventHandler() from another thread while the
SocketReactor is running. My current use of the SocketReactor
encountered an issue where the SocketNotifier::_events has been
corrupted by a concurent write access done by
SocketReactor::addEventHandler() and
SocketReactor::removeEventHandler().
The call stack show that the SocketReactor::addEventHandler is stuck in
a while loop in gcc/libstdc++/tree.cc Rb_tree_insert_and_rebalance()

I clearly see in my logs that it happened while my
SocketConnector::unregisterConnector() and
SocketConnector::registerConnector() were called by two different
threads.

#0 0x00a80a7b in std::_Rb_tree_insert_and_rebalance () from
/usr/lib/libstdc++.so.6
#1 0x06ccb430 in std::_Rb_tree<Poco::Net::SocketNotification*,
Poco::Net::SocketNotification*,
std::_IdentityPoco::Net::SocketNotification*,
std::lessPoco::Net::SocketNotification*,
std::allocatorPoco::Net::SocketNotification* >::_M_insert
(this=0xac75dc90, __x=0x0, __p=0xac7ed0c8, __v=@0xb5fb0c40) at
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_tree.h:816
#2 0x06ccb15d in std::_Rb_tree<Poco::Net::SocketNotification*,
Poco::Net::SocketNotification*,
std::_IdentityPoco::Net::SocketNotification*,
std::lessPoco::Net::SocketNotification*,
std::allocatorPoco::Net::SocketNotification* >::insert_equal
(this=0xac75dc90, __v=@0xb5fb0c40) at
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_tree.h:858
#3 0x06ccad86 in std::multiset<Poco::Net::SocketNotification*,
std::lessPoco::Net::SocketNotification*,
std::allocatorPoco::Net::SocketNotification* >::insert (this=0xac75dc90,
__x=@0xb5fb0c40)
at
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_multiset.h:306
#4 0x06cca72b in Poco::Net::SocketNotifier::addObserver
(this=0xac75dc70, pReactor=0x8d27958, observer=@0xb5fb0cd0) at
src/SocketNotifier.cpp:45
#5 0x06cd060f in Poco::Net::SocketReactor::addEventHandler
(this=0x8d27958, socket=@0xac7f5a74, observer=@0xb5fb0cd0) at
src/SocketReactor.cpp:178

SocketReactor::run() is already protecting the access to the
SocketNotifier.
@tenglong88 tenglong88 mentioned this pull request Oct 27, 2017
Closed
@jrfeenst jrfeenst mentioned this pull request Jan 11, 2018
Closed
@jbulow jbulow mentioned this pull request Mar 8, 2018
Closed
@mkrivos mkrivos mentioned this pull request Apr 12, 2018
Closed
@kongdb kongdb mentioned this pull request Oct 17, 2018
Closed
@jbulow jbulow mentioned this pull request Mar 8, 2019
Closed
@omerbrandis omerbrandis mentioned this pull request Jun 20, 2023
Closed
@hbzxl hbzxl mentioned this pull request Jul 25, 2024
Merged
@omerbrandis omerbrandis mentioned this pull request Dec 24, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@RangelReale @aleks-f