[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15330593#comment-15330593 ] James E. King, III commented on THRIFT-3228: Does the priority of critical still make sense for this particular defect with respect to other defects labeled as such? Would it be possible to submit a pull request in github for the fix? > Fix TAutoOverlapThread may reference released memory > > > Key: THRIFT-3228 > URL: https://issues.apache.org/jira/browse/THRIFT-3228 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: Paweł Janicki >Priority: Critical > Attachments: > 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, > ConsoleApplication1.cpp > > > A released memory may be referenced by TAutoEverlapThread in case there > exists a global instance of TPipeServer or TNamedPipeServer or > TAutoOverlapThread in compilation module other than > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp > TPipeServer on listen() instantiates TNamedPipeServer which instantiates > TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static > function TOverlappedSubmissionThread::release_instance(). This static > functions refers to global variable "TCriticalSection > TOverlappedSubmissionThread::instanceGuard_" defined in > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. > As the d-tion of globar variable is undefined across compilation modules it > may happen that if user defined global variable holding reference to > TPipeServer, the instanceGuard_ can be freed by CRT before call to > TPipeServer d-tor, which will reference deleted global variable > instanceGuard_. > This is because of incorrect implementation of singleton pattern of > TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15009578#comment-15009578 ] James E. King, III commented on THRIFT-3228: Couldn't a boost::mutex be used to ensure that the function level static for getInstance() is thread-safe? > Fix TAutoOverlapThread may reference released memory > > > Key: THRIFT-3228 > URL: https://issues.apache.org/jira/browse/THRIFT-3228 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: Paweł Janicki >Priority: Critical > Attachments: > 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, > ConsoleApplication1.cpp > > > A released memory may be referenced by TAutoEverlapThread in case there > exists a global instance of TPipeServer or TNamedPipeServer or > TAutoOverlapThread in compilation module other than > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp > TPipeServer on listen() instantiates TNamedPipeServer which instantiates > TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static > function TOverlappedSubmissionThread::release_instance(). This static > functions refers to global variable "TCriticalSection > TOverlappedSubmissionThread::instanceGuard_" defined in > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. > As the d-tion of globar variable is undefined across compilation modules it > may happen that if user defined global variable holding reference to > TPipeServer, the instanceGuard_ can be freed by CRT before call to > TPipeServer d-tor, which will reference deleted global variable > instanceGuard_. > This is because of incorrect implementation of singleton pattern of > TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933855#comment-14933855 ] James E. King, III commented on THRIFT-3228: [~ben.craig] What's the next action to take here? > Fix TAutoOverlapThread may reference released memory > > > Key: THRIFT-3228 > URL: https://issues.apache.org/jira/browse/THRIFT-3228 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: Paweł Janicki >Priority: Critical > Attachments: > 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, > ConsoleApplication1.cpp > > > A released memory may be referenced by TAutoEverlapThread in case there > exists a global instance of TPipeServer or TNamedPipeServer or > TAutoOverlapThread in compilation module other than > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp > TPipeServer on listen() instantiates TNamedPipeServer which instantiates > TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static > function TOverlappedSubmissionThread::release_instance(). This static > functions refers to global variable "TCriticalSection > TOverlappedSubmissionThread::instanceGuard_" defined in > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. > As the d-tion of globar variable is undefined across compilation modules it > may happen that if user defined global variable holding reference to > TPipeServer, the instanceGuard_ can be freed by CRT before call to > TPipeServer d-tor, which will reference deleted global variable > instanceGuard_. > This is because of incorrect implementation of singleton pattern of > TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934471#comment-14934471 ] Ben Craig commented on THRIFT-3228: --- There are basically two major options... 1. Break behavioral compatibility and remove the singleton 2. Don't break behavioral compatibility If you go with option 1. you can also take out the big chunk of WaitableNamedPipe code in TPipe.cpp. It does break some legitimate use cases though. If you go with option 2., your best bet is to deprecate TPipe and make a new version. Maybe that version requires the user to do things similar to the TWinsockSingleton, or maybe it doesn't bother with the WaitableNamedPipe approach. > Fix TAutoOverlapThread may reference released memory > > > Key: THRIFT-3228 > URL: https://issues.apache.org/jira/browse/THRIFT-3228 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.9.2 >Reporter: Paweł Janicki >Priority: Critical > Attachments: > 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, > ConsoleApplication1.cpp > > > A released memory may be referenced by TAutoEverlapThread in case there > exists a global instance of TPipeServer or TNamedPipeServer or > TAutoOverlapThread in compilation module other than > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp > TPipeServer on listen() instantiates TNamedPipeServer which instantiates > TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static > function TOverlappedSubmissionThread::release_instance(). This static > functions refers to global variable "TCriticalSection > TOverlappedSubmissionThread::instanceGuard_" defined in > src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. > As the d-tion of globar variable is undefined across compilation modules it > may happen that if user defined global variable holding reference to > TPipeServer, the instanceGuard_ can be freed by CRT before call to > TPipeServer d-tor, which will reference deleted global variable > instanceGuard_. > This is because of incorrect implementation of singleton pattern of > TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
I seem to be having an issue when trying to connect to cassandra to php via
thrift and this is the issue when running this code:
?php
$GLOBALS['THRIFT_ROOT'] = '/usr/share/php/Thrift';
require_once $GLOBALS['THRIFT_ROOT'].'/packages/cassandra/Cassandra.php';
require_once $GLOBALS['THRIFT_ROOT'].'/packages/cassandra/cassandra_types.php';
require_once $GLOBALS['THRIFT_ROOT'].'/transport/TSocket.php';
require_once $GLOBALS['THRIFT_ROOT'].'/protocol/TBinaryProtocol.php';
require_once $GLOBALS['THRIFT_ROOT'].'/transport/TFramedTransport.php';
require_once $GLOBALS['THRIFT_ROOT'].'/transport/TBufferedTransport.php';
try {
// Make a connection to the Thrift interface to Cassandra
$socket = new TSocket('127.0.0.1', 9160);
$transport = new TBufferedTransport($socket, 1024, 1024);
$protocol = new TBinaryProtocolAccelerated($transport);
$client = new CassandraClient($protocol);
$transport-open();
/* Insert some data into the Standard1 column family from the default config */
// Keyspace specified in storage=conf.xml
$keyspace = 'Keyspace1';
// reference to specific User id
$keyUserId = 1;
// Constructing the column path that we are adding information into.
$columnPath = new cassandra_ColumnPath();
$columnPath-column_family = 'Standard1';
$columnPath-super_column = null;
$columnPath-column = 'email';
// Timestamp for update
$timestamp = time();
// We want the consistency level to be ZERO which means async operations on 1
node
$consistency_level = cassandra_ConsistencyLevel::ZERO;
// Add the value to be written to the table, User Key, and path.
$value = foo...@example.com;
$client-insert($keyspace, $keyUserId, $columnPath, $value, $timestamp,
$consistency_level);
// Add a new column path to be altered.
$columnPath-column = 'age';
//Get a current timestamp
$timestamp = time();
// Update the value to be inserted for the updated column Path
$value = 24;
$client-insert($keyspace, $keyUserId, $columnPath, $value, $timestamp,
$consistency_level);
/*
use batch_insert to insert a supercolumn and its children using the standard
config
builds the structure *
Super1 : {
KeyName : {
SuperColumnName : {
foo : fooey value
bar : bar like thing
}
}
}
*/
// build columns to insert
$column1 = new cassandra_Column();
$column1-name = 'foo';
$column1-value = 'fooey value';
$column1-timestamp = time();
$column2 = new cassandra_Column();
$column2-name = 'bar';
$column2-value = 'bar like thing';
$column2-timestamp = time();
// build super column containing the columns
$super_column = new cassandra_SuperColumn();
$super_column-name = 'SuperColumnName';
$super_column-columns = array($column1, $column2);
// create columnorsupercolumn holder class that batch_insert uses
$c_or_sc = new cassandra_ColumnOrSuperColumn();
$c_or_sc-super_column = $super_column;
// create the mutation (a map of ColumnFamily names to lists
ColumnsOrSuperColumns objects
$mutation['Super1'] = array($c_or_sc);
$client-batch_insert($keyspace, 'KeyName', $mutation, $consistency_level);
/* Query for data */
// Specify what Column Family to query against.
$columnParent = new cassandra_ColumnParent();
$columnParent-column_family = Standard1;
$columnParent-super_column = NULL;
$sliceRange = new cassandra_SliceRange();
$sliceRange-start = ;
$sliceRange-finish = ;
$predicate = new cassandra_SlicePredicate();
list() = $predicate-column_names;
$predicate-slice_range = $sliceRange;
// We want the consistency level to be ONE which means to only wait for 1 node
$consistency_level = cassandra_ConsistencyLevel::ONE;
// Issue the Query
$keyUserId = 1;
$result = $client-get_slice($keyspace, $keyUserId, $columnParent, $predicate,
$consistency_level);
print_r($result);
$transport-close();
} catch (TException $tx) {
print 'TException: '.$tx-why. ' Error: '.$tx-getMessage() . \n;
}
?
TTransport class was not loaded and not found in TSocket.php line 37.
Any ideas would be great?
Thanks
On 11 Aug 2015, at 16:46, James E. King, III (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681968#comment-14681968
]
James E. King, III commented on THRIFT-3228:
You can use boost::once to properly initialize something once and only once
in a thread-safe manner that is portable.
Tip: You can make something non-copyable by having it inherit from
boost::noncopyable instead of declaring the copy constructor and assignment
operator explicitly.
Fix TAutoOverlapThread may reference released memory
Key: THRIFT-3228
URL: https://issues.apache.org/jira/browse/THRIFT-3228
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.2
Reporter: Paweł Janicki
Priority: Critical
Attachments:
[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14681968#comment-14681968 ] James E. King, III commented on THRIFT-3228: You can use boost::once to properly initialize something once and only once in a thread-safe manner that is portable. Tip: You can make something non-copyable by having it inherit from boost::noncopyable instead of declaring the copy constructor and assignment operator explicitly. Fix TAutoOverlapThread may reference released memory Key: THRIFT-3228 URL: https://issues.apache.org/jira/browse/THRIFT-3228 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.2 Reporter: Paweł Janicki Priority: Critical Attachments: 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, ConsoleApplication1.cpp A released memory may be referenced by TAutoEverlapThread in case there exists a global instance of TPipeServer or TNamedPipeServer or TAutoOverlapThread in compilation module other than src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp TPipeServer on listen() instantiates TNamedPipeServer which instantiates TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static function TOverlappedSubmissionThread::release_instance(). This static functions refers to global variable TCriticalSection TOverlappedSubmissionThread::instanceGuard_ defined in src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. As the d-tion of globar variable is undefined across compilation modules it may happen that if user defined global variable holding reference to TPipeServer, the instanceGuard_ can be freed by CRT before call to TPipeServer d-tor, which will reference deleted global variable instanceGuard_. This is because of incorrect implementation of singleton pattern of TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620029#comment-14620029 ] Paweł Janicki commented on THRIFT-3228: --- My question is if we are going to abadon the lazy-initialization at the trade on removing the constraint Don't destroy at global scope? Fix TAutoOverlapThread may reference released memory Key: THRIFT-3228 URL: https://issues.apache.org/jira/browse/THRIFT-3228 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.2 Reporter: Paweł Janicki Priority: Critical Attachments: 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, ConsoleApplication1.cpp A released memory may be referenced by TAutoEverlapThread in case there exists a global instance of TPipeServer or TNamedPipeServer or TAutoOverlapThread in compilation module other than src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp TPipeServer on listen() instantiates TNamedPipeServer which instantiates TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static function TOverlappedSubmissionThread::release_instance(). This static functions refers to global variable TCriticalSection TOverlappedSubmissionThread::instanceGuard_ defined in src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. As the d-tion of globar variable is undefined across compilation modules it may happen that if user defined global variable holding reference to TPipeServer, the instanceGuard_ can be freed by CRT before call to TPipeServer d-tor, which will reference deleted global variable instanceGuard_. This is because of incorrect implementation of singleton pattern of TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14620491#comment-14620491 ] Ben Craig commented on THRIFT-3228: --- A lot of my uses of Thrift involve multiple users of Thrift, mostly unaware of each other, all coexisting in the same process. This includes multiple dlls, some of which also use Thrift. With the function level static, there isn't a way to arbitrate between the different clients. None of the clients know whose responsibility it is to initialize everything. The create and destroy at global scope constraint isn't pleasant either, but at least all clients can follow that without coordinating amongst each other. I have strongly considered taking out the overlapped submission thread from TPipe entirely, and making a different transport class just to satisfy my waitable pipe needs. The server class that fully takes advantage of the overlapped submission thread isn't even currently public, or something that I particularly like at this point. Fix TAutoOverlapThread may reference released memory Key: THRIFT-3228 URL: https://issues.apache.org/jira/browse/THRIFT-3228 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.2 Reporter: Paweł Janicki Priority: Critical Attachments: 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, ConsoleApplication1.cpp A released memory may be referenced by TAutoEverlapThread in case there exists a global instance of TPipeServer or TNamedPipeServer or TAutoOverlapThread in compilation module other than src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp TPipeServer on listen() instantiates TNamedPipeServer which instantiates TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static function TOverlappedSubmissionThread::release_instance(). This static functions refers to global variable TCriticalSection TOverlappedSubmissionThread::instanceGuard_ defined in src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. As the d-tion of globar variable is undefined across compilation modules it may happen that if user defined global variable holding reference to TPipeServer, the instanceGuard_ can be freed by CRT before call to TPipeServer d-tor, which will reference deleted global variable instanceGuard_. This is because of incorrect implementation of singleton pattern of TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3228) Fix TAutoOverlapThread may reference released memory
[ https://issues.apache.org/jira/browse/THRIFT-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14618801#comment-14618801 ] Ben Craig commented on THRIFT-3228: --- Function level statics are not thread safe in Visual Studio 2013 and earlier. Visual Studio 2015 makes the construction thread safe, but Thrift can't make Visual Studio 2015 the oldest supported version right now. Fix TAutoOverlapThread may reference released memory Key: THRIFT-3228 URL: https://issues.apache.org/jira/browse/THRIFT-3228 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.9.2 Reporter: Paweł Janicki Priority: Critical Attachments: 0001-THRIFT-3228.-cpp-Fix-TAutoOverlapThread-may-referenc.patch, ConsoleApplication1.cpp A released memory may be referenced by TAutoEverlapThread in case there exists a global instance of TPipeServer or TNamedPipeServer or TAutoOverlapThread in compilation module other than src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp TPipeServer on listen() instantiates TNamedPipeServer which instantiates TAutoOverlapThread. The TAutoOverlapThread calls in it's d-tor a static function TOverlappedSubmissionThread::release_instance(). This static functions refers to global variable TCriticalSection TOverlappedSubmissionThread::instanceGuard_ defined in src\lib\cpp\src\thrift\windows\OverlappedSubmissionThread.cpp. As the d-tion of globar variable is undefined across compilation modules it may happen that if user defined global variable holding reference to TPipeServer, the instanceGuard_ can be freed by CRT before call to TPipeServer d-tor, which will reference deleted global variable instanceGuard_. This is because of incorrect implementation of singleton pattern of TOverlappedSubmissionThread. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
