[jira] [Commented] (THRIFT-5498) Fails to build with gcc 12

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491605#comment-17491605
 ] 

Mario Emmenlauer commented on THRIFT-5498:
--

I can try to look into this, probably in the current week. We do not have 
gcc-12 in our setup yet, but I guess I can find a docker container and try it 
there. Do we have time to wait with the release until then? No promise that I 
manage it this week, as there are quite many things lining up at work...

> Fails to build with gcc 12
> --
>
> Key: THRIFT-5498
> URL: https://issues.apache.org/jira/browse/THRIFT-5498
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.15.0
>Reporter: Orion Poplawski
>Priority: Major
>
> Fedora rawhide has been updated to gcc 12 and now thrift fails to build with:
> make[3]: Entering directory 
> '/builddir/build/BUILD/thrift-0.15.0/compiler/cpp'
> /bin/sh ../../libtool  {}tag=CXX   -mode=link g++ -std=c++11 -Wall 
> -Wextra -pedantic -Werror -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  
> -Wl,-z,relro -Wl,as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,-build-id=sha1 -o thrift 
> src/thrift/audit/thrift-t_audit.o src/thrift/thrift-common.o 
> src/thrift/generate/thrift-t_generator.o src/thrift/thrift-main.o 
> src/thrift/parse/thrift-parse.o src/thrift/parse/thrift-t_typedef.o 
> src/thrift/generate/thrift-t_c_glib_generator.o 
> src/thrift/generate/thrift-t_cl_generator.o 
> src/thrift/generate/thrift-t_cpp_generator.o 
> src/thrift/generate/thrift-t_d_generator.o 
> src/thrift/generate/thrift-t_dart_generator.o 
> src/thrift/generate/thrift-t_delphi_generator.o 
> src/thrift/generate/thrift-t_erl_generator.o 
> src/thrift/generate/thrift-t_go_generator.o 
> src/thrift/generate/thrift-t_gv_generator.o 
> src/thrift/generate/thrift-t_haxe_generator.o 
> src/thrift/generate/thrift-t_html_generator.o 
> src/thrift/generate/thrift-t_markdown_generator.o 
> src/thrift/generate/thrift-t_java_generator.o 
> src/thrift/generate/thrift-t_javame_generator.o 
> src/thrift/generate/thrift-t_js_generator.o 
> src/thrift/generate/thrift-t_json_generator.o 
> src/thrift/generate/thrift-t_lua_generator.o 
> src/thrift/generate/thrift-t_netstd_generator.o 
> src/thrift/generate/thrift-t_ocaml_generator.o 
> src/thrift/generate/thrift-t_perl_generator.o 
> src/thrift/generate/thrift-t_php_generator.o 
> src/thrift/generate/thrift-t_py_generator.o 
> src/thrift/generate/thrift-t_rb_generator.o 
> src/thrift/generate/thrift-t_rs_generator.o 
> src/thrift/generate/thrift-t_st_generator.o 
> src/thrift/generate/thrift-t_swift_generator.o 
> src/thrift/generate/thrift-t_xml_generator.o 
> src/thrift/generate/thrift-t_xsd_generator.o src/thrift/libparse.a -lrt 
> -lpthread 
> libtool: link: g++ std=c++11 -Wall -Wextra -pedantic -Werror -O2 
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection -Wl,-z -Wl,relro -Wl,as-needed -Wl,-z -Wl,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,-build-id=sha1 -o thrift 
> src/thrift/audit/thrift-t_audit.o src/thrift/thrift-common.o 
> src/thrift/generate/thrift-t_generator.o src/thrift/thrift-main.o 
> src/thrift/parse/thrift-parse.o src/thrift/parse/thrift-t_typedef.o 
> src/thrift/generate/thrift-t_c_glib_generator.o 
> src/thrift/generate/thrift-t_cl_generator.o 
> src/thrift/generate/thrift-t_cpp_generator.o 
> src/thrift/generate/thrift-t_d_generator.o 
> src/thrift/generate/thrift-t_dart_generator.o 
> src/thrift/generate/thrift-t_delphi_generator.o 
> src/thrift/generate/thrift-t_erl_generator.o 
> src/thrift/generate/thrift-t_go_generator.o 
> src/thrift/generate/thrift-t_gv_generator.o 
> src/thrift/generate/thrift-t_haxe_generator.o 
> src/thrift/generate/thrift-t_html_generator.o 
> src/thrift/generate/thrift-t_markdown_generator.o 
> src/thrift/generate/thrift-t_java_generator.o 
> src/thrift/generate/thrift-t_javame_generator.o 
> src/thrift/generate/thrift-t_js_generator.o 
> src/thrift/generate/thrift-t_json_generator.o 
> src/thrift/generat

[jira] [Commented] (THRIFT-5498) Fails to build with gcc 12

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491667#comment-17491667
 ] 

Mario Emmenlauer commented on THRIFT-5498:
--

Hmm, I've not gone into much detail, but it seems gcc 12 is not officially 
released yet. I'm not sure we want to wait with the thrift release for a 
compiler that's still work in progress?

In any case, it will be a bit more effort for me to get my software stack built 
with gcc-12 since its not officially released. I'd rather wait a bit to go down 
that road. But I could be convinced otherwise. What do others think?

> Fails to build with gcc 12
> --
>
> Key: THRIFT-5498
> URL: https://issues.apache.org/jira/browse/THRIFT-5498
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.15.0
>Reporter: Orion Poplawski
>Priority: Major
>
> Fedora rawhide has been updated to gcc 12 and now thrift fails to build with:
> make[3]: Entering directory 
> '/builddir/build/BUILD/thrift-0.15.0/compiler/cpp'
> /bin/sh ../../libtool  {}tag=CXX   -mode=link g++ -std=c++11 -Wall 
> -Wextra -pedantic -Werror -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  
> -Wl,-z,relro -Wl,as-needed  -Wl,-z,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,-build-id=sha1 -o thrift 
> src/thrift/audit/thrift-t_audit.o src/thrift/thrift-common.o 
> src/thrift/generate/thrift-t_generator.o src/thrift/thrift-main.o 
> src/thrift/parse/thrift-parse.o src/thrift/parse/thrift-t_typedef.o 
> src/thrift/generate/thrift-t_c_glib_generator.o 
> src/thrift/generate/thrift-t_cl_generator.o 
> src/thrift/generate/thrift-t_cpp_generator.o 
> src/thrift/generate/thrift-t_d_generator.o 
> src/thrift/generate/thrift-t_dart_generator.o 
> src/thrift/generate/thrift-t_delphi_generator.o 
> src/thrift/generate/thrift-t_erl_generator.o 
> src/thrift/generate/thrift-t_go_generator.o 
> src/thrift/generate/thrift-t_gv_generator.o 
> src/thrift/generate/thrift-t_haxe_generator.o 
> src/thrift/generate/thrift-t_html_generator.o 
> src/thrift/generate/thrift-t_markdown_generator.o 
> src/thrift/generate/thrift-t_java_generator.o 
> src/thrift/generate/thrift-t_javame_generator.o 
> src/thrift/generate/thrift-t_js_generator.o 
> src/thrift/generate/thrift-t_json_generator.o 
> src/thrift/generate/thrift-t_lua_generator.o 
> src/thrift/generate/thrift-t_netstd_generator.o 
> src/thrift/generate/thrift-t_ocaml_generator.o 
> src/thrift/generate/thrift-t_perl_generator.o 
> src/thrift/generate/thrift-t_php_generator.o 
> src/thrift/generate/thrift-t_py_generator.o 
> src/thrift/generate/thrift-t_rb_generator.o 
> src/thrift/generate/thrift-t_rs_generator.o 
> src/thrift/generate/thrift-t_st_generator.o 
> src/thrift/generate/thrift-t_swift_generator.o 
> src/thrift/generate/thrift-t_xml_generator.o 
> src/thrift/generate/thrift-t_xsd_generator.o src/thrift/libparse.a -lrt 
> -lpthread 
> libtool: link: g++ std=c++11 -Wall -Wextra -pedantic -Werror -O2 
> -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 
> -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection 
> -fcf-protection -Wl,-z -Wl,relro -Wl,as-needed -Wl,-z -Wl,now 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,-build-id=sha1 -o thrift 
> src/thrift/audit/thrift-t_audit.o src/thrift/thrift-common.o 
> src/thrift/generate/thrift-t_generator.o src/thrift/thrift-main.o 
> src/thrift/parse/thrift-parse.o src/thrift/parse/thrift-t_typedef.o 
> src/thrift/generate/thrift-t_c_glib_generator.o 
> src/thrift/generate/thrift-t_cl_generator.o 
> src/thrift/generate/thrift-t_cpp_generator.o 
> src/thrift/generate/thrift-t_d_generator.o 
> src/thrift/generate/thrift-t_dart_generator.o 
> src/thrift/generate/thrift-t_delphi_generator.o 
> src/thrift/generate/thrift-t_erl_generator.o 
> src/thrift/generate/thrift-t_go_generator.o 
> src/thrift/generate/thrift-t_gv_generator.o 
> src/thrift/generate/thrift-t_haxe_generator.o 
> src/thrift/generate/thrift-t_html_generator.o 
> src/thrift/generate/thrift-t_markdown_generator.o 
> src/thrift/generate/thrift-t_java_generator.o 
> src/thrift/generate/thrift-t_javame_generator.o 

[jira] [Commented] (THRIFT-5613) ::realloc has not been declared

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17584739#comment-17584739
 ] 

Mario Emmenlauer commented on THRIFT-5613:
--

Well the error seems to be in the headers of the compiler, which is at least a 
bit surprising. Without looking further, I would guess there is nothing simple 
that people could do to thrift to help here. A better source of help may be 
StackOverflow...

> ::realloc has not been declared
> ---
>
> Key: THRIFT-5613
> URL: https://issues.apache.org/jira/browse/THRIFT-5613
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Compiler
>Affects Versions: 0.16.0
>Reporter: chendan
>Priority: Major
>
> I want to compile thrift for arm by my company's cross compiler.
> After running bootstrap and configure with proper parameters, then run make. 
> An error occured:
> make[4]: Entering directory `/root/build/thrift-0.16.0/lib/cpp'
> depbase=`echo src/thrift/TApplicationException.lo | sed 
> 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
> /bin/sh ../../libtool  --tag=CXX   --mode=compile 
> aarch64-kedacom-linux-gnu-g++ -std=c++11 -DHAVE_CONFIG_H     -I./src 
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -march=armv8-a -Wall -Wextra 
> -pedantic -march=armv8-a -MT src/thrift/TApplicationException.lo -MD -MP -MF 
> $depbase.Tpo -c -o src/thrift/TApplicationException.lo 
> src/thrift/TApplicationException.cpp &&\
> mv -f $depbase.Tpo $depbase.Plo
> libtool: compile:  aarch64-kedacom-linux-gnu-g++ -std=c++11 -DHAVE_CONFIG_H 
> -I./src -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -march=armv8-a -Wall 
> -Wextra -pedantic -march=armv8-a -MT src/thrift/TApplicationException.lo -MD 
> -MP -MF src/thrift/.deps/TApplicationException.Tpo -c 
> src/thrift/TApplicationException.cpp  -fPIC -DPIC -o 
> src/thrift/.libs/TApplicationException.o
> In file included from 
> /opt/aarch64-kedacom-linux/aarch64-kedacom-linux-gnu/include/c++/8.3.0/ext/string_conversions.h:41,
>                  from 
> /opt/aarch64-kedacom-linux/aarch64-kedacom-linux-gnu/include/c++/8.3.0/bits/basic_string.h:6400,
>                  from 
> /opt/aarch64-kedacom-linux/aarch64-kedacom-linux-gnu/include/c++/8.3.0/string:52,
>                  from ./src/thrift/Thrift.h:37,
>                  from ./src/thrift/TApplicationException.h:23,
>                  from src/thrift/TApplicationException.cpp:20:
> /opt/aarch64-kedacom-linux/aarch64-kedacom-linux-gnu/include/c++/8.3.0/cstdlib:164:11:
>  error: ‘::realloc’ has not been declared
>    using ::realloc;
>            ^~~
> make[4]: *** [src/thrift/TApplicationException.lo] Error 1
> make[4]: Leaving directory `/root/build/thrift-0.16.0/lib/cpp'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory `/root/build/thrift-0.16.0/lib/cpp'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/root/build/thrift-0.16.0/lib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/root/build/thrift-0.16.0'
> make: *** [all] Error 2
>  
> How to solve it?
> Some people show the solution below. But that's for version 0.9.0. Not 
> suitable for 0.16.0 as no such lines in config.h.
> To delete two lines in config.h:
> *#define {color:#ff}malloc {color}rpl_malloc*
> *#define realloc rpl_realloc*



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5678) TConnectedClient: warning due to non-virtual dtor

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679449#comment-17679449
 ] 

Mario Emmenlauer commented on THRIFT-5678:
--

I'm currently travelling so I have limited internet access and could not check 
the mentioned commit.

But my two cents: for the use case of thrift, I'd make all destructors virtual. 
It comes at a (tiny) runtime cost, because virtual dispatch will be involved in 
some method lookups. But in most cases, the cost of virtual dispatch is so 
small that it can barely be measured (if you *really* want to know, for most 
current CPUs the cost becomes only relevant when the virtual class table is 
*not* in the CPU cache, so when the methods are rarely called. But in high 
performance cases, the difference is not even measurable). At the same time, 
virtual destructors brings safety in one specific use case: If user code 
derives from thrift code, and deletes an object through a base class pointer, 
there are memory leaks when the destructor is not virtual. Even if thrift 
itself may be currently safe from that kind of deletion, such code may be added 
in the future and then the problem can be easily overlooked, and even more, 
user code may run into this issue.

Therefore, long story short, making all destructors virtual comes at almost 
zero cost, but can bring a relevant benefit. It would be my choice of action.

> TConnectedClient: warning due to non-virtual dtor
> -
>
> Key: THRIFT-5678
> URL: https://issues.apache.org/jira/browse/THRIFT-5678
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.13.0, 0.14.0, 0.15.0, 0.14.1, 0.14.2, 0.16.0, 0.17.0
>Reporter: Christopher Friedt
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In TConnectedClient.h the destructor is non-virtual, which causes the warning 
> below.
> {code:java}
> In member function 'void 
> apache::thrift::server::TServerFramework::disposeConnectedClient(apache::thrift::server::TConnectedClient*)':
> lib/cpp/src/thrift/server/TServerFramework.cpp:234:3: warning: deleting 
> object of polymorphic class type 'apache::thrift::server::TConnectedClient' 
> which has non-virtual destructor might cause undefined behavior 
> [-Wdelete-non-virtual-dtor]
>   234 |   delete pClient;
>       |   ^~{code}
> Not itself a major problem, but Zephyr CI promotes all warnings to errors, 
> which causes builds to fail.
> TConnectedClient.cpp has the following line of code:
> {code:java}
> TConnectedClient::~TConnectedClient() = default;{code}
> It might be considered a regression. The commit that removed the virtual 
> qualifier was 042580f53441efe1bc5c80c89351fcb30740659e
> Suggested fix is to mark it as virtual and set it to default in the header, 
> and then delete the definition in the .cpp file.
> Alternatively, keep the .cpp dtor, but simply re-add the virtual keyword in 
> the header



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5678) TConnectedClient: warning due to non-virtual dtor

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17679583#comment-17679583
 ] 

Mario Emmenlauer commented on THRIFT-5678:
--

Thanks a lot [~cfriedt] . I would have a tiny preference to have just the 
`virtual` keyword in front of the destructor in the header, and then add a 
"normal" destructor in the implementation file. This is because some C++ 
parsers do not yet support the `= default` keywords. Its not a strong 
recommendation, just my personal preference.

> TConnectedClient: warning due to non-virtual dtor
> -
>
> Key: THRIFT-5678
> URL: https://issues.apache.org/jira/browse/THRIFT-5678
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.13.0, 0.14.0, 0.15.0, 0.14.1, 0.14.2, 0.16.0, 0.17.0
>Reporter: Christopher Friedt
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In TConnectedClient.h the destructor is non-virtual, which causes the warning 
> below.
> {code:java}
> In member function 'void 
> apache::thrift::server::TServerFramework::disposeConnectedClient(apache::thrift::server::TConnectedClient*)':
> lib/cpp/src/thrift/server/TServerFramework.cpp:234:3: warning: deleting 
> object of polymorphic class type 'apache::thrift::server::TConnectedClient' 
> which has non-virtual destructor might cause undefined behavior 
> [-Wdelete-non-virtual-dtor]
>   234 |   delete pClient;
>       |   ^~{code}
> Not itself a major problem, but Zephyr CI promotes all warnings to errors, 
> which causes builds to fail.
> TConnectedClient.cpp has the following line of code:
> {code:java}
> TConnectedClient::~TConnectedClient() = default;{code}
> It might be considered a regression. The commit that removed the virtual 
> qualifier was 042580f53441efe1bc5c80c89351fcb30740659e
> Suggested fix is to mark it as virtual and set it to default in the header, 
> and then delete the definition in the .cpp file.
> Alternatively, keep the .cpp dtor, but simply re-add the virtual keyword in 
> the header



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5660) TTransportException: create thrift::numeric_cast

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775188#comment-17775188
 ] 

Mario Emmenlauer commented on THRIFT-5660:
--

I think this is a breaking change :(

With this change in place, I can not successfully use the transport {{HEADER}} 
in C++ anymore. It fails with a {{std::bad_cast}} in 
{{{}lib/cpp/src/thrift/numeric_cast.h{}}}. The failing invocation is obviously 
wrong when looking at the arguments. But it is far from trivial to identify the 
culprit in the code, because of the automatic type promotion of C++.

The failing arguments are:
{code:java}
unsigned long i = 0;
return apache::thrift::numeric_cast(i);{code}
This should obviously not throw a {{{}std::bad_cast{}}}, but it does.

I've tried to understand where the current implementation is wrong. Without 
spending significant time, this is not trivial. My current hunch is that the 
following lines are problematic:
{code:java}
if (positive_overflow_possible && value > DstLim::max()) {{code}
and
{code:java}
if (negative_overflow_possible && (value < DstLim::lowest())) {{code}
One problem can be that {{value}} is of type {{Src}} (for example {{unsigned 
long}} in my case), whereas {{DstLim::max()}} and {{DstLim::lowest()}} are of 
type {{{}Dst{}}}. To perform the comparison, C++ will promote one or both 
types. This is actually exactly the thing that the code should prohibit, 
because it is unclear if type promotion (or casting) works correctly for the 
given types.

 

The simple solution to fix the {{HEADER}} transport is to revert commit 
6e9cbbd059. If somebody would indeed volunteer to implement a clean solution 
for a {{apache::thrift::numeric_cast()}} method, I would be willing to test and 
help, but from prior experience I can say that this is not a trivial task and 
can easily lead to unforeseen culprits.

On a related note, I think the current implementation may not be safe to use 
for non-integral types, or at least it would mostly work by chance, not by 
design. There should be a {{static_assert}} or {{enable_if}} to prohibit wrong 
usage.

> TTransportException: create thrift::numeric_cast
> 
>
> Key: THRIFT-5660
> URL: https://issues.apache.org/jira/browse/THRIFT-5660
> Project: Thrift
>  Issue Type: Sub-task
>  Components: C++ - Library
>Reporter: Christopher Friedt
>Assignee: Christopher Friedt
>Priority: Trivial
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> This adds an equivalent implementation of `boost::numeric_cast` written 
> purely in standard c++.
> The implementation is relatively trivial and reduces the dependency on 
> `boost`.
> Adapted from
> https://stackoverflow.com/a/49658950/5636218
> PR is here:
> [https://github.com/apache/thrift/pull/2689]
> See also:
> [https://github.com/zephyrproject-rtos/gsoc-2022-thrift/issues/147]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5660) TTransportException: create thrift::numeric_cast

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775188#comment-17775188
 ] 

Mario Emmenlauer edited comment on THRIFT-5660 at 10/14/23 11:27 AM:
-

I think this is a breaking change :(

With this change in place, I can not successfully use the transport {{HEADER}} 
in C++ anymore. It fails with a {{std::bad_cast}} in 
{{{}lib/cpp/src/thrift/numeric_cast.h{}}}. The failing invocation is obviously 
wrong when looking at the arguments. But it is far from trivial to identify the 
culprit in the code, because of the automatic type promotion of C++.

The failing arguments are:
{code:java}
unsigned long i = 0;
return apache::thrift::numeric_cast(i);{code}
This should not throw a {{{}std::bad_cast{}}}, because the value {{0}} can be 
correctly represented (without under- or overflow) in both types. But it does 
throw.

I've tried to understand where the current implementation is wrong. Without 
spending significant time, this is not trivial. My current hunch is that the 
following lines are problematic:
{code:java}
if (positive_overflow_possible && value > DstLim::max()) {{code}
and
{code:java}
if (negative_overflow_possible && (value < DstLim::lowest())) {{code}
One problem can be, that {{value}} is of type {{Src}} (for example {{unsigned 
long}} in my case), whereas {{DstLim::max()}} and {{DstLim::lowest()}} are of 
type {{Dst}} (for example {{int32_t}} in my case). In order to perform the 
comparison, C++ will promote one (or maybe even both?) types. Funny enough, 
this is actually exactly the thing that the code should prohibit, because it is 
unclear if type promotion (or casting) works correctly for the given types! :)

 

The simple solution is to revert commit 6e9cbbd059. If somebody would volunteer 
to implement a clean solution for an {{apache::thrift::numeric_cast()}} method, 
I would be willing to test and help. But from my prior experience, I can say 
that this is not a trivial task. It can easily lead to unforeseen culprits.

On a related note, I think the current implementation of  
{{apache::thrift::numeric_cast()}} may have further problems. I.e. it may not 
be safe to use for non-integral types. Or at least, it would mostly work by 
chance, not by design? There should be a {{static_assert}} or {{enable_if}} to 
prohibit wrong usage. Currently an unsuspecting user may use it to cast also 
floating types, in which case a precision-loss is not correctly detected.


was (Author: emmenlau):
I think this is a breaking change :(

With this change in place, I can not successfully use the transport {{HEADER}} 
in C++ anymore. It fails with a {{std::bad_cast}} in 
{{{}lib/cpp/src/thrift/numeric_cast.h{}}}. The failing invocation is obviously 
wrong when looking at the arguments. But it is far from trivial to identify the 
culprit in the code, because of the automatic type promotion of C++.

The failing arguments are:
{code:java}
unsigned long i = 0;
return apache::thrift::numeric_cast(i);{code}
This should obviously not throw a {{{}std::bad_cast{}}}, but it does.

I've tried to understand where the current implementation is wrong. Without 
spending significant time, this is not trivial. My current hunch is that the 
following lines are problematic:
{code:java}
if (positive_overflow_possible && value > DstLim::max()) {{code}
and
{code:java}
if (negative_overflow_possible && (value < DstLim::lowest())) {{code}
One problem can be that {{value}} is of type {{Src}} (for example {{unsigned 
long}} in my case), whereas {{DstLim::max()}} and {{DstLim::lowest()}} are of 
type {{{}Dst{}}}. To perform the comparison, C++ will promote one or both 
types. This is actually exactly the thing that the code should prohibit, 
because it is unclear if type promotion (or casting) works correctly for the 
given types.

 

The simple solution to fix the {{HEADER}} transport is to revert commit 
6e9cbbd059. If somebody would indeed volunteer to implement a clean solution 
for a {{apache::thrift::numeric_cast()}} method, I would be willing to test and 
help, but from prior experience I can say that this is not a trivial task and 
can easily lead to unforeseen culprits.

On a related note, I think the current implementation may not be safe to use 
for non-integral types, or at least it would mostly work by chance, not by 
design. There should be a {{static_assert}} or {{enable_if}} to prohibit wrong 
usage.

> TTransportException: create thrift::numeric_cast
> 
>
> Key: THRIFT-5660
> URL: https://issues.apache.org/jira/browse/THRIFT-5660
> Project: Thrift
>  Issue Type: Sub-task
>  Components: C++ - Library
>Reporter: Christopher Friedt
>Assignee: Christopher Friedt
>Priority: Trivial
>  Time Spent: 1h 50m
>  Remain

[jira] [Commented] (THRIFT-5660) TTransportException: create thrift::numeric_cast

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775200#comment-17775200
 ] 

Mario Emmenlauer commented on THRIFT-5660:
--

Thanks [~cfriedt] for the immediate response!

I think its nice if you consider a better implementation! However we may also 
want to consider to revert the commit until a better implementation is found. 
It may be better to live with the dependency on boost, rather than breaking one 
of the transports.

What do others think? [~jensg] ? Others?

> TTransportException: create thrift::numeric_cast
> 
>
> Key: THRIFT-5660
> URL: https://issues.apache.org/jira/browse/THRIFT-5660
> Project: Thrift
>  Issue Type: Sub-task
>  Components: C++ - Library
>Reporter: Christopher Friedt
>Assignee: Christopher Friedt
>Priority: Trivial
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> This adds an equivalent implementation of `boost::numeric_cast` written 
> purely in standard c++.
> The implementation is relatively trivial and reduces the dependency on 
> `boost`.
> Adapted from
> https://stackoverflow.com/a/49658950/5636218
> PR is here:
> [https://github.com/apache/thrift/pull/2689]
> See also:
> [https://github.com/zephyrproject-rtos/gsoc-2022-thrift/issues/147]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5773) UUID wrapper for C++

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878870#comment-17878870
 ] 

Mario Emmenlauer commented on THRIFT-5773:
--

Sorry to be a bit late to the party. I have just updated boost to 1.86.0 
(current latest), and thrift to current latest master. Now the UUID support 
does not build for me. I can see that a relevant change was in the PR for this 
issue, but I don't know if boost 1.86.0 is part of the  breaking change.

The following code does not build for me:
{code}
  TUuid(const boost::uuids::uuid& buuid) noexcept
  {
std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
  }
{code}

I think the reason is that according to 
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
 the use of the data member is now discouraged, and does not work in all cases 
any more. The error I get with clang 18 is:
{code}
[build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no 
matching function for call to 'begin'
[build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
[build]   |   ^~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
 note: candidate template ignored: could not match 'initializer_list<_Tp>' 
against 'data_type'
[build]90 | begin(initializer_list<_Tp> __ils) noexcept
[build]   | ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
 note: candidate template ignored: substitution failure [with _Container = 
const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
[build]   | ^~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
 note: candidate template ignored: substitution failure [with _Container = 
data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]63 | begin(const _Container& __cont) -> decltype(__cont.begin())
[build]   | ^  ~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
 note: candidate template ignored: could not match '_Tp[_Nm]' against 'const 
data_type'
[build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
[build]   | ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
 note: candidate template ignored: could not match 'valarray<_Tp>' against 
'const data_type'
[build]   113 |   template _Tp* begin(valarray<_Tp>&) noexcept;
[build]   |   ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
 note: candidate template ignored: could not match 'const valarray<_Tp>' 
against 'const data_type'
[build]   114 |   template const _Tp* begin(const valarray<_Tp>&) 
noexcept;
[build]   | ^
{code}

I'm not really knowledgeable with boost::uuids, but according to a quick 
search, the iterators are available directly on the uuid? So the following 
compiles for me:
{code}
  TUuid(const boost::uuids::uuid& buuid) noexcept
  {
std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
  }
{code}

Opinions?

> UUID wrapper for C++
> 
>
> Key: THRIFT-5773
> URL: https://issues.apache.org/jira/browse/THRIFT-5773
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler
>Reporter: Carel
>Assignee: Carel
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Continuation of THRIFT-5772
> Add a strong wrapper type for UUID support in C++



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (THRIFT-5773) UUID wrapper for C++

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878870#comment-17878870
 ] 

Mario Emmenlauer edited comment on THRIFT-5773 at 9/3/24 12:48 PM:
---

Sorry to be a bit late to the party. I have just updated boost to 1.86.0 
(current latest), and thrift to current latest master. Now the UUID support 
does not build for me. I can see that a relevant change was in the PR for this 
issue, but I don't know for sure if boost 1.86.0 is part of the  breaking 
change.

The following code does not build for me:
{code}
  TUuid(const boost::uuids::uuid& buuid) noexcept
  {
std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
  }
{code}

The error I get with clang 18 on Ubuntu 22.04 is:
{code}
[build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no 
matching function for call to 'begin'
[build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
[build]   |   ^~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
 note: candidate template ignored: could not match 'initializer_list<_Tp>' 
against 'data_type'
[build]90 | begin(initializer_list<_Tp> __ils) noexcept
[build]   | ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
 note: candidate template ignored: substitution failure [with _Container = 
const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
[build]   | ^~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
 note: candidate template ignored: substitution failure [with _Container = 
data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]63 | begin(const _Container& __cont) -> decltype(__cont.begin())
[build]   | ^  ~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
 note: candidate template ignored: could not match '_Tp[_Nm]' against 'const 
data_type'
[build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
[build]   | ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
 note: candidate template ignored: could not match 'valarray<_Tp>' against 
'const data_type'
[build]   113 |   template _Tp* begin(valarray<_Tp>&) noexcept;
[build]   |   ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
 note: candidate template ignored: could not match 'const valarray<_Tp>' 
against 'const data_type'
[build]   114 |   template const _Tp* begin(const valarray<_Tp>&) 
noexcept;
[build]   | ^
{code}

I think the reason is that according to 
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
 the use of the data member is now discouraged, and does not work in all cases 
any more. So it seems this broke with boost 1.86.0, but I'm not sure how well 
earlier boost versions supported this.

I'm not really knowledgeable with boost::uuids. But according to a quick 
search, the iterators are available directly on the uuid, instead of the data 
member?! So the following compiles for me:
{code}
  TUuid(const boost::uuids::uuid& buuid) noexcept
  {
std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
  }
{code}

Highlight: Remove the {{.data}} from {{buuid}} in two places.

Opinions?


was (Author: emmenlau):
Sorry to be a bit late to the party. I have just updated boost to 1.86.0 
(current latest), and thrift to current latest master. Now the UUID support 
does not build for me. I can see that a relevant change was in the PR for this 
issue, but I don't know if boost 1.86.0 is part of the  breaking change.

The following code does not build for me:
{code}
  TUuid(const boost::uuids::uuid& buuid) noexcept
  {
std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
  }
{code}

I think the reason is that according to 
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
 the use of the data member is now discouraged, and does not work in all cases 
any more. The error I get with clang 18 is:
{code}
[build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no 
matching function for call to 'begin'
[build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
[build]   |   ^~

[jira] [Created] (THRIFT-5816) Fix UUID for boost 1.86.0 (change in {{data}} member usage)

[Mario Emmenlauer (Jira)]

Mario Emmenlauer created THRIFT-5816:


 Summary: Fix UUID for boost 1.86.0 (change in {{data}} member 
usage)
 Key: THRIFT-5816
 URL: https://issues.apache.org/jira/browse/THRIFT-5816
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
Affects Versions: 0.20.0
Reporter: Mario Emmenlauer
Assignee: Carel


I have just updated boost to 1.86.0 (current latest), and thrift to current 
latest master. Now the UUID support does not build for me. I can see that a 
relevant change was in the PR for this issue, but I don't know for sure if 
boost 1.86.0 is part of the  breaking change.

The following code does not build for me:
{code}
  TUuid(const boost::uuids::uuid& buuid) noexcept
  {
std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
  }
{code}

The error I get with clang 18 on Ubuntu 22.04 is:
{code}
[build] /data/tmp/Debug/thrift/lib/cpp/src/thrift/TUuid.h:93:15: error: no 
matching function for call to 'begin'
[build]93 | std::copy(std::begin(buuid.data), std::end(buuid.data), 
std::begin(this->data_));
[build]   |   ^~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/initializer_list:90:5:
 note: candidate template ignored: could not match 'initializer_list<_Tp>' 
against 'data_type'
[build]90 | begin(initializer_list<_Tp> __ils) noexcept
[build]   | ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:52:5:
 note: candidate template ignored: substitution failure [with _Container = 
const data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]52 | begin(_Container& __cont) -> decltype(__cont.begin())
[build]   | ^~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:63:5:
 note: candidate template ignored: substitution failure [with _Container = 
data_type]: no member named 'begin' in 'boost::uuids::uuid::data_type'
[build]63 | begin(const _Container& __cont) -> decltype(__cont.begin())
[build]   | ^  ~
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:95:5:
 note: candidate template ignored: could not match '_Tp[_Nm]' against 'const 
data_type'
[build]95 | begin(_Tp (&__arr)[_Nm]) noexcept
[build]   | ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:113:31:
 note: candidate template ignored: could not match 'valarray<_Tp>' against 
'const data_type'
[build]   113 |   template _Tp* begin(valarray<_Tp>&) noexcept;
[build]   |   ^
[build] 
/usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/range_access.h:114:37:
 note: candidate template ignored: could not match 'const valarray<_Tp>' 
against 'const data_type'
[build]   114 |   template const _Tp* begin(const valarray<_Tp>&) 
noexcept;
[build]   | ^
{code}

I think the reason is that according to 
https://www.boost.org/doc/libs/1_86_0/libs/uuid/doc/html/uuid.html#changes_changes_in_boost_1_86_0_major_update,
 the use of the data member is now discouraged, and does not work in all cases 
any more. So it seems this broke with boost 1.86.0, but I'm not sure how well 
earlier boost versions supported this.

I'm not really knowledgeable with boost::uuids. But according to a quick 
search, the iterators are available directly on the uuid, instead of the data 
member?! So the following compiles for me:
{code}
  TUuid(const boost::uuids::uuid& buuid) noexcept
  {
std::copy(std::begin(buuid), std::end(buuid), std::begin(this->data_));
  }
{code}

Highlight: Remove the {{.data}} from {{buuid}} in two places.

Opinions?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (THRIFT-5773) UUID wrapper for C++

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-5773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878900#comment-17878900
 ] 

Mario Emmenlauer commented on THRIFT-5773:
--

The follow-up is now in https://issues.apache.org/jira/browse/THRIFT-5816

> UUID wrapper for C++
> 
>
> Key: THRIFT-5773
> URL: https://issues.apache.org/jira/browse/THRIFT-5773
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Compiler
>Reporter: Carel
>Assignee: Carel
>Priority: Major
> Fix For: 0.21.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Continuation of THRIFT-5772
> Add a strong wrapper type for UUID support in C++



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (THRIFT-4158) minor issue in README-MSYS2.md

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4158:


 Summary: 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: 1.0
Reporter: Mario Emmenlauer


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] [Created] (THRIFT-4159) Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4159:


 Summary: Building tests fails on MSYS2 (MinGW64) due to a (small?) 
linker error
 Key: THRIFT-4159
 URL: https://issues.apache.org/jira/browse/THRIFT-4159
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Affects Versions: 1.0
 Environment: MSYS2 MinGW64 compiler gcc-6.3
Reporter: Mario Emmenlauer


When I build thrift in static mode with cmake, and I enable BUILD_TESTING,
I get a linker error:
{code}
Scanning dependencies of target SecurityTest
[ 65%] Building CXX object 
lib/cpp/test/CMakeFiles/SecurityTest.dir/SecurityTest.cpp.obj
[ 66%] Linking CXX executable ../../../bin/SecurityTest.exe
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcb3): 
undefined reference to `apache::thrift::transport::TWinsockSingleton::create()'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcc8): 
undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcf8): 
undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfa3): 
undefined reference to `thrift_fcntl'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfc0): 
undefined reference to `thrift_fcntl'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x1127): 
undefined reference to `thrift_sleep(unsigned int)'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x200c): 
undefined reference to `thrift_poll'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x212e): 
undefined reference to `thrift_fcntl'
../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x214a): 
undefined reference to `thrift_fcntl'
../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x211e): undefined 
reference to `thrift_poll'
../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x21cd): undefined 
reference to `thrift_poll'
../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a1a): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a36): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58da): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58f6): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TOutput.cpp.obj):TOutput.cpp:(.text+0x54): undefined 
reference to `thrift_ctime_r(long long const*, char*)'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x1e76): undefined 
reference to `thrift_poll'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25a0): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25c5): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x26ee): undefined 
reference to `thrift_poll'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2749): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2a0a): undefined 
reference to `thrift_fcntl'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x35f1): undefined 
reference to `apache::thrift::transport::TWinsockSingleton::create()'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3a44): undefined 
reference to `thrift_gettimeofday(timeval*, timezone*)'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3aaf): undefined 
reference to `thrift_poll'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3cfc): undefined 
reference to `thrift_gettimeofday(timeval*, timezone*)'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3d3f): undefined 
reference to `thrift_usleep(unsigned int)'
../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x6443): undefined 
reference to `apache::thrift::transport::TWinsockSingleton::create()'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [lib/cpp/test/CMakeFiles/SecurityTest.dir/build.make:116: 
bin/SecurityTest.exe] Error 1
make[1]: *** [CMakeFiles/Makefile2:1269: 
lib/cpp/test/CMakeFiles/SecurityTest.dir/all] Error 2
make: *** [Makefile:161: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
{code}

Typically this comes from the fact that MSYS2 is more picky about undefined
symbols than other platforms are. The symbols look a bit like they would
be defined in a basic thrift library. Could you please check if the tests
must link the thrift libraries and/or if a library may be missing there?




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-4158) minor issue in README-MSYS2.md

[Mario Emmenlauer (JIRA)]

[ 
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-4159) Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961403#comment-15961403
 ] 

Mario Emmenlauer commented on THRIFT-4159:
--

I checked, but sadly it does not help. I tried now various build options from 
your MSYS2 and MinGW
appveyor configs, but I always end up with the same linker error from above. Is 
it possible that my
MSYS2 is newer, or some other difference in the environment?

> Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error
> --
>
> Key: THRIFT-4159
> URL: https://issues.apache.org/jira/browse/THRIFT-4159
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
> Environment: MSYS2 MinGW64 compiler gcc-6.3
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>
> When I build thrift in static mode with cmake, and I enable BUILD_TESTING,
> I get a linker error:
> {code}
> Scanning dependencies of target SecurityTest
> [ 65%] Building CXX object 
> lib/cpp/test/CMakeFiles/SecurityTest.dir/SecurityTest.cpp.obj
> [ 66%] Linking CXX executable ../../../bin/SecurityTest.exe
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcb3): 
> undefined reference to 
> `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcc8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcf8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfa3): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfc0): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x1127): 
> undefined reference to `thrift_sleep(unsigned int)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x200c): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x212e): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x214a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x211e): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x21cd): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a1a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a36): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58da): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58f6): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TOutput.cpp.obj):TOutput.cpp:(.text+0x54): undefined 
> reference to `thrift_ctime_r(long long const*, char*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x1e76): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25a0): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25c5): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x26ee): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2749): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2a0a): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x35f1): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3a44): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3aaf): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3cfc): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3d3f): undefined 
> reference to `thrift_usleep(unsigned int)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x6443): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [lib/cpp/test/CMakeFiles/SecurityTest.dir/build.make:116: 
> bin/SecurityTest.exe] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1269: 
> lib/cpp/test/CMakeFile

[jira] [Commented] (THRIFT-4159) Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961414#comment-15961414
 ] 

Mario Emmenlauer commented on THRIFT-4159:
--

Aha. In lib/cpp/CMakeLists.txt it reads:
{code}
if (WIN32 AND NOT MSYS)
list(APPEND thriftcpp_SOURCES
src/thrift/windows/TWinsockSingleton.cpp
src/thrift/windows/SocketPair.cpp
src/thrift/windows/GetTimeOfDay.cpp
src/thrift/windows/WinFcntl.cpp
)
{code}
So this seems to disable src/thrift/windows/WinFcntl.cpp on MSYS2. The 
functions that are missing for me are
mostly (possibly all?) defined in this WinFcntl.cpp. Should this possibly be 
enabled on MSYS2, or why is it
disabled?

> Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error
> --
>
> Key: THRIFT-4159
> URL: https://issues.apache.org/jira/browse/THRIFT-4159
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
> Environment: MSYS2 MinGW64 compiler gcc-6.3
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>
> When I build thrift in static mode with cmake, and I enable BUILD_TESTING,
> I get a linker error:
> {code}
> Scanning dependencies of target SecurityTest
> [ 65%] Building CXX object 
> lib/cpp/test/CMakeFiles/SecurityTest.dir/SecurityTest.cpp.obj
> [ 66%] Linking CXX executable ../../../bin/SecurityTest.exe
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcb3): 
> undefined reference to 
> `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcc8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcf8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfa3): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfc0): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x1127): 
> undefined reference to `thrift_sleep(unsigned int)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x200c): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x212e): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x214a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x211e): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x21cd): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a1a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a36): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58da): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58f6): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TOutput.cpp.obj):TOutput.cpp:(.text+0x54): undefined 
> reference to `thrift_ctime_r(long long const*, char*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x1e76): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25a0): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25c5): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x26ee): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2749): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2a0a): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x35f1): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3a44): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3aaf): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3cfc): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3d3f): undefined 
> reference to `thrift_usleep(unsigned int)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x6443): undefined 
> reference to `apache::thrift::tr

[jira] [Commented] (THRIFT-4159) Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961456#comment-15961456
 ] 

Mario Emmenlauer commented on THRIFT-4159:
--

Ok I can confirm that when I modify in lib/cpp/CMakeLists.txt:
{code}
-if (WIN32 AND NOT MSYS)
+if (WIN32)
{code}
then the thrift build works on Windows 7 with MSYS2 x86 and x64 successfully.
I did not go far beyond the build and running the test suite, that both work.

> Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error
> --
>
> Key: THRIFT-4159
> URL: https://issues.apache.org/jira/browse/THRIFT-4159
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
> Environment: MSYS2 MinGW64 compiler gcc-6.3
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>
> When I build thrift in static mode with cmake, and I enable BUILD_TESTING,
> I get a linker error:
> {code}
> Scanning dependencies of target SecurityTest
> [ 65%] Building CXX object 
> lib/cpp/test/CMakeFiles/SecurityTest.dir/SecurityTest.cpp.obj
> [ 66%] Linking CXX executable ../../../bin/SecurityTest.exe
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcb3): 
> undefined reference to 
> `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcc8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcf8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfa3): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfc0): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x1127): 
> undefined reference to `thrift_sleep(unsigned int)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x200c): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x212e): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x214a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x211e): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x21cd): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a1a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a36): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58da): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58f6): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TOutput.cpp.obj):TOutput.cpp:(.text+0x54): undefined 
> reference to `thrift_ctime_r(long long const*, char*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x1e76): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25a0): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25c5): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x26ee): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2749): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2a0a): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x35f1): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3a44): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3aaf): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3cfc): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3d3f): undefined 
> reference to `thrift_usleep(unsigned int)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x6443): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [lib/cpp/test/CMakeFiles/SecurityTest.dir/build.make:116: 
> bin/SecurityTest.exe] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1269: 
> lib/cpp/test/C

[jira] [Commented] (THRIFT-4159) Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961460#comment-15961460
 ] 

Mario Emmenlauer commented on THRIFT-4159:
--

See https://github.com/apache/thrift/pull/1248

> Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error
> --
>
> Key: THRIFT-4159
> URL: https://issues.apache.org/jira/browse/THRIFT-4159
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
> Environment: MSYS2 MinGW64 compiler gcc-6.3
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>
> When I build thrift in static mode with cmake, and I enable BUILD_TESTING,
> I get a linker error:
> {code}
> Scanning dependencies of target SecurityTest
> [ 65%] Building CXX object 
> lib/cpp/test/CMakeFiles/SecurityTest.dir/SecurityTest.cpp.obj
> [ 66%] Linking CXX executable ../../../bin/SecurityTest.exe
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcb3): 
> undefined reference to 
> `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcc8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcf8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfa3): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfc0): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x1127): 
> undefined reference to `thrift_sleep(unsigned int)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x200c): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x212e): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x214a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x211e): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x21cd): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a1a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a36): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58da): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58f6): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TOutput.cpp.obj):TOutput.cpp:(.text+0x54): undefined 
> reference to `thrift_ctime_r(long long const*, char*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x1e76): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25a0): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25c5): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x26ee): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2749): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2a0a): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x35f1): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3a44): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3aaf): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3cfc): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3d3f): undefined 
> reference to `thrift_usleep(unsigned int)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x6443): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [lib/cpp/test/CMakeFiles/SecurityTest.dir/build.make:116: 
> bin/SecurityTest.exe] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1269: 
> lib/cpp/test/CMakeFiles/SecurityTest.dir/all] Error 2
> make: *** [Makefile:161: all] Error 2
> ==> ERROR: A failure occurred in build().
> Aborting...
> {code}
> Typically this comes from the fact that MSYS2 is more picky about unde

[jira] [Commented] (THRIFT-4158) minor issue in README-MSYS2.md

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15961913#comment-15961913
 ] 

Mario Emmenlauer commented on THRIFT-4158:
--

See the PR here: https://github.com/apache/thrift/pull/1247
There where errors in the build but (AFAIK) not related to MSYS2 / MinGW build, 
so I hope the PR is good?

> 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-4159) Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962078#comment-15962078
 ] 

Mario Emmenlauer commented on THRIFT-4159:
--

Thanks! I have made an "official" MSYS2 package for thrift now. Once the PR is 
merged, thrift
binary can be installed via pacman. PR here: 
https://github.com/Alexpux/MINGW-packages/pull/2379

> Building tests fails on MSYS2 (MinGW64) due to a (small?) linker error
> --
>
> Key: THRIFT-4159
> URL: https://issues.apache.org/jira/browse/THRIFT-4159
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
> Environment: MSYS2 MinGW64 compiler gcc-6.3
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> When I build thrift in static mode with cmake, and I enable BUILD_TESTING,
> I get a linker error:
> {code}
> Scanning dependencies of target SecurityTest
> [ 65%] Building CXX object 
> lib/cpp/test/CMakeFiles/SecurityTest.dir/SecurityTest.cpp.obj
> [ 66%] Linking CXX executable ../../../bin/SecurityTest.exe
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcb3): 
> undefined reference to 
> `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcc8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xcf8): 
> undefined reference to `thrift_socketpair(int, int, int, unsigned long long*)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfa3): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0xfc0): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x1127): 
> undefined reference to `thrift_sleep(unsigned int)'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x200c): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x212e): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TServerSocket.cpp.obj):TServerSocket.cpp:(.text+0x214a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x211e): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x21cd): 
> undefined reference to `thrift_poll'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a1a): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x4a36): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58da): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TSSLSocket.cpp.obj):TSSLSocket.cpp:(.text+0x58f6): 
> undefined reference to `thrift_fcntl'
> ../../libthrift.a(TOutput.cpp.obj):TOutput.cpp:(.text+0x54): undefined 
> reference to `thrift_ctime_r(long long const*, char*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x1e76): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25a0): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x25c5): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x26ee): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2749): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x2a0a): undefined 
> reference to `thrift_fcntl'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x35f1): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3a44): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3aaf): undefined 
> reference to `thrift_poll'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3cfc): undefined 
> reference to `thrift_gettimeofday(timeval*, timezone*)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x3d3f): undefined 
> reference to `thrift_usleep(unsigned int)'
> ../../libthrift.a(TSocket.cpp.obj):TSocket.cpp:(.text+0x6443): undefined 
> reference to `apache::thrift::transport::TWinsockSingleton::create()'
> collect2.exe: error: ld returned 1 exit status
> make[2]: *** [lib/cpp/test/CMakeFiles/SecurityTest.dir/build.make:116: 
> bin/SecurityTest.exe] Error 1
> make[1]: *** [CMakeFiles/Makefile2:1269: 
> lib/cpp/test/CMakeFiles/SecurityTest.dir/all] Error 2
> mak

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972322#comment-15972322
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

Maybe its possible to have both options available with the help of defines? 
I.e. one could use a dedicated header with something like
{code}
#if USE_BOOST_SHARED_PTR
#include 
#define shared_ptr_namespace boost
#else
#include 
#define shared_ptr_namespace std
#endif
{code}

And in the code change:
{code}
-boost::shared_ptr socket(new TSocket("127.0.0.1", port));
+shared_ptr_namespace::shared_ptr socket(new TSocket("127.0.0.1", 
port));
{code}

Admittedly, this does not read as fluent as the current code does, but I think 
it would
encapsulate the boost namespace quite nicely, and allow users to switch. 
Personally
I use std::shared_ptr everywhere in my code, and nowadays many users have a 
c++11
compiler?


> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Task
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Priority: Minor
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972900#comment-15972900
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

This looks like a very suitable solution, and only moderate effort to make. I 
think many
people nowadays use std::shared_ptr so I think the benefit is worthwhile, what 
do you think?

Could you implement this change? Or should I give it a try, and would a PR with 
this change
be accepted?


> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Task
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Priority: Minor
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980020#comment-15980020
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

Great work, I'm very curious to test it!

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980411#comment-15980411
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

Two thumbs up for the great work!!!

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034550#comment-16034550
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

Dear [~jking3], is there a cummulative patch with all your changes with respect 
to all your C++11 related work?

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16034550#comment-16034550
 ] 

Mario Emmenlauer edited comment on THRIFT-2221 at 6/2/17 2:01 PM:
--

Dear [~jking3],
I tried the patch from 
https://github.com/jeking3/thrift/commit/d6d75b42bd04cefd9eb1b7ea7b8ecdee168b7c01
 against the latest thrift trunk (2b1b32c) but the build fails for me with:
{code}
In file included from 
/data/thrift-trunk-r2b1b32c/lib/cpp/src/thrift/transport/TTransport.h:24:0,
 from 
/data/thrift-trunk-r2b1b32c/lib/cpp/src/thrift/protocol/TProtocol.h:28,
 from 
/data/thrift-trunk-r2b1b32c/lib/cpp/src/thrift/TApplicationException.cpp:21:
/data/thrift-trunk-r2b1b32c/lib/cpp/src/thrift/stdcxx.h:127:24: error: invalid 
use of template-name ‘std::unique_ptr’ without an argument list
 using scoped_ptr = std::unique_ptr;
^
{code}
Am I doing something wrong? Do I need to specifically configure cmake if I want 
to use the C++11 shared_ptr?


was (Author: emmenlau):
Dear [~jking3], is there a cummulative patch with all your changes with respect 
to all your C++11 related work?

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036097#comment-16036097
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

Thanks [~msg-72]! This is the key. When I change
{code}
+  #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates 
>= 200704)
+using scoped_ptr = std::unique_ptr;
+  #else
{code}
to
{code}
+  #if __cplusplus >= 201103L && (defined(__clang__) || __cpp_alias_templates 
>= 200704)
+template  using scoped_ptr = std::unique_ptr;
+  #else
{code}
it builds fine! I'm very curious to test the C++11 pointers, thanks! Can't wait 
for the rest of the C++11 code cleanup...

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036380#comment-16036380
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

The patch works on several Linux derivates, but not on all. On CentOS 7.3 and 
Ubuntu 14.04 I get an error:
{code}
[...]
In file included from 
/data/thrift-trunk-r2b1b32c/lib/cpp/src/thrift/async/TAsyncChannel.h:23:0,
 from 
/data/thrift-trunk-r2b1b32c/lib/cpp/src/thrift/async/TAsyncChannel.cpp:20:
/data/thrift-trunk-r2b1b32c/lib/cpp/src/thrift/stdcxx.h:129:20: error: 
'boost::scoped_ptr' has not been declared
 using ::boost::scoped_ptr;
^
{code}

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16036853#comment-16036853
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

I think this is the problem, but I do not understand the first '#if' well 
enough to solve it.
Why is boost/scoped_ptr.hpp included if "__cplusplus < 201103L" ? I do not 
fully understand
the multiple conditions in this file, maybe [~jking3] can help?

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4239:


 Summary: Latest thrift breaks java build with 
handleRuntimeExceptions
 Key: THRIFT-4239
 URL: https://issues.apache.org/jira/browse/THRIFT-4239
 Project: Thrift
  Issue Type: Bug
  Components: Java - Compiler
Affects Versions: 0.11.0
 Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
Reporter: Mario Emmenlauer


With the latest trunk I can no longer build my Java thrift example. I get an 
error that handleRuntimeExceptions does not Override. It seems related to these 
new additions in the generated Java code:
{code}
-  @Override
-  protected boolean handleRuntimeExceptions() {
-return false;
-  }
{code}
With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16067241#comment-16067241
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

The exact error message is pointing to the @Override of 
handleRuntimeExceptions():
{code}
[...]/APIAccess.java:398: error: method does not override or implement a method 
from a supertype
  @Override
  ^
{code}


> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16068997#comment-16068997
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

I also found THRIFT-1805, but admittedly I don't fully understand how this 
affects my problem.

I did some regression testing and could find that thrift 3db41fa (from 
2017-04-07) does not
show the problem, whereas 2b1b32c (from 2017-05-30) is affected. I could not 
narrow it down
further yet.

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071377#comment-16071377
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

Thanks a lot [~jensg]. Does it help if I share my code? I'm using just a minor 
rewrite of the simple java Thrift example. If I'm not completely mistaken, I 
get one {noformat}@Override protected boolean handleRuntimeExceptions() { } 
{noformat} for every function that can throw an exception, is that reasonable?

Is this issue really specific to me, or can someone reproduce the problem? 


> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072815#comment-16072815
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

Great! Can you send me your mail address to emmenla...@gmx.de ? I have prepared 
something like a minimal test case including gradle build script.

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072815#comment-16072815
 ] 

Mario Emmenlauer edited comment on THRIFT-4239 at 7/3/17 7:23 PM:
--

Great! Can you send me your mail address? I have prepared something like a 
minimal test case including gradle build script.


was (Author: emmenlau):
Great! Can you send me your mail address to emmenla...@gmx.de ? I have prepared 
something like a minimal test case including gradle build script.

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16072833#comment-16072833
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

Ok, mail is sent. Let me know if you did *not* get the email. Thanks for your 
help!

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16079714#comment-16079714
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

Then it would be helpful if you also add a better hint to what your apache.org 
email address could be :-) :-)
I guessed ctubbsii at apache.org, is that wrong?

Or just use this link: http://data.marssoft.de/THRIFT-4239.tar.gz

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4252:


 Summary: Cannot shutdown Java server when clients are still 
connected
 Key: THRIFT-4252
 URL: https://issues.apache.org/jira/browse/THRIFT-4252
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.10.0
Reporter: Mario Emmenlauer


I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
that the same problem still exists in the Java servers, and I'm affected by it. 
Short summary: I can not shut down the Java server (neither TSimpleServer nor 
TThreadedServer) while clients are still
connected. That is pretty bad, because essentially the clients are not under by 
control, but
they can essentially "block" server maintenance operations by blocking the 
shutdown.

In more detail:
I have a Java TSimpleServer runnable in a thread running. The main thread 
eventually asks the server to stop(). But they seem to ignore the request. I 
checked the code of TSimpleServer.java and I'm under the impression that the 
innermost loop the server does not poll the variable stopped_ or does it? 
Looking at 
https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
 from line 76:
{code}
  while (true) {
if (eventHandler_ != null) {
  eventHandler_.processContext(connectionContext, inputTransport, 
outputTransport);
}
if(!processor.process(inputProtocol, outputProtocol)) {
  break;
}
  }
{code}

I found that this loop is only interrupted if the client disconnects. I tried 
changing `while(true)` for `while(!stopped_)` but that did not help. I guess 
that one of the methods in the loop must be blocking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4252:
-
Description: 
I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
that the same problem still exists in the Java servers, and I'm affected by it. 
Short summary: I can not shut down the Java server (neither TSimpleServer nor 
TThreadedServer) while clients are still connected. That is pretty bad, because 
essentially the clients are not under by control, but they can essentially 
"block" server maintenance operations by blocking the shutdown.

*In more detail:* I have a Java TSimpleServer runnable in a thread running. The 
main thread eventually asks the server to stop(). But they seem to ignore the 
request. I checked the code of TSimpleServer.java and I'm under the impression 
that the innermost loop the server does not poll the variable stopped_ or does 
it? Looking at 
https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
 from line 76:
{code}
  while (true) {
if (eventHandler_ != null) {
  eventHandler_.processContext(connectionContext, inputTransport, 
outputTransport);
}
if(!processor.process(inputProtocol, outputProtocol)) {
  break;
}
  }
{code}

I found that this loop is only interrupted if the client disconnects. I tried 
changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
guess that one of the methods in the loop must be blocking.

  was:
I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
that the same problem still exists in the Java servers, and I'm affected by it. 
Short summary: I can not shut down the Java server (neither TSimpleServer nor 
TThreadedServer) while clients are still
connected. That is pretty bad, because essentially the clients are not under by 
control, but
they can essentially "block" server maintenance operations by blocking the 
shutdown.

In more detail:
I have a Java TSimpleServer runnable in a thread running. The main thread 
eventually asks the server to stop(). But they seem to ignore the request. I 
checked the code of TSimpleServer.java and I'm under the impression that the 
innermost loop the server does not poll the variable stopped_ or does it? 
Looking at 
https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
 from line 76:
{code}
  while (true) {
if (eventHandler_ != null) {
  eventHandler_.processContext(connectionContext, inputTransport, 
outputTransport);
}
if(!processor.process(inputProtocol, outputProtocol)) {
  break;
}
  }
{code}

I found that this loop is only interrupted if the client disconnects. I tried 
changing `while(true)` for `while(!stopped_)` but that did not help. I guess 
that one of the methods in the loop must be blocking.


> Cannot shutdown Java server when clients are still connected
> 
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
> that the same problem still exists in the Java servers, and I'm affected by 
> it. Short summary: I can not shut down the Java server (neither TSimpleServer 
> nor TThreadedServer) while clients are still connected. That is pretty bad, 
> because essentially the clients are not under by control, but they can 
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running. 
> The main thread eventually asks the server to stop(). But they seem to ignore 
> the request. I checked the code of TSimpleServer.java and I'm under the 
> impression that the innermost loop the server does not poll the variable 
> stopped_ or does it? Looking at 
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
>  from line 76:
> {code}
>   while (true) {
> if (eventHandler_ != null) {
>   eventHandler_.processContext(connectionContext, inputTransport, 
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
>   break;
> }
>   }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried 
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
> guess that one of the methods in the loop must be blocking.



--
Thi

[jira] [Commented] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089776#comment-16089776
 ] 

Mario Emmenlauer commented on THRIFT-4239:
--

Dear [~ctubbsii], thanks a lot!!! You are right, this is the issue! Dammit, 
that was not too easy to find for me, thanks a lot for your help.

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer closed THRIFT-4239.


Fixed, thanks.

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (THRIFT-4239) Latest thrift breaks java build with handleRuntimeExceptions

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer resolved THRIFT-4239.
--
Resolution: Fixed

> Latest thrift breaks java build with handleRuntimeExceptions
> 
>
> Key: THRIFT-4239
> URL: https://issues.apache.org/jira/browse/THRIFT-4239
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler
>Affects Versions: 0.11.0
> Environment: Ubuntu 16.04 LTS with Oracle Java 1.8 JDK
>Reporter: Mario Emmenlauer
>
> With the latest trunk I can no longer build my Java thrift example. I get an 
> error that handleRuntimeExceptions does not Override. It seems related to 
> these new additions in the generated Java code:
> {code}
> -  @Override
> -  protected boolean handleRuntimeExceptions() {
> -return false;
> -  }
> {code}
> With thrift 0.10.0 the method handleRuntimeExceptions (and the error) are not 
> present.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-2221) Generate c++ code with std::shared_ptr instead of boost::shared_ptr.

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16122089#comment-16122089
 ] 

Mario Emmenlauer commented on THRIFT-2221:
--

Thanks again [~jking] , super great work and its highly appreciated! I'm very 
much looking forward to this release!

> Generate c++ code with std::shared_ptr instead of boost::shared_ptr.
> 
>
> Key: THRIFT-2221
> URL: https://issues.apache.org/jira/browse/THRIFT-2221
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.9.1
> Environment: C++11 compilers with std::shared_ptr support
>Reporter: Chris Stylianou
>Assignee: James E. King, III
>  Labels: c++11, compiler, thrift
> Fix For: 0.11.0
>
>
> Most modern compilers now have full support for std::shared_ptr when enable 
> with c++11 flags. It would be nice to have the option to generate code that 
> uses this instead of boost::shared_ptr. This would enable us to remove 
> another boost dependency, on the road to a dependency-free thrift library :)
> Solution summary (so you don't need to wade through the comments):
> A new header, , creates the namespace apache::thrift::stdcxx 
> and aliases the proper std:: or boost:: constructs depending on the 
> capabilities of the environment and whether any build flags are used to force 
> an override of this behavior.  All code throughout the project now uses 
> stdcxx:: for all smart_ptr and functional (bind, function, placeholders, _1, 
> _2, ...) constructs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16124948#comment-16124948
 ] 

Mario Emmenlauer commented on THRIFT-4252:
--

I have the same problem also with the Java thread pool server, so it seems this 
is an expected behavior of the Java servers. However, since this has been fixed 
for the C++ servers, I think it would be sensible to also fix the issue for the 
Java servers.

With the current behavior, a malicious client can basically prohibit clean 
server shutdown (and all it needs to do is keep the connection open). More 
realisticly, the client does not need to be malicious, it could just hang or 
forget to disconnect and thereby "locking" the server in an open API connection.

> Cannot shutdown Java server when clients are still connected
> 
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
> that the same problem still exists in the Java servers, and I'm affected by 
> it. Short summary: I can not shut down the Java server (neither TSimpleServer 
> nor TThreadedServer) while clients are still connected. That is pretty bad, 
> because essentially the clients are not under by control, but they can 
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running. 
> The main thread eventually asks the server to stop(). But they seem to ignore 
> the request. I checked the code of TSimpleServer.java and I'm under the 
> impression that the innermost loop the server does not poll the variable 
> stopped_ or does it? Looking at 
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
>  from line 76:
> {code}
>   while (true) {
> if (eventHandler_ != null) {
>   eventHandler_.processContext(connectionContext, inputTransport, 
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
>   break;
> }
>   }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried 
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
> guess that one of the methods in the loop must be blocking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16160353#comment-16160353
 ] 

Mario Emmenlauer commented on THRIFT-4252:
--

Can someone please confirm that I'm on the right track? Is this an expected 
behavior or a bug? Could you give me a hint if changing this behavior would 
require significant effort or if there is something simple that could be done 
about it? Thanks for your help!

> Cannot shutdown Java server when clients are still connected
> 
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
> that the same problem still exists in the Java servers, and I'm affected by 
> it. Short summary: I can not shut down the Java server (neither TSimpleServer 
> nor TThreadedServer) while clients are still connected. That is pretty bad, 
> because essentially the clients are not under by control, but they can 
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running. 
> The main thread eventually asks the server to stop(). But they seem to ignore 
> the request. I checked the code of TSimpleServer.java and I'm under the 
> impression that the innermost loop the server does not poll the variable 
> stopped_ or does it? Looking at 
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
>  from line 76:
> {code}
>   while (true) {
> if (eventHandler_ != null) {
>   eventHandler_.processContext(connectionContext, inputTransport, 
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
>   break;
> }
>   }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried 
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
> guess that one of the methods in the loop must be blocking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16205985#comment-16205985
 ] 

Mario Emmenlauer commented on THRIFT-4252:
--

Anyone?

> Cannot shutdown Java server when clients are still connected
> 
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
> that the same problem still exists in the Java servers, and I'm affected by 
> it. Short summary: I can not shut down the Java server (neither TSimpleServer 
> nor TThreadedServer) while clients are still connected. That is pretty bad, 
> because essentially the clients are not under by control, but they can 
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running. 
> The main thread eventually asks the server to stop(). But they seem to ignore 
> the request. I checked the code of TSimpleServer.java and I'm under the 
> impression that the innermost loop the server does not poll the variable 
> stopped_ or does it? Looking at 
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
>  from line 76:
> {code}
>   while (true) {
> if (eventHandler_ != null) {
>   eventHandler_.processContext(connectionContext, inputTransport, 
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
>   break;
> }
>   }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried 
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
> guess that one of the methods in the loop must be blocking.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (THRIFT-4411) SIGABRT in thrift client during program end

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4411:


 Summary: SIGABRT in thrift client during program end
 Key: THRIFT-4411
 URL: https://issues.apache.org/jira/browse/THRIFT-4411
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
Affects Versions: 1.0
 Environment: Ubuntu Linux x86_64
Reporter: Mario Emmenlauer


After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
you need to see the source code?

{noformat}
LightBISClientCMDLine: 
/data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
!= 0' failed.

Program received signal SIGABRT, Aborted.
0x76c29428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x76c2b02a in __GI_abort () at abort.c:89
#2  0x76c21bd7 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x769bc190 "px != 0", 
file=file@entry=0x769bc108 
"/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
line=line@entry=199, 
function=function@entry=0x769bc1c0 
::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
0", 
file=0x769bc108 
"/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
function=0x769bc1c0 
::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  0x769acee9 in 
boost::shared_array::operator[] 
(this=0x76bf3c00 , i=12)
at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
#5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
n=12)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
#6  0x757ab8e7 in CRYPTO_add_lock () from 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#7  0x75bcacec in SSL_CTX_free () from 
/lib/x86_64-linux-gnu/libssl.so.1.0.0
#8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
(this=0x6725b0, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
#9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
(this=0x6725b0, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
#10 0x769adebe in 
std::_Sp_counted_ptr::_M_dispose (this=0x6737e0) at 
/usr/include/c++/5/bits/shared_ptr_base.h:374
#11 0x00425744 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
at /usr/include/c++/5/bits/shared_ptr_base.h:150
#12 0x00424439 in 
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
(this=0x674150, __in_chrg=) at 
/usr/include/c++/5/bits/shared_ptr_base.h:659
#13 0x769acb96 in 
std::__shared_ptr::~__shared_ptr (this=0x674148, __in_chrg=)
---Type  to continue, or q  to quit---
at /usr/include/c++/5/bits/shared_ptr_base.h:925
#14 0x769acbd8 in 
std::shared_ptr::~shared_ptr 
(this=0x674148, __in_chrg=) at 
/usr/include/c++/5/bits/shared_ptr.h:93
#15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
(this=0x674050, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
#16 0x769a7ec8 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
(this=0x674050, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
#17 0x769ade4c in 
std::_Sp_counted_ptr::_M_dispose (this=0x674180) at 
/usr/include/c++/5/bits/shared_ptr_base.h:374
#18 0x00425744 in 
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x674180) 
at /usr/include/c++/5/bits/shared_ptr_base.h:150
#19 0x00424439 in 
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
(this=0x679960, __in_chrg=) at 
/usr/include/c++/5/bits/shared_ptr_base.h:659
#20 0x77b1b98a in 
std::__shared_ptr::~__shared_ptr (this=0x679958, __in_chrg=)
at /usr/include/c++/5/bits/shared_ptr_base.h:925
#21 0x77b1b9a6 in 
std::shared_ptr::~shared_ptr 
(this=0x679958, __in_chrg=) at 
/usr/include/c++/5/bits/shared_ptr.h:93
#22 0x76996f92 in 
apache::thrift::transport::

[jira] [Created] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4412:


 Summary: thrift cmake does not use absolute library path, linking 
system libraries
 Key: THRIFT-4412
 URL: https://issues.apache.org/jira/browse/THRIFT-4412
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Affects Versions: 0.10.0, 0.11.0, 1.0
Reporter: Mario Emmenlauer


I build thrift using cmake on Linux. It works generally very good on many 
platforms (I've tested Linux, Windows and MacOSX extensively). But one issue is 
plaguing me. I have my own custom boost libraries, libevent and others. I set 
CMAKE_PREFIX_PATH to their install directory. This generally also works well, 
and cmake finds the libraries. However in the final Makefile, the linker 
command uses `-lxxx` for library `xxx` instead of the usual cmake absolute path 
`/a/b/c/libxxx.so`. This is a problem because `ld` suddenly prefers the system 
libraries over my custom builds. This in turn breaks the build for me.

I do not have this problem with any other cmake builds. And I tried various 
workarounds to force cmake to use the absolute path, but failed. Did somebody 
maybe add this on purpose?




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4412:
-
Description: 
I build thrift using cmake on Linux. It works generally very good on many 
platforms (I've tested Linux, Windows and MacOSX extensively). But one issue is 
plaguing me. I have my own custom boost libraries, libevent and others. I set 
CMAKE_PREFIX_PATH to their install directory. This generally also works well, 
and cmake finds the libraries. However in the final Makefile, the linker 
command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake absolute 
path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly prefers 
the system libraries over my custom builds. This in turn breaks the build for 
me.

I do not have this problem with any other cmake builds. And I tried various 
workarounds to force cmake to use the absolute path, but failed. Did somebody 
maybe add this on purpose?


  was:
I build thrift using cmake on Linux. It works generally very good on many 
platforms (I've tested Linux, Windows and MacOSX extensively). But one issue is 
plaguing me. I have my own custom boost libraries, libevent and others. I set 
CMAKE_PREFIX_PATH to their install directory. This generally also works well, 
and cmake finds the libraries. However in the final Makefile, the linker 
command uses `-lxxx` for library `xxx` instead of the usual cmake absolute path 
`/a/b/c/libxxx.so`. This is a problem because `ld` suddenly prefers the system 
libraries over my custom builds. This in turn breaks the build for me.

I do not have this problem with any other cmake builds. And I tried various 
workarounds to force cmake to use the absolute path, but failed. Did somebody 
maybe add this on purpose?



> thrift cmake does not use absolute library path, linking system libraries
> -
>
> Key: THRIFT-4412
> URL: https://issues.apache.org/jira/browse/THRIFT-4412
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0, 0.11.0, 1.0
>Reporter: Mario Emmenlauer
>
> I build thrift using cmake on Linux. It works generally very good on many 
> platforms (I've tested Linux, Windows and MacOSX extensively). But one issue 
> is plaguing me. I have my own custom boost libraries, libevent and others. I 
> set CMAKE_PREFIX_PATH to their install directory. This generally also works 
> well, and cmake finds the libraries. However in the final Makefile, the 
> linker command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake 
> absolute path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly 
> prefers the system libraries over my custom builds. This in turn breaks the 
> build for me.
> I do not have this problem with any other cmake builds. And I tried various 
> workarounds to force cmake to use the absolute path, but failed. Did somebody 
> maybe add this on purpose?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16282614#comment-16282614
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

With thrift 1.0.0 and 0.11.0 I used std::shared_ptr whereas with 0.10.0 I have 
to use boost::shared_ptr. I do not know if this is related, but I will try to 
test this soon.

> SIGABRT in thrift client during program end
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.11.0, 1.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
> (this=0x674150, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:659
> #13 0x769acb96 in 
> std::__shared_ptr (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x674148, 
> __in_chrg=)
> ---Type  to continue, or q  to quit---
> at /usr/include/c++/5/bits/shared_ptr_base.h:925
> #14 0x769acbd8 in 
> std::shared_ptr::~shared_ptr 
> (this=0x674148, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr.h:93
> #15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
> #16 0x769a7ec8 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
> #17 0x769ade4c in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x674180) at 
> /usr/include/c++/5/bits/shared_ptr

[jira] [Updated] (THRIFT-4411) SIGABRT in thrift client during program end

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4411:
-
Affects Version/s: 0.11.0

> SIGABRT in thrift client during program end
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.11.0, 1.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
> (this=0x674150, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:659
> #13 0x769acb96 in 
> std::__shared_ptr (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x674148, 
> __in_chrg=)
> ---Type  to continue, or q  to quit---
> at /usr/include/c++/5/bits/shared_ptr_base.h:925
> #14 0x769acbd8 in 
> std::shared_ptr::~shared_ptr 
> (this=0x674148, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr.h:93
> #15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
> #16 0x769a7ec8 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
> #17 0x769ade4c in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x674180) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #18 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x674180) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #19 0x00424439 in 
>

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16282611#comment-16282611
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

The issue affects also thrift 0.11.0, but not 0.10.0.

> SIGABRT in thrift client during program end
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.11.0, 1.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
> (this=0x674150, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:659
> #13 0x769acb96 in 
> std::__shared_ptr (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x674148, 
> __in_chrg=)
> ---Type  to continue, or q  to quit---
> at /usr/include/c++/5/bits/shared_ptr_base.h:925
> #14 0x769acbd8 in 
> std::shared_ptr::~shared_ptr 
> (this=0x674148, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr.h:93
> #15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
> #16 0x769a7ec8 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
> #17 0x769ade4c in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x674180) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #18 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x674180) 

[jira] [Updated] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4412:
-
Description: 
I build thrift using cmake on Linux. It works generally very good on many 
platforms (I've tested Linux, Windows and MacOSX extensively). But one issue is 
plaguing me. I have my own custom boost libraries, libevent and others. I set 
{{CMAKE_PREFIX_PATH}} to their install directory. This generally also works 
well, and cmake finds the libraries. However in the final Makefile, the linker 
command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake absolute 
path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly prefers 
the system libraries over my custom builds. This in turn breaks the build for 
me.

I do not have this problem with any other cmake builds. And I tried various 
workarounds to force cmake to use the absolute path, but failed. Did somebody 
maybe add this on purpose?


  was:
I build thrift using cmake on Linux. It works generally very good on many 
platforms (I've tested Linux, Windows and MacOSX extensively). But one issue is 
plaguing me. I have my own custom boost libraries, libevent and others. I set 
CMAKE_PREFIX_PATH to their install directory. This generally also works well, 
and cmake finds the libraries. However in the final Makefile, the linker 
command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake absolute 
path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly prefers 
the system libraries over my custom builds. This in turn breaks the build for 
me.

I do not have this problem with any other cmake builds. And I tried various 
workarounds to force cmake to use the absolute path, but failed. Did somebody 
maybe add this on purpose?



> thrift cmake does not use absolute library path, linking system libraries
> -
>
> Key: THRIFT-4412
> URL: https://issues.apache.org/jira/browse/THRIFT-4412
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0, 0.11.0, 1.0
>Reporter: Mario Emmenlauer
>
> I build thrift using cmake on Linux. It works generally very good on many 
> platforms (I've tested Linux, Windows and MacOSX extensively). But one issue 
> is plaguing me. I have my own custom boost libraries, libevent and others. I 
> set {{CMAKE_PREFIX_PATH}} to their install directory. This generally also 
> works well, and cmake finds the libraries. However in the final Makefile, the 
> linker command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake 
> absolute path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly 
> prefers the system libraries over my custom builds. This in turn breaks the 
> build for me.
> I do not have this problem with any other cmake builds. And I tried various 
> workarounds to force cmake to use the absolute path, but failed. Did somebody 
> maybe add this on purpose?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283209#comment-16283209
 ] 

Mario Emmenlauer commented on THRIFT-4412:
--

Dear James, thanks for the quick response and help! Yes, When adding -L to 
{{LDFLAGS}} before running cmake then the correct libraries are used!

I also tested that the problem happens predominantly on older Linux (despite 
using newest cmake from the 3.9.x or 3.10.x series). I observe this problem on 
Ubuntu 14.04, CentOS 6 and CentOS 7, but not on Ubuntu 16.04 or 17.04.

Please let me re-phrase this issue as a feature request: If somebody knows 
(with little effort) how we could make sure that cmake uses the absolute linker 
path, then this would be a prefered behavior? Its good to have the workaround 
with the {{-L}} / {{-I}}, but standard cmake behavior would be to ensure that 
libs from {{CMAKE_PREFIX_PATH}} are preferred.

> thrift cmake does not use absolute library path, linking system libraries
> -
>
> Key: THRIFT-4412
> URL: https://issues.apache.org/jira/browse/THRIFT-4412
> Project: Thrift
>  Issue Type: Question
>  Components: Build Process
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>
> I build thrift using cmake on Linux. It works generally very good on many 
> platforms (I've tested Linux, Windows and MacOSX extensively). But one issue 
> is plaguing me. I have my own custom boost libraries, libevent and others. I 
> set {{CMAKE_PREFIX_PATH}} to their install directory. This generally also 
> works well, and cmake finds the libraries. However in the final Makefile, the 
> linker command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake 
> absolute path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly 
> prefers the system libraries over my custom builds. This in turn breaks the 
> build for me.
> I do not have this problem with any other cmake builds. And I tried various 
> workarounds to force cmake to use the absolute path, but failed. Did somebody 
> maybe add this on purpose?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4412:
-
Priority: Minor  (was: Major)

> thrift cmake does not use absolute library path, linking system libraries
> -
>
> Key: THRIFT-4412
> URL: https://issues.apache.org/jira/browse/THRIFT-4412
> Project: Thrift
>  Issue Type: Question
>  Components: Build Process
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>Priority: Minor
>
> I build thrift using cmake on Linux. It works generally very good on many 
> platforms (I've tested Linux, Windows and MacOSX extensively). But one issue 
> is plaguing me. I have my own custom boost libraries, libevent and others. I 
> set {{CMAKE_PREFIX_PATH}} to their install directory. This generally also 
> works well, and cmake finds the libraries. However in the final Makefile, the 
> linker command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake 
> absolute path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly 
> prefers the system libraries over my custom builds. This in turn breaks the 
> build for me.
> I do not have this problem with any other cmake builds. And I tried various 
> workarounds to force cmake to use the absolute path, but failed. Did somebody 
> maybe add this on purpose?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (THRIFT-4411) SIGABRT in thrift client during program end

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283236#comment-16283236
 ] 

Mario Emmenlauer edited comment on THRIFT-4411 at 12/8/17 9:09 AM:
---

I built thrift now with {{-DWITH_BOOST_SMART_PTR="ON"}} and add 
{{-DFORCE_BOOST_SMART_PTR=1}} to my compiler definitions. Now I get the same 
error, but with boost::shared_ptr instead of std::shared_ptr, so it seems 
unrelated to the shared pointer implementation. Note that my RPC client itself 
is contained in a std::shared_ptr that gets destructed at program end, but I 
think this is unrelated to the crash, since I do not observe any errors with 
thrift 0.10.0. I can reproduce the problem consistently with thrift 0.11.0 and 
1.0.0-dev.

Here is the stack trace:
{noformat}
LightBISClientCMDLine: 
/data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
!= 0' failed.

Program received signal SIGABRT, Aborted.
0x76c39428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x76c39428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x76c3b02a in __GI_abort () at abort.c:89
#2  0x76c31bd7 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x769cd9b0 "px != 0", 
file=file@entry=0x769cd928 
"/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
line=line@entry=199, 
function=function@entry=0x769cda60 
::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  0x76c31c82 in __GI___assert_fail (assertion=0x769cd9b0 "px != 
0", 
file=0x769cd928 
"/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
function=0x769cda60 
::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  0x769b988b in 
boost::shared_array::operator[] 
(this=0x76c03680 , i=12)
at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
#5  0x769b3fa7 in apache::thrift::transport::callbackLocking (mode=9, 
n=12)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
#6  0x757c48e7 in CRYPTO_add_lock () from 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#7  0x75be3cec in SSL_CTX_free () from 
/lib/x86_64-linux-gnu/libssl.so.1.0.0
#8  0x769b4585 in apache::thrift::transport::SSLContext::~SSLContext 
(this=0x6725d0, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
#9  0x769b45c0 in apache::thrift::transport::SSLContext::~SSLContext 
(this=0x6725d0, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
#10 0x769ba6b5 in 
boost::checked_delete (x=0x6725d0)
at /data/thirdparty/include/boost/core/checked_delete.hpp:34
#11 0x769baaca in 
boost::detail::sp_counted_impl_p::dispose
 (this=0x673800)
---Type  to continue, or q  to quit---
at /data/thirdparty/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#12 0x00422ccb in boost::detail::sp_counted_base::release 
(this=0x673800)
at 
/data/thirdparty/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:110
#13 0x00422d41 in boost::detail::shared_count::~shared_count 
(this=0x674170, __in_chrg=)
at /data/thirdparty/include/boost/smart_ptr/detail/shared_count.hpp:426
#14 0x769b96d6 in 
boost::shared_ptr::~shared_ptr 
(this=0x674168, __in_chrg=)
at /data/thirdparty/include/boost/smart_ptr/shared_ptr.hpp:341
#15 0x769b4cb4 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
(this=0x674070, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
#16 0x769b4cf0 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
(this=0x674070, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
#17 0x769ba71f in 
boost::checked_delete (x=0x674070)
at /data/thirdparty/include/boost/core/checked_delete.hpp:34
#18 0x769baa72 in 
boost::detail::sp_counted_impl_p::dispose
 (this=0x6741a0)
at /data/thirdparty/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#19 0x00422ccb in boost::detail::sp_counted_base::release 
(this=0x6741a0)
at 
/data/thirdparty/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:110
#

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283236#comment-16283236
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

I built thrift now with {{-DWITH_BOOST_SMART_PTR="ON"}} and add 
{{-DFORCE_BOOST_SMART_PTR=1}} to my compiler definitions. Now I get the same 
error, but with boost::shared_ptr instead of std::shared_ptr, so it seems 
unrelated to the shared pointer implementation. Note that my RPC client itself 
is contained in a std::shared_ptr that gets destructed at program end, but I 
think this is unrelated to the crash, since I do not observe any errors with 
thrift 0.10.0. I can reproduce the problem consistently with thrift 0.11.0 and 
1.0.0-dev.

Here is the stack trace:
{{{
LightBISClientCMDLine: 
/data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
!= 0' failed.

Program received signal SIGABRT, Aborted.
0x76c39428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x76c39428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x76c3b02a in __GI_abort () at abort.c:89
#2  0x76c31bd7 in __assert_fail_base (fmt=, 
assertion=assertion@entry=0x769cd9b0 "px != 0", 
file=file@entry=0x769cd928 
"/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
line=line@entry=199, 
function=function@entry=0x769cda60 
::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  0x76c31c82 in __GI___assert_fail (assertion=0x769cd9b0 "px != 
0", 
file=0x769cd928 
"/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
function=0x769cda60 
::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  0x769b988b in 
boost::shared_array::operator[] 
(this=0x76c03680 , i=12)
at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
#5  0x769b3fa7 in apache::thrift::transport::callbackLocking (mode=9, 
n=12)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
#6  0x757c48e7 in CRYPTO_add_lock () from 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#7  0x75be3cec in SSL_CTX_free () from 
/lib/x86_64-linux-gnu/libssl.so.1.0.0
#8  0x769b4585 in apache::thrift::transport::SSLContext::~SSLContext 
(this=0x6725d0, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
#9  0x769b45c0 in apache::thrift::transport::SSLContext::~SSLContext 
(this=0x6725d0, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
#10 0x769ba6b5 in 
boost::checked_delete (x=0x6725d0)
at /data/thirdparty/include/boost/core/checked_delete.hpp:34
#11 0x769baaca in 
boost::detail::sp_counted_impl_p::dispose
 (this=0x673800)
---Type  to continue, or q  to quit---
at /data/thirdparty/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#12 0x00422ccb in boost::detail::sp_counted_base::release 
(this=0x673800)
at 
/data/thirdparty/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:110
#13 0x00422d41 in boost::detail::shared_count::~shared_count 
(this=0x674170, __in_chrg=)
at /data/thirdparty/include/boost/smart_ptr/detail/shared_count.hpp:426
#14 0x769b96d6 in 
boost::shared_ptr::~shared_ptr 
(this=0x674168, __in_chrg=)
at /data/thirdparty/include/boost/smart_ptr/shared_ptr.hpp:341
#15 0x769b4cb4 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
(this=0x674070, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
#16 0x769b4cf0 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
(this=0x674070, __in_chrg=)
at 
/data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
#17 0x769ba71f in 
boost::checked_delete (x=0x674070)
at /data/thirdparty/include/boost/core/checked_delete.hpp:34
#18 0x769baa72 in 
boost::detail::sp_counted_impl_p::dispose
 (this=0x6741a0)
at /data/thirdparty/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#19 0x00422ccb in boost::detail::sp_counted_base::release 
(this=0x6741a0)
at 
/data/thirdparty/include/boost/smart_ptr/detail/sp_counted_base_std_atomic.hpp:110
#20 0x00422d41 in boost::detail::shared_count::~s

[jira] [Commented] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16284079#comment-16284079
 ] 

Mario Emmenlauer commented on THRIFT-4412:
--

cmake will by default prefer to use the full path to libraries. I understand 
that the reason is to avoid exactly the kind of problem I am facing. See for 
example 
https://cmake.org/cmake/help/v3.3/command/target_link_libraries.html#command:target_link_libraries
 and https://cmake.org/cmake/help/v3.3/policy/CMP0060.html. There are certain 
exceptions from this rule, but only in rare cases (i.e. for system libraries on 
some platforms). This generally works well and I've never had trouble with it, 
except for thrift on certain older Linux distrivutions. Its beyond my 
understanding why for thrift, cmake behaves differently. But I think its 
specific to thrift that the behavior is different (that libraries are not 
linked with full path), and I've not seen this elsewhere.

In any case its not a huge problem so we can close it as "too much effort to 
solve, and only affects rare cases". 

> thrift cmake does not use absolute library path, linking system libraries
> -
>
> Key: THRIFT-4412
> URL: https://issues.apache.org/jira/browse/THRIFT-4412
> Project: Thrift
>  Issue Type: Question
>  Components: Build Process
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>Priority: Minor
>
> I build thrift using cmake on Linux. It works generally very good on many 
> platforms (I've tested Linux, Windows and MacOSX extensively). But one issue 
> is plaguing me. I have my own custom boost libraries, libevent and others. I 
> set {{CMAKE_PREFIX_PATH}} to their install directory. This generally also 
> works well, and cmake finds the libraries. However in the final Makefile, the 
> linker command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake 
> absolute path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly 
> prefers the system libraries over my custom builds. This in turn breaks the 
> build for me.
> I do not have this problem with any other cmake builds. And I tried various 
> workarounds to force cmake to use the absolute path, but failed. Did somebody 
> maybe add this on purpose?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer closed THRIFT-4412.


> thrift cmake does not use absolute library path, linking system libraries
> -
>
> Key: THRIFT-4412
> URL: https://issues.apache.org/jira/browse/THRIFT-4412
> Project: Thrift
>  Issue Type: Question
>  Components: Build Process
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>Priority: Minor
>
> I build thrift using cmake on Linux. It works generally very good on many 
> platforms (I've tested Linux, Windows and MacOSX extensively). But one issue 
> is plaguing me. I have my own custom boost libraries, libevent and others. I 
> set {{CMAKE_PREFIX_PATH}} to their install directory. This generally also 
> works well, and cmake finds the libraries. However in the final Makefile, the 
> linker command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake 
> absolute path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly 
> prefers the system libraries over my custom builds. This in turn breaks the 
> build for me.
> I do not have this problem with any other cmake builds. And I tried various 
> workarounds to force cmake to use the absolute path, but failed. Did somebody 
> maybe add this on purpose?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (THRIFT-4412) thrift cmake does not use absolute library path, linking system libraries

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer resolved THRIFT-4412.
--
Resolution: Won't Fix

[~jking3] I thik you are right and this issue is too broad for thrift. Its 
possibly just a cmake issue that requires special handling. I'll investigate 
with cmake, and if I find a workaround I'll propose it here.

> thrift cmake does not use absolute library path, linking system libraries
> -
>
> Key: THRIFT-4412
> URL: https://issues.apache.org/jira/browse/THRIFT-4412
> Project: Thrift
>  Issue Type: Question
>  Components: Build Process
>Affects Versions: 0.10.0, 0.11.0
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>Priority: Minor
>
> I build thrift using cmake on Linux. It works generally very good on many 
> platforms (I've tested Linux, Windows and MacOSX extensively). But one issue 
> is plaguing me. I have my own custom boost libraries, libevent and others. I 
> set {{CMAKE_PREFIX_PATH}} to their install directory. This generally also 
> works well, and cmake finds the libraries. However in the final Makefile, the 
> linker command uses {{-lxxx}} for library {{xxx}} instead of the usual cmake 
> absolute path {{/a/b/c/libxxx.so}}. This is a problem because {{ld}} suddenly 
> prefers the system libraries over my custom builds. This in turn breaks the 
> build for me.
> I do not have this problem with any other cmake builds. And I tried various 
> workarounds to force cmake to use the absolute path, but failed. Did somebody 
> maybe add this on purpose?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end, C++, using openssl

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430489#comment-16430489
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

I was avoiding this discussion for a long time in the hope I would get more 
enlighted, but thruth be told, I'm not knowledgable enough about openssl 
initialization and cleanup to understand what you pointed out. How can I 
discriminate the lifetime of TSSLSocket vs the lifetime of the 
TSSLSocketFactory, and why would the one be different from the other? Is it not 
passed down, do I need to perform this manually? Or am I now on the wrong track?

Thanks a lot for your help!

> SIGABRT in thrift client during program end, C++, using openssl
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Question
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>Priority: Major
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
> (this=0x674150, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:659
> #13 0x769acb96 in 
> std::__shared_ptr (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x674148, 
> __in_chrg=)
> ---Type  to continue, or q  to quit---
> at /usr/include/c++/5/bits/shared_ptr_base.h:925
> #14 0x769acbd8 in 
> std::shared_ptr::~shared_ptr 
> (this=0x674148, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr.h:93
> #15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end, C++, using openssl

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16430504#comment-16430504
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

Thank you so much for that helpful discussion. I will check my code for the 
lifetime of the smart pointer. Very likely this was causing the issue!

> SIGABRT in thrift client during program end, C++, using openssl
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Question
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>Assignee: James E. King, III
>Priority: Major
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
> (this=0x674150, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:659
> #13 0x769acb96 in 
> std::__shared_ptr (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x674148, 
> __in_chrg=)
> ---Type  to continue, or q  to quit---
> at /usr/include/c++/5/bits/shared_ptr_base.h:925
> #14 0x769acbd8 in 
> std::shared_ptr::~shared_ptr 
> (this=0x674148, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr.h:93
> #15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
> #16 0x769a7ec8 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
> #17 0x769ade4c in 
> std::_Sp_counted_ptr (__gnu_cxx::

[jira] [Created] (THRIFT-4560) The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4560:


 Summary: The logic of CMAKE_DEPENDENT_OPTION seems wrong and can 
break the build
 Key: THRIFT-4560
 URL: https://issues.apache.org/jira/browse/THRIFT-4560
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Affects Versions: 1.0
Reporter: Mario Emmenlauer


The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
according to my understanding, the resulting logic is wrong and can lead to 
problems. Consider the following example for building with Qt4 or Qt5 from 
{{build/cmake/DefineOptions.cmake}}:
{{{
find_package(Qt5 QUIET COMPONENTS Core Network)
CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
   "Qt5_FOUND" OFF)
}}}

If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have Qt5 
installed, they will not get an error. They will just get a warning that the 
option {{WITH_QT5}} was unused.
Furthermore, if the user must disable Qt5 (i.e. because its broken), then 
{{cmake -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
{{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
will fail, despite {{cmake -DWITH_QT5=OFF}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4560) The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4560:
-
Description: 
The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
according to my understanding, the resulting logic is wrong and can lead to 
problems. Consider the following example for building with Qt4 or Qt5 from 
{{build/cmake/DefineOptions.cmake}}:

{noformat}
find_package(Qt5 QUIET COMPONENTS Core Network)
CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
   "Qt5_FOUND" OFF)
{noformat}

If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have Qt5 
installed, they will not get an error. They will just get a warning that the 
option {{WITH_QT5}} was unused.
Furthermore, if the user must disable Qt5 (i.e. because its broken), then 
{{cmake -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
{{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
will fail, despite {{cmake -DWITH_QT5=OFF}}.

  was:
The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
according to my understanding, the resulting logic is wrong and can lead to 
problems. Consider the following example for building with Qt4 or Qt5 from 
{{build/cmake/DefineOptions.cmake}}:
{{{
find_package(Qt5 QUIET COMPONENTS Core Network)
CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
   "Qt5_FOUND" OFF)
}}}

If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have Qt5 
installed, they will not get an error. They will just get a warning that the 
option {{WITH_QT5}} was unused.
Furthermore, if the user must disable Qt5 (i.e. because its broken), then 
{{cmake -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
{{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
will fail, despite {{cmake -DWITH_QT5=OFF}}.


> The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build
> ---
>
> Key: THRIFT-4560
> URL: https://issues.apache.org/jira/browse/THRIFT-4560
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
> according to my understanding, the resulting logic is wrong and can lead to 
> problems. Consider the following example for building with Qt4 or Qt5 from 
> {{build/cmake/DefineOptions.cmake}}:
> {noformat}
> find_package(Qt5 QUIET COMPONENTS Core Network)
> CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
>"Qt5_FOUND" OFF)
> {noformat}
> If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have 
> Qt5 installed, they will not get an error. They will just get a warning that 
> the option {{WITH_QT5}} was unused.
> Furthermore, if the user must disable Qt5 (i.e. because its broken), then 
> {{cmake -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
> {{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
> will fail, despite {{cmake -DWITH_QT5=OFF}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4560) The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4560:
-
Description: 
The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
according to my understanding, the resulting logic is wrong and can lead to 
problems. Consider the following example for building with Qt4 or Qt5 from 
{{build/cmake/DefineOptions.cmake}}:

{noformat}
find_package(Qt5 QUIET COMPONENTS Core Network)
CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
   "Qt5_FOUND" OFF)
{noformat}

If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have Qt5 
installed, they will not get an error. They will just get a warning that the 
option {{WITH_QT5}} was unused.
Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
-DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
{{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.

  was:
The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
according to my understanding, the resulting logic is wrong and can lead to 
problems. Consider the following example for building with Qt4 or Qt5 from 
{{build/cmake/DefineOptions.cmake}}:

{noformat}
find_package(Qt5 QUIET COMPONENTS Core Network)
CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
   "Qt5_FOUND" OFF)
{noformat}

If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have Qt5 
installed, they will not get an error. They will just get a warning that the 
option {{WITH_QT5}} was unused.
Furthermore, if the user must disable Qt5 (i.e. because its broken), then 
{{cmake -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
{{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
will fail, despite {{cmake -DWITH_QT5=OFF}}.


> The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build
> ---
>
> Key: THRIFT-4560
> URL: https://issues.apache.org/jira/browse/THRIFT-4560
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
> according to my understanding, the resulting logic is wrong and can lead to 
> problems. Consider the following example for building with Qt4 or Qt5 from 
> {{build/cmake/DefineOptions.cmake}}:
> {noformat}
> find_package(Qt5 QUIET COMPONENTS Core Network)
> CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
>"Qt5_FOUND" OFF)
> {noformat}
> If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have 
> Qt5 installed, they will not get an error. They will just get a warning that 
> the option {{WITH_QT5}} was unused.
> Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
> -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
> {{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
> will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4560) The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4560:
-
Description: 
The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
according to my understanding, the resulting logic is wrong and can lead to 
problems. Consider the following example for building with Qt4 or Qt5 from 
{{build/cmake/DefineOptions.cmake}}:

{noformat}
find_package(Qt5 QUIET COMPONENTS Core Network)
CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
   "Qt5_FOUND" OFF)
{noformat}

If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have Qt5 
installed, they will not get an error. They will just get a warning that the 
option {{WITH_QT5}} was unused.
Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
-DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
{{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.

My expected behavior is that if {{WITH_QT5=OFF}} is specified, that no Qt5 
checks are run and that a missing/broken Qt5 would not impact thrift in any way.

  was:
The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
according to my understanding, the resulting logic is wrong and can lead to 
problems. Consider the following example for building with Qt4 or Qt5 from 
{{build/cmake/DefineOptions.cmake}}:

{noformat}
find_package(Qt5 QUIET COMPONENTS Core Network)
CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
   "Qt5_FOUND" OFF)
{noformat}

If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have Qt5 
installed, they will not get an error. They will just get a warning that the 
option {{WITH_QT5}} was unused.
Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
-DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
{{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.


> The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build
> ---
>
> Key: THRIFT-4560
> URL: https://issues.apache.org/jira/browse/THRIFT-4560
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
> according to my understanding, the resulting logic is wrong and can lead to 
> problems. Consider the following example for building with Qt4 or Qt5 from 
> {{build/cmake/DefineOptions.cmake}}:
> {noformat}
> find_package(Qt5 QUIET COMPONENTS Core Network)
> CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
>"Qt5_FOUND" OFF)
> {noformat}
> If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have 
> Qt5 installed, they will not get an error. They will just get a warning that 
> the option {{WITH_QT5}} was unused.
> Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
> -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
> {{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
> will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.
> My expected behavior is that if {{WITH_QT5=OFF}} is specified, that no Qt5 
> checks are run and that a missing/broken Qt5 would not impact thrift in any 
> way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end, C++, using openssl

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502942#comment-16502942
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

Dear [~jking3], I found more insights but I am still plagued by this issue. I 
can see that the `SIGABRT` comes in the destructor of my class that handles the 
connection, when it destroys the client. If I completely leave out 
`cleanupOpenSSL()` the crash will not happen, so you where right there! But I 
still can not get a working solution. I tried to ensure to manually clean up 
all resources. I can see that the reference count of each pointer is `1` before 
I `reset()` it, so the cleanup should work AFAICS.

So I assume I must be missing another manual deletion before 
`cleanupOpenSSL()`, but I can not think which one?

Here is the destructor. The mSecureXXX variables are all `shared_ptr`'s to the 
client, protocol, transport and socket. I assumed this should work?

LightBISClientCpp::~LightBISClientCpp() {
mSecureClient.reset();
mSecureProtocol.reset();
mSecureTransport.reset();
mSecureSocket.reset();

// If this cleanup is present, we get a crash. If it is removed, the crash 
is gone. But why?!
apache::thrift::transport::cleanupOpenSSL();
}


> SIGABRT in thrift client during program end, C++, using openssl
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Question
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>Assignee: James E. King III
>Priority: Major
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end, C++, using openssl

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502941#comment-16502941
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

Dear [~jking3], I found more insights but I am still plagued by this issue. I 
can see that the `SIGABRT` comes in the destructor of my class that handles the 
connection, when it destroys the client. If I completely leave out 
`cleanupOpenSSL()` the crash will not happen, so you where right there! But I 
still can not get a working solution. I tried to ensure to manually clean up 
all resources. I can see that the reference count of each pointer is `1` before 
I `reset()` it, so the cleanup should work AFAICS.

So I assume I must be missing another manual deletion before 
`cleanupOpenSSL()`, but I can not think which one?

Here is the destructor. The mSecureXXX variables are all `shared_ptr`'s to the 
client, protocol, transport and socket. I assumed this should work?

LightBISClientCpp::~LightBISClientCpp() {
mSecureClient.reset();
mSecureProtocol.reset();
mSecureTransport.reset();
mSecureSocket.reset();

// If this cleanup is present, we get a crash. If it is removed, the crash 
is gone. But why?!
apache::thrift::transport::cleanupOpenSSL();
}


> SIGABRT in thrift client during program end, C++, using openssl
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Question
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>Assignee: James E. King III
>Priority: Major
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end, C++, using openssl

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16502948#comment-16502948
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

Basically, it seems the TSSLSocketFactory destructor will crash, even if I 
closed all other thrift resources before calling cleanupOpenSSL();


> SIGABRT in thrift client during program end, C++, using openssl
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Question
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>Assignee: James E. King III
>Priority: Major
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
> (this=0x674150, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:659
> #13 0x769acb96 in 
> std::__shared_ptr (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x674148, 
> __in_chrg=)
> ---Type  to continue, or q  to quit---
> at /usr/include/c++/5/bits/shared_ptr_base.h:925
> #14 0x769acbd8 in 
> std::shared_ptr::~shared_ptr 
> (this=0x674148, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr.h:93
> #15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
> #16 0x769a7ec8 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
> #17 0x769ade4c in 
> std::_Sp_counted_ptr (__gnu_cxx::_Loc

[jira] [Commented] (THRIFT-4411) SIGABRT in thrift client during program end, C++, using openssl

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503017#comment-16503017
 ] 

Mario Emmenlauer commented on THRIFT-4411:
--

Ok, the issue is solved! It seems required to also delete TSSLSocketFactory 
before invoking cleanupOpenSSL()! I was not aware of that. Thanks [~jking3] for 
your help!

> SIGABRT in thrift client during program end, C++, using openssl
> ---
>
> Key: THRIFT-4411
> URL: https://issues.apache.org/jira/browse/THRIFT-4411
> Project: Thrift
>  Issue Type: Question
>  Components: C++ - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux x86_64
>Reporter: Mario Emmenlauer
>Assignee: James E. King III
>Priority: Major
>
> After upgrading to thrift 1.0.0 rev 20e16bc I get a SIGABRT during exit of my 
> thrift RPC client. This did not happen with 0.10.0. Here is a stack trace. Do 
> you need to see the source code?
> {noformat}
> LightBISClientCMDLine: 
> /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199: T& 
> boost::shared_array::operator[](std::ptrdiff_t) const [with T = 
> apache::thrift::concurrency::Mutex; std::ptrdiff_t = long int]: Assertion `px 
> != 0' failed.
> Program received signal SIGABRT, Aborted.
> 0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  0x76c29428 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x76c2b02a in __GI_abort () at abort.c:89
> #2  0x76c21bd7 in __assert_fail_base (fmt=, 
> assertion=assertion@entry=0x769bc190 "px != 0", 
> file=file@entry=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", 
> line=line@entry=199, 
> function=function@entry=0x769bc1c0 
> ::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  0x76c21c82 in __GI___assert_fail (assertion=0x769bc190 "px != 
> 0", 
> file=0x769bc108 
> "/data/thirdparty/include/boost/smart_ptr/shared_array.hpp", line=199, 
> function=0x769bc1c0 
> ::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  0x769acee9 in 
> boost::shared_array::operator[] 
> (this=0x76bf3c00 , i=12)
> at /data/thirdparty/include/boost/smart_ptr/shared_array.hpp:199
> #5  0x769a717f in apache::thrift::transport::callbackLocking (mode=9, 
> n=12)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:77
> #6  0x757ab8e7 in CRYPTO_add_lock () from 
> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> #7  0x75bcacec in SSL_CTX_free () from 
> /lib/x86_64-linux-gnu/libssl.so.1.0.0
> #8  0x769a775d in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:200
> #9  0x769a7798 in apache::thrift::transport::SSLContext::~SSLContext 
> (this=0x6725b0, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:203
> #10 0x769adebe in 
> std::_Sp_counted_ptr (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x6737e0) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:374
> #11 0x00425744 in 
> std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x6737e0) 
> at /usr/include/c++/5/bits/shared_ptr_base.h:150
> #12 0x00424439 in 
> std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count 
> (this=0x674150, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr_base.h:659
> #13 0x769acb96 in 
> std::__shared_ptr (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x674148, 
> __in_chrg=)
> ---Type  to continue, or q  to quit---
> at /usr/include/c++/5/bits/shared_ptr_base.h:925
> #14 0x769acbd8 in 
> std::shared_ptr::~shared_ptr 
> (this=0x674148, __in_chrg=) at 
> /usr/include/c++/5/bits/shared_ptr.h:93
> #15 0x769a7e8c in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:248
> #16 0x769a7ec8 in apache::thrift::transport::TSSLSocket::~TSSLSocket 
> (this=0x674050, __in_chrg=)
> at 
> /data/thirdparty/thrift-1.0.0.20e16bc/lib/cpp/src/thrift/transport/TSSLSocket.cpp:250
> #17 0x769ade4c in 
> std::_Sp_cou

[jira] [Commented] (THRIFT-4560) The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510867#comment-16510867
 ] 

Mario Emmenlauer commented on THRIFT-4560:
--

Would a PR be accepted for this issue? I would like to change the logic of 
these options:
* If `-DWITH_XXX=OFF` is specified, then no `find_package(XXX)` should run
* If `-DWITH_XXX=ON` is specified, then the build should fail if `XXX` is 
missing

I think this may require a third state (the new default). Th new state would be 
something like `WITH_XXX=AUTO` for automatic detection of availability of `XXX`.

> The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build
> ---
>
> Key: THRIFT-4560
> URL: https://issues.apache.org/jira/browse/THRIFT-4560
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
> according to my understanding, the resulting logic is wrong and can lead to 
> problems. Consider the following example for building with Qt4 or Qt5 from 
> {{build/cmake/DefineOptions.cmake}}:
> {noformat}
> find_package(Qt5 QUIET COMPONENTS Core Network)
> CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
>"Qt5_FOUND" OFF)
> {noformat}
> If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have 
> Qt5 installed, they will not get an error. They will just get a warning that 
> the option {{WITH_QT5}} was unused.
> Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
> -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
> {{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
> will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.
> My expected behavior is that if {{WITH_QT5=OFF}} is specified, that no Qt5 
> checks are run and that a missing/broken Qt5 would not impact thrift in any 
> way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4252) Cannot shutdown Java server when clients are still connected

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510998#comment-16510998
 ] 

Mario Emmenlauer commented on THRIFT-4252:
--

Is it possible to post a bounty on this task? Are there thrift core developers 
that accept a bounty?

> Cannot shutdown Java server when clients are still connected
> 
>
> Key: THRIFT-4252
> URL: https://issues.apache.org/jira/browse/THRIFT-4252
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.10.0
>Reporter: Mario Emmenlauer
>Priority: Major
>
> I found issue https://issues.apache.org/jira/browse/THRIFT-2441 and I believe 
> that the same problem still exists in the Java servers, and I'm affected by 
> it. Short summary: I can not shut down the Java server (neither TSimpleServer 
> nor TThreadedServer) while clients are still connected. That is pretty bad, 
> because essentially the clients are not under by control, but they can 
> essentially "block" server maintenance operations by blocking the shutdown.
> *In more detail:* I have a Java TSimpleServer runnable in a thread running. 
> The main thread eventually asks the server to stop(). But they seem to ignore 
> the request. I checked the code of TSimpleServer.java and I'm under the 
> impression that the innermost loop the server does not poll the variable 
> stopped_ or does it? Looking at 
> https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/server/TSimpleServer.java
>  from line 76:
> {code}
>   while (true) {
> if (eventHandler_ != null) {
>   eventHandler_.processContext(connectionContext, inputTransport, 
> outputTransport);
> }
> if(!processor.process(inputProtocol, outputProtocol)) {
>   break;
> }
>   }
> {code}
> I found that this loop is only interrupted if the client disconnects. I tried 
> changing {{while(true)}} for {{while(!stopped_)}} but that did not help. I 
> guess that one of the methods in the loop must be blocking.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4560) The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16519190#comment-16519190
 ] 

Mario Emmenlauer commented on THRIFT-4560:
--

Thanks Aki! I will provide a PR for your review!

BTW, I agree that it could be considered a bug in a {{Find*.cmake}} script that 
it will fail if Qt is incompletely installed. However I guess the cleanest 
solution is not to require {{find_package(Qt5)}} at all if {{-DWITH_QT=OFF}}.


> The logic of CMAKE_DEPENDENT_OPTION seems wrong and can break the build
> ---
>
> Key: THRIFT-4560
> URL: https://issues.apache.org/jira/browse/THRIFT-4560
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 1.0
>Reporter: Mario Emmenlauer
>Priority: Minor
>
> The cmake build uses {{CMAKE_DEPENDENT_OPTION}} in several places. But 
> according to my understanding, the resulting logic is wrong and can lead to 
> problems. Consider the following example for building with Qt4 or Qt5 from 
> {{build/cmake/DefineOptions.cmake}}:
> {noformat}
> find_package(Qt5 QUIET COMPONENTS Core Network)
> CMAKE_DEPENDENT_OPTION(WITH_QT5 "Build with Qt5 support" ON
>"Qt5_FOUND" OFF)
> {noformat}
> If a user configures thrift with {{cmake -DWITH_QT5=ON}} but does not have 
> Qt5 installed, they will not get an error. They will just get a warning that 
> the option {{WITH_QT5}} was unused.
> Furthermore, if the user disables Qt5 (i.e. because its broken), then {{cmake 
> -DWITH_QT5=OFF}} will **not** disable the search for Qt5. If the 
> {{find_package(Qt5 QUIET COMPONENTS Core Network)}} fails in error, the build 
> will fail, despite the explicit request for {{cmake -DWITH_QT5=OFF}}.
> My expected behavior is that if {{WITH_QT5=OFF}} is specified, that no Qt5 
> checks are run and that a missing/broken Qt5 would not impact thrift in any 
> way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4598) TBinaryProtocol.readMessageBegin() hangs forever in Java

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4598:


 Summary: TBinaryProtocol.readMessageBegin() hangs forever in Java
 Key: THRIFT-4598
 URL: https://issues.apache.org/jira/browse/THRIFT-4598
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 1.0
 Environment: Ubuntu Linux 16.04 x86_64
Reporter: Mario Emmenlauer


I run some internal tests for the robustness of our thrift Java server. It 
seems the tests lead to an infinitely hanging server thread. This blocks the 
jvm from cleanly ending. After I try a clean exit, there are almost no threads 
left except the org.apache.thrift.server.TThreadPoolServer.

Here is the call stack:
{code:java}
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
- locked <0x00067b390fd8> (a java.io.BufferedInputStream)
at 
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
at 
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27)
at 
org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
I already reduced the server socket timeout to 30sec and the requestTimeout to 
10sec. Is there anything else I can do to timeout readMessageBegin()?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4598) TBinaryProtocol.readMessageBegin() hangs forever in Java

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4598:
-
Description: 
I run some internal tests for the robustness of our thrift Java server. One of 
the robustness tests is to try to connect to the secure server socket with an 
insecure client and vice versa. This may seem a slightly diabolic test but it 
can be a simple user error to forget enabling or disabling encryption. So I 
think thrift should handle this gracefully.

However it seems that this test leads to an infinitely hanging server thread! 
The thread blocks the jvm (Java 1.8.0_161 x86_64) from ending. I can see in 
jstack that the main method ends and there are almost no threads left, except 
some garbage collectors and finalizers plus 
org.apache.thrift.server.TThreadPoolServer.

Here is the call stack of the thrift server thread:
{code:java}
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
- locked <0x00067b390fd8> (a java.io.BufferedInputStream)
at 
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
at 
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27)
at 
org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
I already reduced the server socket timeout to 30sec and the requestTimeout to 
10sec. Is there anything else I can do to timeout readMessageBegin()?

  was:
I run some internal tests for the robustness of our thrift Java server. It 
seems the tests lead to an infinitely hanging server thread. This blocks the 
jvm from cleanly ending. After I try a clean exit, there are almost no threads 
left except the org.apache.thrift.server.TThreadPoolServer.

Here is the call stack:
{code:java}
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
- locked <0x00067b390fd8> (a java.io.BufferedInputStream)
at 
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
at 
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27)
at 
org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
I already reduced the server socket timeout to 30sec and the requestTimeout to 
10sec. Is there anything else I can do to timeout readMessageBegin()?


> TBinaryProtocol.readMessageBegin() hangs forever in Java
> 
>
> Key: THRIFT-4598
> URL: https://issues.apache.org/jira/browse/THRIFT-4598
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 1.0
> Environment: Ubuntu Linux 16.04 x86_64
>Reporter: Mario Emmenlauer
>Priority: Major
>
> I run some internal tests for the robustness of our thrift Java server. One 
> of the robustness tests is to try to connect to the secure server socket with 
> an insecure client and vice versa. This may seem a slightly diabolic test but 
> it can be a simp

[jira] [Commented] (THRIFT-4598) TBinaryProtocol.readMessageBegin() hangs forever in Java

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532879#comment-16532879
 ] 

Mario Emmenlauer commented on THRIFT-4598:
--

Thanks for this very helpful insight! I was indeed using 
{code}TServer::stop(){code} instead of {code}TThreadPoolServer::stop(){code}
This seems to have a significant difference. The server exits cleanly now after 
using the latter. For me this fixes the issue, but maybe we can leave the 
report open until TServer is adjusted accordingly?

> TBinaryProtocol.readMessageBegin() hangs forever in Java
> 
>
> Key: THRIFT-4598
> URL: https://issues.apache.org/jira/browse/THRIFT-4598
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux 16.04 x86_64
>Reporter: Mario Emmenlauer
>Priority: Major
>
> I run some internal tests for the robustness of our thrift Java server. One 
> of the robustness tests is to try to connect to the secure server socket with 
> an insecure client and vice versa. This may seem a slightly diabolic test but 
> it can be a simple user error to forget enabling or disabling encryption. So 
> I think thrift should handle this gracefully.
> However it seems that this test leads to an infinitely hanging server thread! 
> The thread blocks the jvm (Java 1.8.0_161 x86_64) from ending. I can see in 
> jstack that the main method ends and there are almost no threads left, except 
> some garbage collectors and finalizers plus 
> org.apache.thrift.server.TThreadPoolServer.
> Here is the call stack of the thrift server thread:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x00067b390fd8> (a java.io.BufferedInputStream)
> at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27)
> at 
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> I already reduced the server socket timeout to 30sec and the requestTimeout 
> to 10sec. Is there anything else I can do to timeout readMessageBegin()?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4598) TBinaryProtocol.readMessageBegin() hangs forever in Java

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533512#comment-16533512
 ] 

Mario Emmenlauer commented on THRIFT-4598:
--

You are right, I was somehow jumping to a wrong conclusion. I was using before:
{code:java}
TServer server = new TThreadPoolServer(...)
server.stop();
{code}
and changed it to:
{code:java}
TThreadPoolServer server = new TThreadPoolServer(...)
server.stop();
{code}
But that was not the relevant change, I was just confusing myself.

I changed also the timeouts again. This must have helped:
{code:java}
const int vTimeoutSec = 30;
TServerTransport vServerTransport = new TServerSocket(vServerPort, 
1000*vTimeoutSec);
TThreadPoolServer.Args vTThreadPoolServerArgs = new 
TThreadPoolServer.Args(vServerTransport);
vTThreadPoolServerArgs.stopTimeoutVal(vTimeoutSec);
vTThreadPoolServerArgs.stopTimeoutUnit(TimeUnit.SECONDS);
vTThreadPoolServerArgs.requestTimeout(vTimeoutSec);
vTThreadPoolServerArgs.requestTimeoutUnit(TimeUnit.SECONDS);
{code}
I think I tested this before, but in any case, since I enforce all timeouts 
again it seems to be working and the connection closes automatically after a 
while.
 Thanks a lot for your help!

> TBinaryProtocol.readMessageBegin() hangs forever in Java
> 
>
> Key: THRIFT-4598
> URL: https://issues.apache.org/jira/browse/THRIFT-4598
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Library
>Affects Versions: 0.11.0
> Environment: Ubuntu Linux 16.04 x86_64
>Reporter: Mario Emmenlauer
>Assignee: James E. King III
>Priority: Major
>
> I run some internal tests for the robustness of our thrift Java server. One 
> of the robustness tests is to try to connect to the secure server socket with 
> an insecure client and vice versa. This may seem a slightly diabolic test but 
> it can be a simple user error to forget enabling or disabling encryption. So 
> I think thrift should handle this gracefully.
> However it seems that this test leads to an infinitely hanging server thread! 
> The thread blocks the jvm (Java 1.8.0_161 x86_64) from ending. I can see in 
> jstack that the main method ends and there are almost no threads left, except 
> some garbage collectors and finalizers plus 
> org.apache.thrift.server.TThreadPoolServer.
> Here is the call stack of the thrift server thread:
> {code:java}
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> - locked <0x00067b390fd8> (a java.io.BufferedInputStream)
> at 
> org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:127)
> at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
> at 
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27)
> at 
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> I already reduced the server socket timeout to 30sec and the requestTimeout 
> to 10sec. Is there anything else I can do to timeout readMessageBegin()?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-1834) As a developer, I would like a thrift C++ runtime DLL for windows development

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16595031#comment-16595031
 ] 

Mario Emmenlauer commented on THRIFT-1834:
--

Could this issue be re-evaluated? I agree with [~jking3] that with modern 
cmake, it has become quite easy to automatically define macros for dll export.

> As a developer, I would like a thrift C++ runtime DLL for windows development
> -
>
> Key: THRIFT-1834
> URL: https://issues.apache.org/jira/browse/THRIFT-1834
> Project: Thrift
>  Issue Type: Story
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: Windows x86_64 MSVC 2010
>Reporter: Chris Stylianou
>Priority: Major
>  Labels: dll, msvc, thrift, windows
>
> I am unable to build a valid .dll version of the Thrift C++ library using 
> MSVC2010 as nothing has been declared with 
> "__declspec(dllexport)/__declspec(dllimport)", meaning that MSVC2010 (and 
> presumably all other versions) are unable to generate the import .lib that 
> should accompany the .dll library.
> Currently the cmake environment only supports building a static library (with 
> static or dynamic runtime - you choose with the "WITH_MT" option).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-1834) As a developer, I would like a thrift C++ runtime DLL for windows development

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16596130#comment-16596130
 ] 

Mario Emmenlauer commented on THRIFT-1834:
--

I agree that the endgame is quite some work. But maybe its possible to be 
pragmatic and start with a best effort. Here is an approach that would bring 
the full feature set with moderate effort: For a start, I would use the cmake 
builtin functionality to export all symbols from the dll automatically 
([https://cmake.org/cmake/help/latest/prop_tgt/WINDOWS_EXPORT_ALL_SYMBOLS.html).]
 This is slightly hackish, but it will just bring the typical behavior on Un*x 
to the Windows dll, so I think it can be an acceptable start. I've used this 
successfully in the past to port a number of libraries and there are rarely any 
problems.

When thrift can be built as shared library, I would focus on the thrift 
compiler to generate code that correctly exports the symbols. This may be 
almost trivial or a bit more effort depending what symbols are generated(?) I 
do not feel super comfortable to do this change myself.

With these two changes in place, the functionality may be good enough for a 
large group of users. Its not super clean to export all symbols from 
thrift.dll, but at the same time its not a real problem. Over time, more and 
more symbols can get the actual correct export definitions, so that eventually 
the WINDOWS_EXPORT_ALL_SYMBOLS can go away.

Would that be reasonable?

> As a developer, I would like a thrift C++ runtime DLL for windows development
> -
>
> Key: THRIFT-1834
> URL: https://issues.apache.org/jira/browse/THRIFT-1834
> Project: Thrift
>  Issue Type: Story
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: Windows x86_64 MSVC 2010
>Reporter: Chris Stylianou
>Priority: Major
>  Labels: dll, msvc, thrift, windows
>
> I am unable to build a valid .dll version of the Thrift C++ library using 
> MSVC2010 as nothing has been declared with 
> "__declspec(dllexport)/__declspec(dllimport)", meaning that MSVC2010 (and 
> presumably all other versions) are unable to generate the import .lib that 
> should accompany the .dll library.
> Currently the cmake environment only supports building a static library (with 
> static or dynamic runtime - you choose with the "WITH_MT" option).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-1834) As a developer, I would like a thrift C++ runtime DLL for windows development

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16596252#comment-16596252
 ] 

Mario Emmenlauer commented on THRIFT-1834:
--

Ok I will provide a PR against HEAD(?) to allow a cmake shared library build on 
Windows, and instruct cmake to export all symbols on Windows.

Could you check the thrift compiler what symbols need to be exported? Is it 
just the class definitions? Then we could pragmatically always export the full 
class. Or are there other interfaces (public variables or something)?

> As a developer, I would like a thrift C++ runtime DLL for windows development
> -
>
> Key: THRIFT-1834
> URL: https://issues.apache.org/jira/browse/THRIFT-1834
> Project: Thrift
>  Issue Type: Story
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: Windows x86_64 MSVC 2010
>Reporter: Chris Stylianou
>Priority: Major
>  Labels: dll, msvc, thrift, windows
>
> I am unable to build a valid .dll version of the Thrift C++ library using 
> MSVC2010 as nothing has been declared with 
> "__declspec(dllexport)/__declspec(dllimport)", meaning that MSVC2010 (and 
> presumably all other versions) are unable to generate the import .lib that 
> should accompany the .dll library.
> Currently the cmake environment only supports building a static library (with 
> static or dynamic runtime - you choose with the "WITH_MT" option).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4752) Add cmake package configuration support?

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4752:


 Summary: Add cmake package configuration support?
 Key: THRIFT-4752
 URL: https://issues.apache.org/jira/browse/THRIFT-4752
 Project: Thrift
  Issue Type: Improvement
  Components: Deployment
Affects Versions: 1.0
Reporter: Mario Emmenlauer


The thrift build with cmake is really great. There is only a minor issue left, 
that downstream packages have to have a FindThrift.cmake script to correctly 
find and use the library and compiler.

Modern cmake suggests as a better solution the use of package configuration 
files (see 
[https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#package-configuration-file).]
 Thanks to package configuration, all users of thrift can just 
find_package(thrift) and use the library and compiler without further work. 
Transitive package dependencies are also resolved.

I have created a package configuration for thrift cmake build. Could this be 
considered for inclusion?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4752) Add cmake package configuration support?

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4752:
-
Description: 
The thrift build with cmake is really great! In my daily use, there is a minor 
issue left: downstream packages all have to have a FindThrift.cmake script. 
This is slightly annoying, because it replicates the same detection script over 
and over in all downstream packages.

Modern cmake suggests a nice solution: the use of package configuration files 
(see 
[https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#package-configuration-file).]
 With package configuration files, after building thrift, downstream packages 
can just use
{noformat}
find_package(thrift){noformat}
and the library and compiler are "auto-magically" resolved. Transitive package 
dependencies are also resolved, and even build settings like compiler flags can 
be passed on.

I have created a package configuration for thrift cmake build. Could this be 
considered for inclusion?

  was:
The thrift build with cmake is really great. There is only a minor issue left, 
that downstream packages have to have a FindThrift.cmake script to correctly 
find and use the library and compiler.

Modern cmake suggests as a better solution the use of package configuration 
files (see 
[https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#package-configuration-file).]
 Thanks to package configuration, all users of thrift can just 
find_package(thrift) and use the library and compiler without further work. 
Transitive package dependencies are also resolved.

I have created a package configuration for thrift cmake build. Could this be 
considered for inclusion?


> Add cmake package configuration support?
> 
>
> Key: THRIFT-4752
> URL: https://issues.apache.org/jira/browse/THRIFT-4752
> Project: Thrift
>  Issue Type: Improvement
>  Components: Deployment
>Affects Versions: 1.0
>Reporter: Mario Emmenlauer
>Priority: Trivial
>  Labels: cmake
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The thrift build with cmake is really great! In my daily use, there is a 
> minor issue left: downstream packages all have to have a FindThrift.cmake 
> script. This is slightly annoying, because it replicates the same detection 
> script over and over in all downstream packages.
> Modern cmake suggests a nice solution: the use of package configuration files 
> (see 
> [https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#package-configuration-file).]
>  With package configuration files, after building thrift, downstream packages 
> can just use
> {noformat}
> find_package(thrift){noformat}
> and the library and compiler are "auto-magically" resolved. Transitive 
> package dependencies are also resolved, and even build settings like compiler 
> flags can be passed on.
> I have created a package configuration for thrift cmake build. Could this be 
> considered for inclusion?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4759) Minor missing symbol apache::thrift::GlobalOutput for Windows shared library build

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4759:


 Summary: Minor missing symbol apache::thrift::GlobalOutput for 
Windows shared library build
 Key: THRIFT-4759
 URL: https://issues.apache.org/jira/browse/THRIFT-4759
 Project: Thrift
  Issue Type: Improvement
Affects Versions: 1.0
Reporter: Mario Emmenlauer


Current trunk has a minor problem when creating a shared library build with 
cmake on Windows with MSVC 2015 and MSVC 2017. It seems one of the symbols is 
not defined, even when 
CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS is on:
{code:java}
TZlibTransport.cpp.obj : error LNK2001: unresolved external symbol "class 
apache::thrift::TOutput apache::thrift::GlobalOutput" 
(?GlobalOutput@thrift@apache@@3VTOutput@12@A)
bin\thriftzmd.dll : fatal error LNK1120: 1 unresolved externals{code}
I don't know why this symbols fails for cmake. But if you want to go another 
route with explicitly exporting all relevant classes, and you need help to 
create a cmake-based dllimport/dllexport-integration, I can offer some help.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4759) Minor missing symbol apache::thrift::GlobalOutput for Windows shared library build

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752968#comment-16752968
 ] 

Mario Emmenlauer commented on THRIFT-4759:
--

I have created a PR that makes a shared library build on Windows possible. The 
PR includes also all changes required to proceed with Step two. By including 
the header thrift_export.h and using the macro THRIFT_EXPORT in class 
definitions, classes can be explicitly exported or hidden.

Please review.

> Minor missing symbol apache::thrift::GlobalOutput for Windows shared library 
> build
> --
>
> Key: THRIFT-4759
> URL: https://issues.apache.org/jira/browse/THRIFT-4759
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.12.0
>Reporter: Mario Emmenlauer
>Priority: Trivial
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Current trunk has a minor problem when creating a shared library build with 
> cmake on Windows with MSVC 2015 and MSVC 2017. It seems one of the symbols is 
> not defined, even when 
> CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS is on:
> {code:java}
> TZlibTransport.cpp.obj : error LNK2001: unresolved external symbol "class 
> apache::thrift::TOutput apache::thrift::GlobalOutput" 
> (?GlobalOutput@thrift@apache@@3VTOutput@12@A)
> bin\thriftzmd.dll : fatal error LNK1120: 1 unresolved externals{code}
> I don't know why this symbols fails for cmake. But if you want to go another 
> route with explicitly exporting all relevant classes, and you need help to 
> create a cmake-based dllimport/dllexport-integration, I can offer some help.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4752) Add cmake package configuration support?

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753092#comment-16753092
 ] 

Mario Emmenlauer commented on THRIFT-4752:
--

What version should be set if the issue was experienced in current trunk (in 
the master branch HEAD revision)? I was seting the version that trunk currently 
reports, but I can also leave version empty if thats better?

> Add cmake package configuration support?
> 
>
> Key: THRIFT-4752
> URL: https://issues.apache.org/jira/browse/THRIFT-4752
> Project: Thrift
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Mario Emmenlauer
>Priority: Trivial
>  Labels: cmake
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The thrift build with cmake is really great! In my daily use, there is a 
> minor issue left: downstream packages all have to have a FindThrift.cmake 
> script. This is slightly annoying, because it replicates the same detection 
> script over and over in all downstream packages.
> Modern cmake suggests a nice solution: the use of package configuration files 
> (see 
> [https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#package-configuration-file).]
>  With package configuration files, after building thrift, downstream packages 
> can just use
> {noformat}
> find_package(thrift){noformat}
> and the library and compiler are "auto-magically" resolved. Transitive 
> package dependencies are also resolved, and even build settings like compiler 
> flags can be passed on.
> I have created a package configuration for thrift cmake build. Could this be 
> considered for inclusion?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753407#comment-16753407
 ] 

Mario Emmenlauer commented on THRIFT-2426:
--

Is there anything that can be done to progress with this issue? I fail to 
understand why only the fbthrift team can submit their work. In my (naiive) 
understanding the license should allow integration of the code into other 
projects, as long as copyright and license are respected/preserved?

In any case, could I (as an independent third party) do anything to help?

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753427#comment-16753427
 ] 

Mario Emmenlauer commented on THRIFT-2426:
--

Ok, for what its worth I have kindly asked for IP clearance again. Lets see 
what comes out of it.

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16753446#comment-16753446
 ] 

Mario Emmenlauer commented on THRIFT-2426:
--

Dear [~codesf] thanks a lot, _now_ I see the problem. I was looking only on the 
fbthrift side of things but now I realize that Apache also has a hurdle to 
ingest the code.

For (2) I have kindly asked for IP clearance in 
[https://github.com/facebook/fbthrift/issues/309] but I understand this may not 
be easy to get. Still I think its relevant to keep trying.

For (1) the main hurdle may be that I am not knowledgeable to compile a useful 
patch. I can see certain relevant features that seem attractive, but the 
fbthrift code has deviated quite a bit so I'm unsure which parts are relevant 
and which aren't. Or would it make sense to just diff the current head 
revisions and get that approved as a patch, so that you can take out the 
relevant parts yourself?

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-2426) clarify IP rights and contributions from fbthrift

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754717#comment-16754717
 ] 

Mario Emmenlauer commented on THRIFT-2426:
--

If someone can guide my through the process I'm of course open to create PR's 
and try to get them signed off. I guess the cpp2 server would be great? How 
self-contained is it?

> clarify IP rights and contributions from fbthrift 
> --
>
> Key: THRIFT-2426
> URL: https://issues.apache.org/jira/browse/THRIFT-2426
> Project: Thrift
>  Issue Type: Story
>  Components: Documentation
>Reporter: Roger Meier
>Assignee: James E. King III
>Priority: Critical
>
> We need to ensure that we have the IP rights to anything we commit from
> fbthrift and its traceable back on our dev list initiated from someone at 
> facebook.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4819) All exceptions are TException

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4819:
-
Description: 
In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a but in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
{code}
try{
vClient->SendRequest();
} catch (const MyService::UserException& vEx) {
// TODO why is this not caught
std::cerr << "Caught a UserException" << vEx.what() << std::endl;
} catch (const std::exception& vEx) {
std::cerr << "Caught a std::exception, message " << vEx.what() << std::endl;
}
{code}

  was:
In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a but in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
try {vClient->SendRequest();} catch (const 
MyService::UserException& vEx) {// TODO why is this not caught  
  std::cerr << "Caught a UserException" << vEx.what() << std::endl;} 
catch (const std::exception& vEx) {std::cerr << "Caught a 
std::exception, message " << vEx.what() << std::endl;}


> All exceptions are TException
> -
>
> Key: THRIFT-4819
> URL: https://issues.apache.org/jira/browse/THRIFT-4819
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.13.0
>Reporter: Mario Emmenlauer
>Priority: Major
>
> In recent versions of thrift we can not exceptions based on their IDL type 
> anymore. I'm not sure if we broke something, but the code is sufficiently 
> simple to suggest a but in thrift. So here is what we have:
>  # A method with signature that can throw a specific exception, i.e. 
> UserException
>  # The C++ server throws this exception whenever the method is called
>  # The C++ client tries to catch this exception but it passes through
> The client can catch the exception as `TException` or as `std::exception` and 
> we can see from the printed message `vException.what()` that its a 
> `UserException`. But catch does not deduce the type correctly.
> Here is the part of the catch that does not work:
> {code}
> try{
> vClient->SendRequest();
> } catch (const MyService::UserException& vEx) {
> // TODO why is this not caught
> std::cerr << "Caught a UserException" << vEx.what() << std::endl;
> } catch (const std::exception& vEx) {
> std::cerr << "Caught a std::exception, message " << vEx.what() << 
> std::endl;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4819) All exceptions are TException

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4819:
-
Description: 
In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a bug in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
{code}
try{
vClient->SendRequest();
} catch (const MyService::UserException& vEx) {
// TODO why is this not caught
std::cerr << "Caught a UserException" << vEx.what() << std::endl;
} catch (const std::exception& vEx) {
std::cerr << "Caught a std::exception, message " << vEx.what() << std::endl;
}
{code}

  was:
In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a but in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
{code}
try{
vClient->SendRequest();
} catch (const MyService::UserException& vEx) {
// TODO why is this not caught
std::cerr << "Caught a UserException" << vEx.what() << std::endl;
} catch (const std::exception& vEx) {
std::cerr << "Caught a std::exception, message " << vEx.what() << std::endl;
}
{code}


> All exceptions are TException
> -
>
> Key: THRIFT-4819
> URL: https://issues.apache.org/jira/browse/THRIFT-4819
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.13.0
>Reporter: Mario Emmenlauer
>Priority: Major
>
> In recent versions of thrift we can not exceptions based on their IDL type 
> anymore. I'm not sure if we broke something, but the code is sufficiently 
> simple to suggest a bug in thrift. So here is what we have:
>  # A method with signature that can throw a specific exception, i.e. 
> UserException
>  # The C++ server throws this exception whenever the method is called
>  # The C++ client tries to catch this exception but it passes through
> The client can catch the exception as `TException` or as `std::exception` and 
> we can see from the printed message `vException.what()` that its a 
> `UserException`. But catch does not deduce the type correctly.
> Here is the part of the catch that does not work:
> {code}
> try{
> vClient->SendRequest();
> } catch (const MyService::UserException& vEx) {
> // TODO why is this not caught
> std::cerr << "Caught a UserException" << vEx.what() << std::endl;
> } catch (const std::exception& vEx) {
> std::cerr << "Caught a std::exception, message " << vEx.what() << 
> std::endl;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (THRIFT-4819) All exceptions are TException

[Mario Emmenlauer (JIRA)]

Mario Emmenlauer created THRIFT-4819:


 Summary: All exceptions are TException
 Key: THRIFT-4819
 URL: https://issues.apache.org/jira/browse/THRIFT-4819
 Project: Thrift
  Issue Type: Bug
  Components: C++ - Library
Affects Versions: 0.13.0
Reporter: Mario Emmenlauer


In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a but in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
try {vClient->SendRequest();} catch (const 
MyService::UserException& vEx) {// TODO why is this not caught  
  std::cerr << "Caught a UserException" << vEx.what() << std::endl;} 
catch (const std::exception& vEx) {std::cerr << "Caught a 
std::exception, message " << vEx.what() << std::endl;}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4819) All exceptions are TException

[Mario Emmenlauer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4819:
-
Description: 
In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a bug in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
{code}
try {
vClient->SendRequest();
} catch (const MyService::UserException& vEx) {
// Why is this not caught, when the server throws MyService::UserException?
std::cerr << "Caught a UserException, message " << vEx.what() << std::endl;
} catch (const std::exception& vEx) {
// Why is this one called instead?
std::cerr << "Caught a std::exception, message " << vEx.what() << std::endl;
}
{code}

  was:
In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a bug in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
{code}
try{
vClient->SendRequest();
} catch (const MyService::UserException& vEx) {
// TODO why is this not caught
std::cerr << "Caught a UserException" << vEx.what() << std::endl;
} catch (const std::exception& vEx) {
std::cerr << "Caught a std::exception, message " << vEx.what() << std::endl;
}
{code}


> All exceptions are TException
> -
>
> Key: THRIFT-4819
> URL: https://issues.apache.org/jira/browse/THRIFT-4819
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.13.0
>Reporter: Mario Emmenlauer
>Priority: Major
>
> In recent versions of thrift we can not exceptions based on their IDL type 
> anymore. I'm not sure if we broke something, but the code is sufficiently 
> simple to suggest a bug in thrift. So here is what we have:
>  # A method with signature that can throw a specific exception, i.e. 
> UserException
>  # The C++ server throws this exception whenever the method is called
>  # The C++ client tries to catch this exception but it passes through
> The client can catch the exception as `TException` or as `std::exception` and 
> we can see from the printed message `vException.what()` that its a 
> `UserException`. But catch does not deduce the type correctly.
> Here is the part of the catch that does not work:
> {code}
> try {
> vClient->SendRequest();
> } catch (const MyService::UserException& vEx) {
> // Why is this not caught, when the server throws 
> MyService::UserException?
> std::cerr << "Caught a UserException, message " << vEx.what() << 
> std::endl;
> } catch (const std::exception& vEx) {
> // Why is this one called instead?
> std::cerr << "Caught a std::exception, message " << vEx.what() << 
> std::endl;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (THRIFT-4752) Add cmake package configuration support?

[Mario Emmenlauer (JIRA)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16798503#comment-16798503
 ] 

Mario Emmenlauer commented on THRIFT-4752:
--

The code from the PR for THRIFT-4811 works for me! Thanks for adding it.

> Add cmake package configuration support?
> 
>
> Key: THRIFT-4752
> URL: https://issues.apache.org/jira/browse/THRIFT-4752
> Project: Thrift
>  Issue Type: Improvement
>  Components: Deployment
>Reporter: Mario Emmenlauer
>Assignee: James E. King III
>Priority: Trivial
>  Labels: cmake
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The thrift build with cmake is really great! In my daily use, there is a 
> minor issue left: downstream packages all have to have a FindThrift.cmake 
> script. This is slightly annoying, because it replicates the same detection 
> script over and over in all downstream packages.
> Modern cmake suggests a nice solution: the use of package configuration files 
> (see 
> [https://cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html#package-configuration-file).]
>  With package configuration files, after building thrift, downstream packages 
> can just use
> {noformat}
> find_package(thrift){noformat}
> and the library and compiler are "auto-magically" resolved. Transitive 
> package dependencies are also resolved, and even build settings like compiler 
> flags can be passed on.
> I have created a package configuration for thrift cmake build. Could this be 
> considered for inclusion?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (THRIFT-4819) All exceptions are TException

[Mario Emmenlauer (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4819:
-
Description: 
In recent versions of thrift we can not catch exceptions based on their IDL 
type anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a bug in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
{code}
try {
vClient->SendRequest();
} catch (const MyService::UserException& vEx) {
// Why is this not caught, when the server throws MyService::UserException?
std::cerr << "Caught a UserException, message " << vEx.what() << std::endl;
} catch (const std::exception& vEx) {
// Why is this one called instead?
std::cerr << "Caught a std::exception, message " << vEx.what() << std::endl;
}
{code}

  was:
In recent versions of thrift we can not exceptions based on their IDL type 
anymore. I'm not sure if we broke something, but the code is sufficiently 
simple to suggest a bug in thrift. So here is what we have:
 # A method with signature that can throw a specific exception, i.e. 
UserException
 # The C++ server throws this exception whenever the method is called
 # The C++ client tries to catch this exception but it passes through

The client can catch the exception as `TException` or as `std::exception` and 
we can see from the printed message `vException.what()` that its a 
`UserException`. But catch does not deduce the type correctly.

Here is the part of the catch that does not work:
{code}
try {
vClient->SendRequest();
} catch (const MyService::UserException& vEx) {
// Why is this not caught, when the server throws MyService::UserException?
std::cerr << "Caught a UserException, message " << vEx.what() << std::endl;
} catch (const std::exception& vEx) {
// Why is this one called instead?
std::cerr << "Caught a std::exception, message " << vEx.what() << std::endl;
}
{code}


> All exceptions are TException
> -
>
> Key: THRIFT-4819
> URL: https://issues.apache.org/jira/browse/THRIFT-4819
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.13.0
>Reporter: Mario Emmenlauer
>Priority: Major
>
> In recent versions of thrift we can not catch exceptions based on their IDL 
> type anymore. I'm not sure if we broke something, but the code is 
> sufficiently simple to suggest a bug in thrift. So here is what we have:
>  # A method with signature that can throw a specific exception, i.e. 
> UserException
>  # The C++ server throws this exception whenever the method is called
>  # The C++ client tries to catch this exception but it passes through
> The client can catch the exception as `TException` or as `std::exception` and 
> we can see from the printed message `vException.what()` that its a 
> `UserException`. But catch does not deduce the type correctly.
> Here is the part of the catch that does not work:
> {code}
> try {
> vClient->SendRequest();
> } catch (const MyService::UserException& vEx) {
> // Why is this not caught, when the server throws 
> MyService::UserException?
> std::cerr << "Caught a UserException, message " << vEx.what() << 
> std::endl;
> } catch (const std::exception& vEx) {
> // Why is this one called instead?
> std::cerr << "Caught a std::exception, message " << vEx.what() << 
> std::endl;
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (THRIFT-4946) Memory corruption in SecurityTest

[Mario Emmenlauer (Jira)]

Mario Emmenlauer created THRIFT-4946:


 Summary: Memory corruption in SecurityTest
 Key: THRIFT-4946
 URL: https://issues.apache.org/jira/browse/THRIFT-4946
 Project: Thrift
  Issue Type: Bug
Affects Versions: 0.12.0
 Environment:  * thrift latest master
 * Operating Systems and Compilers:
* VS2017 x64
* VS2019 x64
* macOS 10.13
* Ubuntu 18.04 x86_64
 * OpenSSL 1.1.1c (current latest official)
Reporter: Mario Emmenlauer


We observe a memory corruption in SecurityTest. The issue is not fully 
reproducible: it appears on average in 1 out of 10 executions. However it is 
not dependent on the environment because can reproduce the problem on Windows 
VS2017 x64, VS2019 x64, macOS 10.13, and Ubuntu 18.04 x86_64.

On Linux the issue is often reported as:
{code}
[...]
TEST: Server = TLSv1_2, Client = TLSv1_1
CLI 7f1be2eaa700 Exception: SSL_connect: tlsv1 alert protocol version 
(SSL_error_code = 1)
Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
SRV 7f1be38bd700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
double free or corruption (out)
unknown location(0): fatal error: in "SecurityTest/ssl_security_matrix": 
signal: SIGABRT (application abort requested)
/builds/thrift/lib/cpp/test/SecurityTest.cpp(173): last checkpoint
{code}

But other forms also appear, for example:
{code}
[...]
Thrift: Mon Sep  2 07:50:53 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
TEST: Server = TLSv1_2, Client = TLSv1_2
corrupted size vs. prev_size
{code}

We tried to isolate a call stack for the problem but have failed so far. The 
boost message log does not always point to the same protocol combination. We 
executed the test in `valgrind` but it does never crash there.

This could indicate a multi-threading issue with the creation of server and 
client in the test?



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (THRIFT-4946) Memory corruption in SecurityTest

[Mario Emmenlauer (Jira)]

 [ 
https://issues.apache.org/jira/browse/THRIFT-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Emmenlauer updated THRIFT-4946:
-
Description: 
We observe a memory corruption in SecurityTest. The issue is not fully 
reproducible: it appears on average in 1 out of 10 executions. However it is 
not dependent on the environment because can reproduce the problem on Windows 
VS2017 x64, VS2019 x64, macOS 10.13, and Ubuntu 18.04 x86_64.

On Linux the issue is often reported as:
{code}
[...]
TEST: Server = TLSv1_2, Client = TLSv1_1
CLI 7f1be2eaa700 Exception: SSL_connect: tlsv1 alert protocol version 
(SSL_error_code = 1)
Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
SRV 7f1be38bd700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
double free or corruption (out)
unknown location(0): fatal error: in "SecurityTest/ssl_security_matrix": 
signal: SIGABRT (application abort requested)
/builds/thrift/lib/cpp/test/SecurityTest.cpp(173): last checkpoint
{code}

But other forms also appear, for example:
{code}
[...]
Thrift: Mon Sep  2 07:50:53 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
TEST: Server = TLSv1_2, Client = TLSv1_2
corrupted size vs. prev_size
{code}

We tried to isolate a call stack for the problem but have failed so far. The 
boost message log does not always point to the same protocol combination. We 
executed the test in `valgrind` but it does never crash there. With `gdb` we 
can create a stack trace but it does not mean much to me:
{code}
EST: Server = TLSv1_2, Client = TLSv1_0
[New Thread 0x7f940fd05700 (LWP 1903)]
[New Thread 0x7f9410718700 (LWP 1904)]
CLI 7f9410718700 Exception: SSL_connect: tlsv1 alert protocol version 
(SSL_error_code = 1)
Thrift: Mon Sep  2 08:36:14 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
SRV 7f940fd05700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
Thrift: Mon Sep  2 08:36:14 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
double free or corruption (out)
[Thread 0x7f9410718700 (LWP 1904) exited]

Thread 28 "SecurityTest" received signal SIGABRT, Aborted.
[Switching to Thread 0x7f940fd05700 (LWP 1903)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7f9410b73801 in __GI_abort () at abort.c:79
#2  0x7f9410bbc897 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f9410ce9b9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x7f9410bc390a in malloc_printerr (str=str@entry=0x7f9410ceb870 "double 
free or corruption (out)") at malloc.c:5350
#4  0x7f9410cceeb9 in _int_free (have_lock=0, p=0x7f940800cd70, 
av=0x7f9410f1ec40 ) at malloc.c:4278
#5  __GI___libc_free (mem=0x7f940800cd80) at malloc.c:3124
#6  tcache_thread_shutdown () at malloc.c:2969
#7  arena_thread_freeres () at arena.c:950
#8  0x7f9410ccf652 in __libc_thread_freeres () at thread-freeres.c:29
#9  0x7f94121bb700 in start_thread (arg=0x7f940fd05700) at 
pthread_create.c:476
#10 0x7f9410c5488f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
{code}

This could indicate a multi-threading issue with the creation of server and/or 
client in the test?

  was:
We observe a memory corruption in SecurityTest. The issue is not fully 
reproducible: it appears on average in 1 out of 10 executions. However it is 
not dependent on the environment because can reproduce the problem on Windows 
VS2017 x64, VS2019 x64, macOS 10.13, and Ubuntu 18.04 x86_64.

On Linux the issue is often reported as:
{code}
[...]
TEST: Server = TLSv1_2, Client = TLSv1_1
CLI 7f1be2eaa700 Exception: SSL_connect: tlsv1 alert protocol version 
(SSL_error_code = 1)
Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
SRV 7f1be38bd700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
double free or corruption (out)
unknown location(0): fatal error: in "SecurityTest/ssl_security_matrix": 
signal: SIGABRT (application abort requested)
/builds/thrift/lib/cpp/test/SecurityTest.cpp(173): last checkpoint
{code}

But other forms also appear, for example:
{code}
[...]
Thrift: Mon Sep  2 07:50:53 2019 SSL_shutdown: shutdown while in init 
(SSL_error_code = 1)
TEST: Server = TLSv1_2, Client = TLSv1_2
corrupted size vs. prev_size
{code}

We tried to isolate a call stack for the problem but have f

[jira] [Commented] (THRIFT-4946) Memory corruption in SecurityTest

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933735#comment-16933735
 ] 

Mario Emmenlauer commented on THRIFT-4946:
--

Can anyone confirm issues with SecurityTest on any platform, i.e. on Windows? 
Its a repeated issue for us since a few months (updated thrift and OpenSSL), 
typically 2 in 3 executions fail.

> Memory corruption in SecurityTest
> -
>
> Key: THRIFT-4946
> URL: https://issues.apache.org/jira/browse/THRIFT-4946
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.12.0
> Environment:  * thrift latest master
>  * Operating Systems and Compilers:
> * VS2017 x64
> * VS2019 x64
> * macOS 10.13
> * Ubuntu 18.04 x86_64
>  * OpenSSL 1.1.1c (current latest official)
>Reporter: Mario Emmenlauer
>Priority: Major
>
> We observe a memory corruption in SecurityTest. The issue is not fully 
> reproducible: it appears on average in 1 out of 10 executions. However it is 
> not dependent on the environment because can reproduce the problem on Windows 
> VS2017 x64, VS2019 x64, macOS 10.13, and Ubuntu 18.04 x86_64.
> On Linux the issue is often reported as:
> {code}
> [...]
> TEST: Server = TLSv1_2, Client = TLSv1_1
> CLI 7f1be2eaa700 Exception: SSL_connect: tlsv1 alert protocol version 
> (SSL_error_code = 1)
> Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> SRV 7f1be38bd700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
> error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
> Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> double free or corruption (out)
> unknown location(0): fatal error: in "SecurityTest/ssl_security_matrix": 
> signal: SIGABRT (application abort requested)
> /builds/thrift/lib/cpp/test/SecurityTest.cpp(173): last checkpoint
> {code}
> But other forms also appear, for example:
> {code}
> [...]
> Thrift: Mon Sep  2 07:50:53 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> TEST: Server = TLSv1_2, Client = TLSv1_2
> corrupted size vs. prev_size
> {code}
> We tried to isolate a call stack for the problem but have failed so far. The 
> boost message log does not always point to the same protocol combination. We 
> executed the test in `valgrind` but it does never crash there. With `gdb` we 
> can create a stack trace but it does not mean much to me:
> {code}
> EST: Server = TLSv1_2, Client = TLSv1_0
> [New Thread 0x7f940fd05700 (LWP 1903)]
> [New Thread 0x7f9410718700 (LWP 1904)]
> CLI 7f9410718700 Exception: SSL_connect: tlsv1 alert protocol version 
> (SSL_error_code = 1)
> Thrift: Mon Sep  2 08:36:14 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> SRV 7f940fd05700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
> error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
> Thrift: Mon Sep  2 08:36:14 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> double free or corruption (out)
> [Thread 0x7f9410718700 (LWP 1904) exited]
> Thread 28 "SecurityTest" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7f940fd05700 (LWP 1903)]
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f9410b73801 in __GI_abort () at abort.c:79
> #2  0x7f9410bbc897 in __libc_message (action=action@entry=do_abort, 
> fmt=fmt@entry=0x7f9410ce9b9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> #3  0x7f9410bc390a in malloc_printerr (str=str@entry=0x7f9410ceb870 
> "double free or corruption (out)") at malloc.c:5350
> #4  0x7f9410cceeb9 in _int_free (have_lock=0, p=0x7f940800cd70, 
> av=0x7f9410f1ec40 ) at malloc.c:4278
> #5  __GI___libc_free (mem=0x7f940800cd80) at malloc.c:3124
> #6  tcache_thread_shutdown () at malloc.c:2969
> #7  arena_thread_freeres () at arena.c:950
> #8  0x7f9410ccf652 in __libc_thread_freeres () at thread-freeres.c:29
> #9  0x7f94121bb700 in start_thread (arg=0x7f940fd05700) at 
> pthread_create.c:476
> #10 0x7f9410c5488f in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> {code}
> This could indicate a multi-threading issue with the creation of server 
> and/or client in the test?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (THRIFT-4946) Memory corruption in SecurityTest

[Mario Emmenlauer (Jira)]

[ 
https://issues.apache.org/jira/browse/THRIFT-4946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933756#comment-16933756
 ] 

Mario Emmenlauer commented on THRIFT-4946:
--

Thanks for the quick reply!

??Wild guess without even looking at the code: Could it be connected to a race 
condition when SSL is used from multiple threads???

That would make sense in the context of the test. However I tried to fix all 
possible race conditions I could think of in the test, and to the best of my 
knowledge there should be none. There are mutexes in place that (according to 
my understanding) should make sure that the server is fully initialized before 
the client even gets a chance. Otherwise the test could have never worked 
reliably because the connection-attempt would have come before the server is 
ready.

Cutting a long story short, I'm at the end of my wit. Any help would be 
appreciated. Maybe its nothing but it seems worrying that basic thirft ssl 
tests fail in a majority of cases for us.

> Memory corruption in SecurityTest
> -
>
> Key: THRIFT-4946
> URL: https://issues.apache.org/jira/browse/THRIFT-4946
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.12.0
> Environment:  * thrift latest master
>  * Operating Systems and Compilers:
> * VS2017 x64
> * VS2019 x64
> * macOS 10.13
> * Ubuntu 18.04 x86_64
>  * OpenSSL 1.1.1c (current latest official)
>Reporter: Mario Emmenlauer
>Priority: Major
>
> We observe a memory corruption in SecurityTest. The issue is not fully 
> reproducible: it appears on average in 1 out of 10 executions. However it is 
> not dependent on the environment because can reproduce the problem on Windows 
> VS2017 x64, VS2019 x64, macOS 10.13, and Ubuntu 18.04 x86_64.
> On Linux the issue is often reported as:
> {code}
> [...]
> TEST: Server = TLSv1_2, Client = TLSv1_1
> CLI 7f1be2eaa700 Exception: SSL_connect: tlsv1 alert protocol version 
> (SSL_error_code = 1)
> Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> SRV 7f1be38bd700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
> error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
> Thrift: Mon Sep  2 07:51:32 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> double free or corruption (out)
> unknown location(0): fatal error: in "SecurityTest/ssl_security_matrix": 
> signal: SIGABRT (application abort requested)
> /builds/thrift/lib/cpp/test/SecurityTest.cpp(173): last checkpoint
> {code}
> But other forms also appear, for example:
> {code}
> [...]
> Thrift: Mon Sep  2 07:50:53 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> TEST: Server = TLSv1_2, Client = TLSv1_2
> corrupted size vs. prev_size
> {code}
> We tried to isolate a call stack for the problem but have failed so far. The 
> boost message log does not always point to the same protocol combination. We 
> executed the test in `valgrind` but it does never crash there. With `gdb` we 
> can create a stack trace but it does not mean much to me:
> {code}
> EST: Server = TLSv1_2, Client = TLSv1_0
> [New Thread 0x7f940fd05700 (LWP 1903)]
> [New Thread 0x7f9410718700 (LWP 1904)]
> CLI 7f9410718700 Exception: SSL_connect: tlsv1 alert protocol version 
> (SSL_error_code = 1)
> Thrift: Mon Sep  2 08:36:14 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> SRV 7f940fd05700 Exception: SSL_accept: error code: 0 (SSL_error_code = 5) 
> error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
> Thrift: Mon Sep  2 08:36:14 2019 SSL_shutdown: shutdown while in init 
> (SSL_error_code = 1)
> double free or corruption (out)
> [Thread 0x7f9410718700 (LWP 1904) exited]
> Thread 28 "SecurityTest" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7f940fd05700 (LWP 1903)]
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x7f9410b73801 in __GI_abort () at abort.c:79
> #2  0x7f9410bbc897 in __libc_message (action=action@entry=do_abort, 
> fmt=fmt@entry=0x7f9410ce9b9a "%s\n") at ../sysdeps/posix/libc_fatal.c:181
> #3  0x7f9410bc390a in malloc_printerr (str=str@entry=0x7f9410ceb870 
> "double free or corruption (out)") at malloc.c:5350
> #4  0x7f9410cceeb9 in _int_free (have_lock=0, p=0x7f940800cd70, 
> av=0x7f9410f1ec40 ) at malloc.c:4278
> #5  __GI___libc_free (mem=0x7f940800cd80) at malloc.c:3124
> #6  tcache_thread_shutdown () at malloc.c:2969
> #7  arena_thread_freeres () at arena.c:950
> #8  0x7f9410ccf652 in __libc_thread_freeres () at thread-freeres.c:29
> #9  0x7f94121b