[jira] [Commented] (THRIFT-5498) Fails to build with gcc 12
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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++
[ 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++
[ 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 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++
[ 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 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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.
[ 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
[ 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
[ 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
[ 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 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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?
[ 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 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
[ 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?
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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 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
[ 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?
[ 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
[ 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 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
[ 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
[ 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
[ 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