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

CMake fixes #4

Merged
merged 1 commit into from
Nov 12, 2012
Merged

CMake fixes #4

merged 1 commit into from
Nov 12, 2012

Conversation

RangelReale
Copy link
Contributor

  • add POCO_STATIC definition in CMake
  • Foundation must compile .mc file in CMake build
  • Net must list all files in CMake build file (because of Route_XXX.cpp)

@RangelReale
* add POCO_STATIC definition in CMake
86b79a6 
* Foundation must compile .mc file in CMake build
* Net must list all files in CMake build file
aleks-f added a commit that referenced this pull request Nov 12, 2012
@aleks-f
Merge pull request #4 from RangelReale/cmakefixes
671b537 
CMake fixes
@aleks-f aleks-f merged commit 671b537 into pocoproject:develop Nov 12, 2012
@aleks-f aleks-f mentioned this pull request Jul 19, 2013
Closed
@trusch trusch mentioned this pull request Apr 14, 2015
Closed
kostya-lnk-ms pushed a commit to kostya-lnk-ms/poco that referenced this pull request May 19, 2015
Merge pull request pocoproject#4 in FSF_POCO/upstream from ~LUTKOS/up…
d46726c 
…stream:MSTKPROJ-1466 to ms-develop

* commit '72087e0211c089a7f1e318c179c0641a590734b7':
  MSTKPROJ-1466 fixed wrong sql
  MSTKPROJ-1466 fixed psogres tests
  MSTKPROJ-1466 made test settings adjustable
obiltschnig pushed a commit that referenced this pull request Aug 19, 2015
@mkrivos
Merge pull request #4 from pocoproject/develop
27e7e5f 
Upstream refresh 3.1.2015
@zosrothko zosrothko mentioned this pull request Nov 20, 2015
Merged
@DEvil0000 DEvil0000 mentioned this pull request Nov 25, 2015
Closed
@zosrothko zosrothko mentioned this pull request Dec 11, 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
Open
@hbzxl hbzxl mentioned this pull request Jul 25, 2024
Merged
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
None yet
Projects
None yet
Milestone
No milestone
Development

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