[jira] [Commented] (THRIFT-4164) Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl
[ https://issues.apache.org/jira/browse/THRIFT-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954194#comment-15954194 ] James E. King, III commented on THRIFT-4164: PR #1235 exposed the fact that before that PR, we were quietly stopping openssl from using the locking callbacks we were providing. This would lead to unsafe multi-thread behavior during shutdown. I looked at guaranteeing this in core: I noodled through it and the solutions were all a bit ugly, involving the factory to keep a smart pointer of each socket it made, and a callback from TSSLSocket::close() to the factory to take it out of a set of sockets it had made. Then in ~TSSLSocketFactory we would need to guarantee the set of sockets left in the factory were the last instance (nobody else was holding onto them as well) so we could guarantee that when the set of sockets is reset, all the sockets the factory ever made were released.Then the factory could clean up openssl safely. OR, we clearly document the requirement that a factory must outlive any sockets it makes. This is what I'm going to do, so will revise the PR to fix our own TestClient.cpp which was in violation of the requirement that a TSSLSocketFactory must outlive any TSSLSocket it creates when the TSSLSocketFactory is managing openssl initialization and destruction, which was causing the build failures. > Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl > - > > Key: THRIFT-4164 > URL: https://issues.apache.org/jira/browse/THRIFT-4164 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.10.0 > Environment: Ubuntu 14.04, openssl (version TBD, I believe it is a > 1.1.0 variant) >Reporter: James E. King, III >Assignee: James E. King, III > > In a project where thrift is used, i was investigating a core in an assertion > in apache::thrift::concurrency::~Mutex (pthread variety). The mutex in > question was one of the locking mutexes that thrift gives to openssl. The > core occurred in TSSLSocket::cleanupOpenSSL() where the mutexes are destroyed > (on the last line). > I suspect that we might be changing the locking callbacks too early in the > cleanup process; perhaps one of the other cleanup calls that follows it would > have released a mutex in some situations? In any case, this needs to be > investigated and I am assigning it to myself. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4164) Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl
[
https://issues.apache.org/jira/browse/THRIFT-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954145#comment-15954145
]
James E. King, III commented on THRIFT-4164:
In the pull request where the first four builds failed with cores, I was able
to reproduce it locally as well. It is very interesting. We were resetting
the openssl thread safety/locking callbacks to NULL as part of destruction of
the last TSSLSocketFactory instance. In the test, we hold on to this socket
factory through the test and then it gets destroyed:
{noformat}
(gdb) bt
#0 apache::thrift::transport::cleanupOpenSSL () at
src/thrift/transport/TSSLSocket.cpp:137
#1 0x77fa10a5 in
apache::thrift::transport::TSSLSocketFactory::~TSSLSocketFactory
(this=0x48d6c0, __in_chrg=) at
src/thrift/transport/TSSLSocket.cpp:696
#2 0x77fa1199 in
apache::thrift::transport::TSSLSocketFactory::~TSSLSocketFactory
(this=0x48d6c0, __in_chrg=) at
src/thrift/transport/TSSLSocket.cpp:698
#3 0x00417d6a in boost::detail::sp_counted_base::release
(this=0x4a95c0) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#4 0x00414407 in release (this=0x4a95c0) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:144
#5 ~shared_count (this=, __in_chrg=) at
/usr/include/boost/smart_ptr/detail/shared_count.hpp:371
#6 ~shared_ptr (this=, __in_chrg=) at
/usr/include/boost/smart_ptr/shared_ptr.hpp:328
#7 main (argc=, argv=) at src/TestClient.cpp:235
{noformat}
Then later on in the test, we close a TSSLSocket that the factory created:
{noformat}
(gdb) bt
#0 0x76c56cc9 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x76c5a0d8 in __GI_abort () at abort.c:89
#2 0x76c4fb86 in __assert_fail_base (fmt=0x76da0830 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x77fcf106 "px
!= 0", file=file@entry=0x77fd1400
"/usr/include/boost/smart_ptr/shared_array.hpp", line=line@entry=194,
function=function@entry=0x77fd5fa0
::operator[](long)
const::__PRETTY_FUNCTION__> "T&
boost::shared_array::operator[](std::ptrdiff_t) const [with T =
apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]") at assert.c:92
#3 0x76c4fc32 in __GI___assert_fail
(assertion=assertion@entry=0x77fcf106 "px != 0",
file=file@entry=0x77fd1400 "/usr/include/boost/smart_ptr/shared_array.hpp",
line=line@entry=194,
function=function@entry=0x77fd5fa0
::operator[](long)
const::__PRETTY_FUNCTION__> "T&
boost::shared_array::operator[](std::ptrdiff_t) const [with T =
apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]") at assert.c:101
#4 0x77fa039d in operator[] (this=, i=)
at /usr/include/boost/smart_ptr/shared_array.hpp:194
#5 apache::thrift::transport::callbackLocking (mode=,
n=) at src/thrift/transport/TSSLSocket.cpp:73
#6 0x76644877 in CRYPTO_add_lock (pointer=0x4a8894, amount=-1,
type=12, file=0x76a08c4a "ssl_lib.c", line=1944) at cryptlib.c:632
#7 0x769f840c in SSL_CTX_free (a=0x4a8800) at ssl_lib.c:1944
#8 0x77fa0209 in apache::thrift::transport::SSLContext::~SSLContext
(this=0x4a85c0, __in_chrg=) at
src/thrift/transport/TSSLSocket.cpp:199
#9 0x77fa5832 in release (this=0x4a95a0) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#10 ~shared_count (this=0x4a9f20, __in_chrg=) at
/usr/include/boost/smart_ptr/detail/shared_count.hpp:371
#11 ~shared_ptr (this=0x4a9f18, __in_chrg=) at
/usr/include/boost/smart_ptr/shared_ptr.hpp:328
#12 apache::thrift::transport::TSSLSocket::~TSSLSocket (this=0x4a9e80,
__in_chrg=) at src/thrift/transport/TSSLSocket.cpp:238
#13 0x77fa58a9 in apache::thrift::transport::TSSLSocket::~TSSLSocket
(this=0x4a9e80, __in_chrg=) at
src/thrift/transport/TSSLSocket.cpp:240
#14 0x77fad03a in release (this=0x4a9f40) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#15 ~shared_count (this=0x4ad640, __in_chrg=) at
/usr/include/boost/smart_ptr/detail/shared_count.hpp:371
#16 ~shared_ptr (this=0x4ad638, __in_chrg=) at
/usr/include/boost/smart_ptr/shared_ptr.hpp:328
#17 ~TBufferedTransport (this=0x4ad610, __in_chrg=) at
./src/thrift/transport/TBufferTransports.h:184
#18 apache::thrift::transport::TBufferedTransport::~TBufferedTransport
(this=0x4ad610, __in_chrg=) at
./src/thrift/transport/TBufferTransports.h:184
#19 0x00417d6a in boost::detail::sp_counted_base::release
(this=0x4ae910) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:146
#20 0x0041446f in release (this=) at
/usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:144
#21 ~shared_count (this=0x7fffdc98, __in_chrg=) at
/usr/include/boost/smart_ptr/detail/shared_count.hpp:371
#22 ~shared_ptr (this=0x7fffdc90, __in_chrg=) at
/usr/
[jira] [Commented] (THRIFT-4163) The debian package / autoconf build environment is not setting NDEBUG on production builds, leaving assertions active
[
https://issues.apache.org/jira/browse/THRIFT-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954048#comment-15954048
]
James E. King, III commented on THRIFT-4163:
I tried doing that but it got a bit messy. I'm thinking instead I will just
add -DNDEBUG to the flags for the debian build. I'd like to hear from others
about this however... do you think asserts should be left on in release
production builds? Eventually we'll remove all the asserts and use exceptions
but until then...
> The debian package / autoconf build environment is not setting NDEBUG on
> production builds, leaving assertions active
> -
>
> Key: THRIFT-4163
> URL: https://issues.apache.org/jira/browse/THRIFT-4163
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
>
> In a project that uses thrift I was looking at a core and found an assertion
> inside thrift triggered it. This was rather strange being in a release build
> of thrift.
> To understand if assertions are active in release builds, I modified
> PlatformSocket.h and added this close to the top:
> {noformat}
> #ifdef NDEBUG
> #error "NDEBUG IS SET: ASSERTIONS ARE IGNORED"
> #else
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> #endif
> {noformat}
> Then I built the ubuntu dockerfile and started a debian package distribution
> build:
> {noformat}
> # docker build -t thrift build/docker/ubuntu
> # docker run -v $(pwd):/thrift/src -it thrift /bin/bash
> # dpkg-buildpackage -d -tc 2>&1 | grep NDEBUG
> ./src/thrift/transport/PlatformSocket.h:25:2: error: #error "NDEBUG IS NOT
> SET: ASSERTIONS ARE ACTIVE"
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> {noformat}
> Assertions should not be active in release builds.
> Assertions really shouldn't be used; exceptions are much better for C++.
> That's covered in THRIFT-3978 however. To fix this issue, the autoconf
> system needs to set NDEBUG for release builds.
> I checked the cmake build environment and it does not suffer from this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (THRIFT-4163) The debian package / autoconf build environment is not setting NDEBUG on production builds, leaving assertions active
[
https://issues.apache.org/jira/browse/THRIFT-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-4163:
---
Priority: Major (was: Critical)
> The debian package / autoconf build environment is not setting NDEBUG on
> production builds, leaving assertions active
> -
>
> Key: THRIFT-4163
> URL: https://issues.apache.org/jira/browse/THRIFT-4163
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> In a project that uses thrift I was looking at a core and found an assertion
> inside thrift triggered it. This was rather strange being in a release build
> of thrift.
> To understand if assertions are active in release builds, I modified
> PlatformSocket.h and added this close to the top:
> {noformat}
> #ifdef NDEBUG
> #error "NDEBUG IS SET: ASSERTIONS ARE IGNORED"
> #else
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> #endif
> {noformat}
> Then I built the ubuntu dockerfile and started a debian package distribution
> build:
> {noformat}
> # docker build -t thrift build/docker/ubuntu
> # docker run -v $(pwd):/thrift/src -it thrift /bin/bash
> # dpkg-buildpackage -d -tc 2>&1 | grep NDEBUG
> ./src/thrift/transport/PlatformSocket.h:25:2: error: #error "NDEBUG IS NOT
> SET: ASSERTIONS ARE ACTIVE"
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> {noformat}
> Assertions should not be active in release builds.
> Assertions really shouldn't be used; exceptions are much better for C++.
> That's covered in THRIFT-3978 however. To fix this issue, the autoconf
> system needs to set NDEBUG for release builds.
> I checked the cmake build environment and it does not suffer from this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4156) Using boost spirit instead of lex and yacc
[ https://issues.apache.org/jira/browse/THRIFT-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954020#comment-15954020 ] Mike Gresens commented on THRIFT-4156: -- According to the release notes of the current boost version (1.63) http://www.boost.org/users/history/version_1_63_0.html Compilers Tested Boost's primary test compilers are: Linux: Clang: 3.0, 3.8.1 Clang, C++11: 3.0, 3.1, 3.2, 3.3, 3.4, 3.8.1 Clang, C++14: 3.5, 3.6, 3.7, 3.8.1 Clang, C++1z: 3.8.1 GCC: 4.4.7, 4.5.3, 4.6.3, 4.7.2, 5.2.0, 6.2.0 GCC, C++11: 4.4.7, 4.7.2, 4.7.3, 4.8.5, 4.9.3, 5.2.0, 6.1.1, 6.2.0 GCC, C++14: 5.2.0, 5.3.0, 6.1.1, 6.2.0 Intel: 16.0, 17.0 Intel, C++11: 16.0, 17.0 Intel, C++14: 16.0, 17.0 OS X: Apple Clang: 7.0.2 Apple Clang, C++11: 7.0.2 Windows: GCC, C++03, mingw: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0 GCC, C++11, mingw: 4.6.4, 4.7.3, 4.8.1 GCC, C++14, mingw: 4.9.3, 5.1.0, 5.2.0, 5.3.0, 6.1.0 Visual C++: 7.1, 8.0, 9.0, 10.0, 11.0, 12.0, 14.0 Android: Clang: 3.6, 3.7, 3.8 GCC: 4.9, 5.4, 6.2 QNX: QCC: 4.4.2 SunOS: Oracle Solaris Studio: 12.5 Oracle Solaris Studio, C++11: 12.5 Boost's additional test compilers include: Linux: Clang: 3.0, 3.8.1 Clang, C++11: 3.0, 3.1, 3.2, 3.3, 3.4, 3.8.1 Clang, C++14: 3.5, 3.6, 3.7, 3.8.1 Clang, C++1z: 3.8.1 GCC: 4.4.7, 4.5.3, 4.6.3, 4.7.2, 5.2.0, 6.1.1, 6.2.0 GCC, C++11: 4.4.7, 4.7.2, 4.7.3, 4.8.5, 4.9.3, 5.2.0, 6.1.1, 6.2.0 GCC, C++14: 5.2.0, 5.3.0, 6.1.1, 6.2.0, 7.0.0 (experimental) GCC, C++1z: 6.1.1 Intel: 16.0, 17.0 Intel, C++11: 16.0, 17.0 Intel, C++14: 16.0, 17.0 OS X: Apple Clang: 7.0.2 Apple Clang, C++11: 7.0.2 Windows: GCC, C++03, mingw: 3.4.5, 4.1.2, 4.2.4, 4.3.3, 4.4.0 GCC, C++11, mingw: 4.6.4, 4.7.3, 4.8.1 GCC, C++14, mingw: 4.9.3, 5.1.0, 5.2.0, 5.3.0, 6.1.0 Visual C++: 7.1, 8.0, 9.0, 10.0, 11.0, 12.0, 14.0 Android: Clang: 3.6, 3.7, 3.8 GCC: 4.9, 5.4, 6.2 GCC,C++14: 6.1.0 QNX: QCC: 4.4.2 SunOS: Oracle Solaris Studio: 12.5 Oracle Solaris Studio, C++11: 12.5 > Using boost spirit instead of lex and yacc > -- > > Key: THRIFT-4156 > URL: https://issues.apache.org/jira/browse/THRIFT-4156 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Reporter: Mike Gresens > > As a developer I want to use boost spirit to get rid of lex and yacc. > This kicks dependency to lex, flex, yacc, bison or what ever. > This makes building easier, because only c++ code must be compiled. > All grammar is inside the code - all c++. No need to learn ll and yy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-4163) The debian package / autoconf build environment is not setting NDEBUG on production builds, leaving assertions active
[
https://issues.apache.org/jira/browse/THRIFT-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953982#comment-15953982
]
James E. King, III edited comment on THRIFT-4163 at 4/3/17 6:45 PM:
To fix this I am pulling in an autoconf module to enable/disable debug and
modified it a little.
https://www.gnu.org/software/autoconf-archive/ax_check_enable_debug.html
The syntax will be as follows:
||{{./configure --enable-debug=}}||Compiler Options Used||Default?||NDEBUG||
|{{yes}}|{{-g -O0}}| | |
|{{info}}|{{-g -O2}}|yes|#defined|
|{{profile}}|{{-g -O0 -pg}}| |#defined|
|{{no}}|{{-O2}}| |#defined|
{noformat}
$ ./configure | grep debugging
checking whether to enable debugging... no just optimize
$ ./configure --enable-debug=yes | grep debugging
checking whether to enable debugging... yes without any optimization
$ ./configure --enable-debug=no | grep debugging
checking whether to enable debugging... no just optimize
{noformat}
was (Author: jking3):
To fix this I am pulling in an autoconf module to enable/disable debug and
modified it a little.
https://www.gnu.org/software/autoconf-archive/ax_check_enable_debug.html
The syntax will be as follows:
||{{./configure --enable-debug=}}||Compiler Options Used||Default?||
|{{yes}}|{{-g -O0}}| |
|{{info}}|{{-g -O2}}|yes|
|{{profile}}|{{-g -O0 -pg}}| |
|{{no}}|{{-O2}}| |
{noformat}
$ ./configure | grep debugging
checking whether to enable debugging... no just optimize
$ ./configure --enable-debug=yes | grep debugging
checking whether to enable debugging... yes without any optimization
$ ./configure --enable-debug=no | grep debugging
checking whether to enable debugging... no just optimize
{noformat}
> The debian package / autoconf build environment is not setting NDEBUG on
> production builds, leaving assertions active
> -
>
> Key: THRIFT-4163
> URL: https://issues.apache.org/jira/browse/THRIFT-4163
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
>
> In a project that uses thrift I was looking at a core and found an assertion
> inside thrift triggered it. This was rather strange being in a release build
> of thrift.
> To understand if assertions are active in release builds, I modified
> PlatformSocket.h and added this close to the top:
> {noformat}
> #ifdef NDEBUG
> #error "NDEBUG IS SET: ASSERTIONS ARE IGNORED"
> #else
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> #endif
> {noformat}
> Then I built the ubuntu dockerfile and started a debian package distribution
> build:
> {noformat}
> # docker build -t thrift build/docker/ubuntu
> # docker run -v $(pwd):/thrift/src -it thrift /bin/bash
> # dpkg-buildpackage -d -tc 2>&1 | grep NDEBUG
> ./src/thrift/transport/PlatformSocket.h:25:2: error: #error "NDEBUG IS NOT
> SET: ASSERTIONS ARE ACTIVE"
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> {noformat}
> Assertions should not be active in release builds.
> Assertions really shouldn't be used; exceptions are much better for C++.
> That's covered in THRIFT-3978 however. To fix this issue, the autoconf
> system needs to set NDEBUG for release builds.
> I checked the cmake build environment and it does not suffer from this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4163) The debian package / autoconf build environment is not setting NDEBUG on production builds, leaving assertions active
[
https://issues.apache.org/jira/browse/THRIFT-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953982#comment-15953982
]
James E. King, III commented on THRIFT-4163:
To fix this I am pulling in an autoconf module to enable/disable debug and
modified it a little.
https://www.gnu.org/software/autoconf-archive/ax_check_enable_debug.html
The syntax will be as follows:
||{{./configure --enable-debug=}}||Compiler Options Used||Default?||
|{{yes}}|{{-g -O0}}| |
|{{info}}|{{-g -O2}}|yes|
|{{profile}}|{{-g -O0 -pg}}| |
|{{no}}|{{-O2}}| |
{noformat}
$ ./configure | grep debugging
checking whether to enable debugging... no just optimize
$ ./configure --enable-debug=yes | grep debugging
checking whether to enable debugging... yes without any optimization
$ ./configure --enable-debug=no | grep debugging
checking whether to enable debugging... no just optimize
{noformat}
> The debian package / autoconf build environment is not setting NDEBUG on
> production builds, leaving assertions active
> -
>
> Key: THRIFT-4163
> URL: https://issues.apache.org/jira/browse/THRIFT-4163
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
>
> In a project that uses thrift I was looking at a core and found an assertion
> inside thrift triggered it. This was rather strange being in a release build
> of thrift.
> To understand if assertions are active in release builds, I modified
> PlatformSocket.h and added this close to the top:
> {noformat}
> #ifdef NDEBUG
> #error "NDEBUG IS SET: ASSERTIONS ARE IGNORED"
> #else
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> #endif
> {noformat}
> Then I built the ubuntu dockerfile and started a debian package distribution
> build:
> {noformat}
> # docker build -t thrift build/docker/ubuntu
> # docker run -v $(pwd):/thrift/src -it thrift /bin/bash
> # dpkg-buildpackage -d -tc 2>&1 | grep NDEBUG
> ./src/thrift/transport/PlatformSocket.h:25:2: error: #error "NDEBUG IS NOT
> SET: ASSERTIONS ARE ACTIVE"
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> {noformat}
> Assertions should not be active in release builds.
> Assertions really shouldn't be used; exceptions are much better for C++.
> That's covered in THRIFT-3978 however. To fix this issue, the autoconf
> system needs to set NDEBUG for release builds.
> I checked the cmake build environment and it does not suffer from this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4156) Using boost spirit instead of lex and yacc
[ https://issues.apache.org/jira/browse/THRIFT-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953935#comment-15953935 ] Jens Geyer commented on THRIFT-4156: Sounds good. Why don't we try it? And what platforms does boost spirit cover? > Using boost spirit instead of lex and yacc > -- > > Key: THRIFT-4156 > URL: https://issues.apache.org/jira/browse/THRIFT-4156 > Project: Thrift > Issue Type: Improvement > Components: Compiler (General) >Reporter: Mike Gresens > > As a developer I want to use boost spirit to get rid of lex and yacc. > This kicks dependency to lex, flex, yacc, bison or what ever. > This makes building easier, because only c++ code must be compiled. > All grammar is inside the code - all c++. No need to learn ll and yy. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #995: THRIFT-3799 Make constants to use iota
Github user astromahi closed the pull request at: https://github.com/apache/thrift/pull/995 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3799) Make constants to use iota
[ https://issues.apache.org/jira/browse/THRIFT-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953732#comment-15953732 ] ASF GitHub Bot commented on THRIFT-3799: Github user astromahi closed the pull request at: https://github.com/apache/thrift/pull/995 > Make constants to use iota > -- > > Key: THRIFT-3799 > URL: https://issues.apache.org/jira/browse/THRIFT-3799 > Project: Thrift > Issue Type: Improvement > Components: Go - Library >Reporter: Mahendran Kathirvel >Priority: Minor > Labels: easyfix > Original Estimate: 24h > Remaining Estimate: 24h > > Now, the constants and enumerations are using hardcoded values but Go has a > elegant way of doing this by using `Iota` -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4164) Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl
[ https://issues.apache.org/jira/browse/THRIFT-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953686#comment-15953686 ] ASF GitHub Bot commented on THRIFT-4164: GitHub user jeking3 opened a pull request: https://github.com/apache/thrift/pull/1235 THRIFT-4164: update openssl cleanup to match current requirements Ran ctest -T MemCheck which runs all tests through valgrind and all passed. Manually inspected the TInterruptTest which includes TSSLInterruptTest and runs the initialize and cleanup methods running valgrind interactively and no issues (and no leaks). You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeking3/thrift THRIFT-4164 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1235.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1235 commit aa18ccaaf472b06617a104f2cdbb9674e9c2bae5 Author: James E. King, III Date: 2017-04-03T15:43:54Z THRIFT-4164: update openssl cleanup to match current requirements > Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl > - > > Key: THRIFT-4164 > URL: https://issues.apache.org/jira/browse/THRIFT-4164 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Affects Versions: 0.10.0 > Environment: Ubuntu 14.04, openssl (version TBD, I believe it is a > 1.1.0 variant) >Reporter: James E. King, III >Assignee: James E. King, III > > In a project where thrift is used, i was investigating a core in an assertion > in apache::thrift::concurrency::~Mutex (pthread variety). The mutex in > question was one of the locking mutexes that thrift gives to openssl. The > core occurred in TSSLSocket::cleanupOpenSSL() where the mutexes are destroyed > (on the last line). > I suspect that we might be changing the locking callbacks too early in the > cleanup process; perhaps one of the other cleanup calls that follows it would > have released a mutex in some situations? In any case, this needs to be > investigated and I am assigning it to myself. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (THRIFT-4163) The debian package / autoconf build environment is not setting NDEBUG on production builds, leaving assertions active
[
https://issues.apache.org/jira/browse/THRIFT-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III reassigned THRIFT-4163:
--
Assignee: James E. King, III
> The debian package / autoconf build environment is not setting NDEBUG on
> production builds, leaving assertions active
> -
>
> Key: THRIFT-4163
> URL: https://issues.apache.org/jira/browse/THRIFT-4163
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Critical
>
> In a project that uses thrift I was looking at a core and found an assertion
> inside thrift triggered it. This was rather strange being in a release build
> of thrift.
> To understand if assertions are active in release builds, I modified
> PlatformSocket.h and added this close to the top:
> {noformat}
> #ifdef NDEBUG
> #error "NDEBUG IS SET: ASSERTIONS ARE IGNORED"
> #else
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> #endif
> {noformat}
> Then I built the ubuntu dockerfile and started a debian package distribution
> build:
> {noformat}
> # docker build -t thrift build/docker/ubuntu
> # docker run -v $(pwd):/thrift/src -it thrift /bin/bash
> # dpkg-buildpackage -d -tc 2>&1 | grep NDEBUG
> ./src/thrift/transport/PlatformSocket.h:25:2: error: #error "NDEBUG IS NOT
> SET: ASSERTIONS ARE ACTIVE"
> #error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
> {noformat}
> Assertions should not be active in release builds.
> Assertions really shouldn't be used; exceptions are much better for C++.
> That's covered in THRIFT-3978 however. To fix this issue, the autoconf
> system needs to set NDEBUG for release builds.
> I checked the cmake build environment and it does not suffer from this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift pull request #1235: THRIFT-4164: update openssl cleanup to match curr...
GitHub user jeking3 opened a pull request: https://github.com/apache/thrift/pull/1235 THRIFT-4164: update openssl cleanup to match current requirements Ran ctest -T MemCheck which runs all tests through valgrind and all passed. Manually inspected the TInterruptTest which includes TSSLInterruptTest and runs the initialize and cleanup methods running valgrind interactively and no issues (and no leaks). You can merge this pull request into a Git repository by running: $ git pull https://github.com/jeking3/thrift THRIFT-4164 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1235.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1235 commit aa18ccaaf472b06617a104f2cdbb9674e9c2bae5 Author: James E. King, III Date: 2017-04-03T15:43:54Z THRIFT-4164: update openssl cleanup to match current requirements --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (THRIFT-4164) Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl
James E. King, III created THRIFT-4164: -- Summary: Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl Key: THRIFT-4164 URL: https://issues.apache.org/jira/browse/THRIFT-4164 Project: Thrift Issue Type: Bug Components: C++ - Library Affects Versions: 0.10.0 Environment: Ubuntu 14.04, openssl (version TBD, I believe it is a 1.1.0 variant) Reporter: James E. King, III Assignee: James E. King, III In a project where thrift is used, i was investigating a core in an assertion in apache::thrift::concurrency::~Mutex (pthread variety). The mutex in question was one of the locking mutexes that thrift gives to openssl. The core occurred in TSSLSocket::cleanupOpenSSL() where the mutexes are destroyed (on the last line). I suspect that we might be changing the locking callbacks too early in the cleanup process; perhaps one of the other cleanup calls that follows it would have released a mutex in some situations? In any case, this needs to be investigated and I am assigning it to myself. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4163) The debian package / autoconf build environment is not setting NDEBUG on production builds, leaving assertions active
James E. King, III created THRIFT-4163:
--
Summary: The debian package / autoconf build environment is not
setting NDEBUG on production builds, leaving assertions active
Key: THRIFT-4163
URL: https://issues.apache.org/jira/browse/THRIFT-4163
Project: Thrift
Issue Type: Bug
Components: Build Process
Affects Versions: 0.10.0
Reporter: James E. King, III
Priority: Critical
In a project that uses thrift I was looking at a core and found an assertion
inside thrift triggered it. This was rather strange being in a release build
of thrift.
To understand if assertions are active in release builds, I modified
PlatformSocket.h and added this close to the top:
{noformat}
#ifdef NDEBUG
#error "NDEBUG IS SET: ASSERTIONS ARE IGNORED"
#else
#error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
#endif
{noformat}
Then I built the ubuntu dockerfile and started a debian package distribution
build:
{noformat}
# docker build -t thrift build/docker/ubuntu
# docker run -v $(pwd):/thrift/src -it thrift /bin/bash
# dpkg-buildpackage -d -tc 2>&1 | grep NDEBUG
./src/thrift/transport/PlatformSocket.h:25:2: error: #error "NDEBUG IS NOT SET:
ASSERTIONS ARE ACTIVE"
#error "NDEBUG IS NOT SET: ASSERTIONS ARE ACTIVE"
{noformat}
Assertions should not be active in release builds.
Assertions really shouldn't be used; exceptions are much better for C++.
That's covered in THRIFT-3978 however. To fix this issue, the autoconf system
needs to set NDEBUG for release builds.
I checked the cmake build environment and it does not suffer from this issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4158) minor issue in README-MSYS2.md
[
https://issues.apache.org/jira/browse/THRIFT-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953181#comment-15953181
]
Mario Emmenlauer commented on THRIFT-4158:
--
Dear @jking3, thanks for the quick response! I see now that the WITH_ variants
work, I had just not checked the
sub-CMakeLists.txt. And it seems due to the nature of the CMakeLists.txt both
BUILD_XXX and WITH_XXX are
supported. Thanks for clarifying!
I will make a PR for the MinGW64 variants of libraries soon but it will take a
few days.
> minor issue in README-MSYS2.md
> --
>
> Key: THRIFT-4158
> URL: https://issues.apache.org/jira/browse/THRIFT-4158
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.11.0
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>
> In README-MSYS2.md there are recommended cmake build flags:
> {code}
> cmake -G"MinGW Makefiles" -DCMAKE_MAKE_PROGRAM=/mingw64/bin/mingw32-make \
>-DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc.exe \
>-DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-g++.exe \
>-DWITH_BOOSTTHREADS=ON -DWITH_LIBEVENT=OFF \
>-DWITH_SHARED_LIB=OFF -DWITH_STATIC_LIB=ON \
>-DWITH_JAVA=OFF -DWITH_PYTHON=OFF -DWITH_PERL=OFF \
> {code}
> However I think they are not really correct, or am I overlooking something?
> The options WITH_JAVA, WITH_PYTHON and WITH_PERL should be
> BUILD_JAVA, BUILD_PYTHON and BUILD_PERL, respectively. At least
> I could not find the WITH_XXX variants in CMakeLists.txt.
> The options CMAKE_MAKE_PROGRAM, CMAKE_C_COMPILER and
> CMAKE_CXX_COMPILER should be optional and not required. I think
> they are rather confusing since these compilers should be the default for
> a MINGW build shell.
> Finally, the readme recommends to install
> {code}
> $ pacman -S bison flex openssl openssl-devel \
> mingw-w64-x86_64-boost mingw-w64-x86_64-cmake \
> mingw-w64-x86_64-toolchain zlib zlib-devel
> {code}
> The openssl and zlib variants used here are from MSYS2, not MinGW64.
> If there is no strong reason to use those, I think its recommended to use
> the MinGW46 variants instead:
> {code}
> $ pacman -S bison flex mingw-w64-x86_64-openssl \
> mingw-w64-x86_64-boost mingw-w64-x86_64-cmake \
> mingw-w64-x86_64-toolchain mingw-w64-x86_64-zlib
> {code}
> My suggested options "build for me" so they come with at least a bit
> of testing...
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-3823) Escape documentation while generating non escaped documetation
[
https://issues.apache.org/jira/browse/THRIFT-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953149#comment-15953149
]
ASF GitHub Bot commented on THRIFT-3823:
Github user hush-hush closed the pull request at:
https://github.com/apache/thrift/pull/1029
> Escape documentation while generating non escaped documetation
> --
>
> Key: THRIFT-3823
> URL: https://issues.apache.org/jira/browse/THRIFT-3823
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.9.3
>Reporter: maxime mouial
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> The HTML generated documentation from a .thrift don't format comments. They
> all appears as a one-liner.
> When not using the "noescape" tag, documentation comments should be displayed
> between "" tag to keep readability.
> This will allow comment such as this one to be displayed correctly (and not
> on one line):
> {code}
> /**
> * This method is doing this and that.
> *
> * @param user
> * Current identifier of the user
> *
> * @param password
> * Some password
> *
> * @return
> * Some data
> *
> * @throws ExceptionA
> * @throws ExceptionB
> */
> string doSomeStuff(
> 1: string user,
> 2: string pasword,
> ) throws (
> 1: ExceptionA userException,
> 2: ExceptionB systemException,
> )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-3823) Escape documentation while generating non escaped documetation
[
https://issues.apache.org/jira/browse/THRIFT-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953148#comment-15953148
]
ASF GitHub Bot commented on THRIFT-3823:
Github user hush-hush commented on the issue:
https://github.com/apache/thrift/pull/1029
OK, closing the PR.
> Escape documentation while generating non escaped documetation
> --
>
> Key: THRIFT-3823
> URL: https://issues.apache.org/jira/browse/THRIFT-3823
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Affects Versions: 0.9.3
>Reporter: maxime mouial
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> The HTML generated documentation from a .thrift don't format comments. They
> all appears as a one-liner.
> When not using the "noescape" tag, documentation comments should be displayed
> between "" tag to keep readability.
> This will allow comment such as this one to be displayed correctly (and not
> on one line):
> {code}
> /**
> * This method is doing this and that.
> *
> * @param user
> * Current identifier of the user
> *
> * @param password
> * Some password
> *
> * @return
> * Some data
> *
> * @throws ExceptionA
> * @throws ExceptionB
> */
> string doSomeStuff(
> 1: string user,
> 2: string pasword,
> ) throws (
> 1: ExceptionA userException,
> 2: ExceptionB systemException,
> )
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] thrift issue #1029: THRIFT-3823: Use 'pre' HTML tag when generating non esca...
Github user hush-hush commented on the issue: https://github.com/apache/thrift/pull/1029 OK, closing the PR. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #1029: THRIFT-3823: Use 'pre' HTML tag when generating n...
Github user hush-hush closed the pull request at: https://github.com/apache/thrift/pull/1029 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-4152) HTML Documentation doesn't link correctly structs
[ https://issues.apache.org/jira/browse/THRIFT-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953110#comment-15953110 ] Gonzalo Aguilar commented on THRIFT-4152: - Yes. Don't do it. We want to check what's the correct behavior it should do. And maybe adjust the patch a little bit. We did this as a hotfix for one of our customers. Since otherwise the output was wrong. Let us investigate a little bit more, since we don't know much about the compiler stuff. > HTML Documentation doesn't link correctly structs > - > > Key: THRIFT-4152 > URL: https://issues.apache.org/jira/browse/THRIFT-4152 > Project: Thrift > Issue Type: Bug > Components: HTML - Compiler >Affects Versions: 0.10.0 > Environment: Thrift Master on commit > 431732d39e89f1661dc7dddffedb2c5c1e019cc7 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar >Priority: Minor > > We discovered the html documents are not correctly generated because the > links of structs are sometimes done as Struct and sometimes as Typedef. > None of the Typedef links are working. Mainly because they are Structs in our > case and thus no link is performed. > We made a patch for structs. but we have to check if it works for the rest of > types. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] thrift pull request #639: Implements ssl sockets on c_glib
Github user gadLinux closed the pull request at: https://github.com/apache/thrift/pull/639 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift issue #639: Implements ssl sockets on c_glib
Github user gadLinux commented on the issue: https://github.com/apache/thrift/pull/639 Yes, quite old sofar. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
