[jira] [Assigned] (THRIFT-4842) Multiplexed protocol has a memory leak in set c_glib
[ https://issues.apache.org/jira/browse/THRIFT-4842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar reassigned THRIFT-4842: --- Assignee: Gonzalo Aguilar > Multiplexed protocol has a memory leak in set c_glib > > > Key: THRIFT-4842 > URL: https://issues.apache.org/jira/browse/THRIFT-4842 > Project: Thrift > Issue Type: Bug >Affects Versions: 0.12.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar >Priority: Major > Fix For: 0.12.1 > > Time Spent: 10m > Remaining Estimate: 0h > > The multiplexed protocol is affected by a memory leak in set property in the > c_gllib version when setting the service to be multiplexed. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4842) Multiplexed protocol has a memory leak in set c_glib
Gonzalo Aguilar created THRIFT-4842: --- Summary: Multiplexed protocol has a memory leak in set c_glib Key: THRIFT-4842 URL: https://issues.apache.org/jira/browse/THRIFT-4842 Project: Thrift Issue Type: Bug Affects Versions: 0.12.0 Reporter: Gonzalo Aguilar Fix For: 0.12.1 The multiplexed protocol is affected by a memory leak in set property in the c_gllib version when setting the service to be multiplexed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (THRIFT-4533) C Framed transport causes sigsev from time to time
Gonzalo Aguilar created THRIFT-4533:
---
Summary: C Framed transport causes sigsev from time to time
Key: THRIFT-4533
URL: https://issues.apache.org/jira/browse/THRIFT-4533
Project: Thrift
Issue Type: Bug
Components: C glib - Library
Affects Versions: 0.10.0
Reporter: Gonzalo Aguilar
It seems that from time to time Apache Thrift receives a package that doesn't
complies with what's expected and it causes a sigsev.
It happens reading the frame.
{{Thread #1 [sg64_hardware_m] 14184 [core: 22] (Suspended : Signal :
SIGSEGV:Segmentation fault) }}
{{ thrift_framed_transport_read_frame() at
/home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/transport/thrift_framed_transport.c:98
0x77bc9bbd }}
{{ thrift_framed_transport_read_slow() at
/home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/transport/thrift_framed_transport.c:134
0x77bc9c3f }}
{{ thrift_transport_real_read_all() at
/home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/transport/thrift_transport.c:122
0x77bc6004 }}
{{ thrift_binary_protocol_read_i32() at
/home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/protocol/thrift_binary_protocol.c:712
0x77bc27ee }}
{{ thrift_binary_protocol_read_message_begin() at
/home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/protocol/thrift_binary_protocol.c:410
0x77bc20b0 }}
{{ thrift_multiplexed_processor_process_impl() at
/home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/processor/thrift_multiplexed_processor.c:83
0x77bbf38b }}
{{ thrift_simple_server_serve() at
/home/gaguilar/thrift/thrift/lib/c_glib/src/thrift/c_glib/server/thrift_simple_server.c:58
0x77bcac25 }}
{{ main() at
/home/gaguilar/workspace-c/moverick-hardware-monitor/src/sg64_hardware_monitor_main.c:254
0x7dd3 }}
{{}}{{transport ThriftTransport * 0x55825440 }}
{{transport@entry ThriftTransport * 0x55825440 }}
{{error GError ** 0x7fffca60 }}
{{error@entry GError ** 0x7fffca60 }}
{{tmpdata guchar * 0x7fffe9fcc760 }}
{{t ThriftFramedTransport * 0x55825440 }}
{{sz guint32 369295616 }}
{{bytes gint32 }}
{{result gboolean 0 }}
As can be seen it's requesting about 370Mb. So I suppose it's a spurious
message that arrived over wire. Maybe a port scanning. I have reports that it
happens even when nothing is connected to the wire. Something it seems strange
to me.
I cannot see how may bytes are read because compiler optimized it. But I can
see that it looks like system allocated that memory into tmpdata. What seems
weird is that compiler cannot access that memory direction. So I wonder if that
address is wrong and causing the sigsev.
A possible patch is to know in advance how many bytes a package can have, and
therefore set a limit to what we can allocate and read. The problem is that we
must know about the upper layers something that breaks a little bit the layered
design.
What do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (THRIFT-4050) Skip() should throw TProtocolException.INVALID_DATA on unknown data types
[ https://issues.apache.org/jira/browse/THRIFT-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16178683#comment-16178683 ] Gonzalo Aguilar commented on THRIFT-4050: - I don't know about this issue, can't see anything relevant on the issue, I don't know what's referring to. But if we must modify I'll do it. > Skip() should throw TProtocolException.INVALID_DATA on unknown data types > - > > Key: THRIFT-4050 > URL: https://issues.apache.org/jira/browse/THRIFT-4050 > Project: Thrift > Issue Type: Sub-task > Components: C glib - Library >Reporter: Jens Geyer >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4050) Skip() should throw TProtocolException.INVALID_DATA on unknown data types
[ https://issues.apache.org/jira/browse/THRIFT-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16178682#comment-16178682 ] Gonzalo Aguilar commented on THRIFT-4050: - I don't know about this issue, can't see anything relevant on the issue, I don't know what's referring to. But if we must modify I'll do it. > Skip() should throw TProtocolException.INVALID_DATA on unknown data types > - > > Key: THRIFT-4050 > URL: https://issues.apache.org/jira/browse/THRIFT-4050 > Project: Thrift > Issue Type: Sub-task > Components: C glib - Library >Reporter: Jens Geyer >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (THRIFT-4332) Binary protocol has memory leaks
[ https://issues.apache.org/jira/browse/THRIFT-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar closed THRIFT-4332. --- Resolution: Fixed > Binary protocol has memory leaks > > > Key: THRIFT-4332 > URL: https://issues.apache.org/jira/browse/THRIFT-4332 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.11.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > > It seems that binary protocol has memory leaks, it's loosing few bytes per > request. > ==4534== 2,399,952 bytes in 99,998 blocks are definitely lost in loss record > 611 of 611 > ==4534== at 0x4C2FB25: calloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4534== by 0x5300580: g_malloc0 (in > /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > ==4534== by 0x4E49774: thrift_binary_protocol_read_string > (thrift_binary_protocol.c:797) > ==4534== by 0x4E48E55: thrift_binary_protocol_read_message_begin > (thrift_binary_protocol.c:431) > ==4534== by 0x4E46013: thrift_multiplexed_processor_process_impl > (thrift_multiplexed_processor.c:60) > ==4534== by 0x4E51864: thrift_simple_server_serve (thrift_simple_server.c:58) > ==4534== by 0x108DAF: test_server_initialize (test_server.c:74) > ==4534== by 0x5321459: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > ==4534== by 0x532138A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > ==4534== by 0x5321631: g_test_run_suite (in > /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > I'm testing on trunk master so will fix it there. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (THRIFT-4332) Binary protocol has memory leaks
[ https://issues.apache.org/jira/browse/THRIFT-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16169648#comment-16169648 ] Gonzalo Aguilar commented on THRIFT-4332: - I will close it since the problem was in the multiplexed that was not releasing a memory string created by read. > Binary protocol has memory leaks > > > Key: THRIFT-4332 > URL: https://issues.apache.org/jira/browse/THRIFT-4332 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.11.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 0.11.0 > > > It seems that binary protocol has memory leaks, it's loosing few bytes per > request. > ==4534== 2,399,952 bytes in 99,998 blocks are definitely lost in loss record > 611 of 611 > ==4534== at 0x4C2FB25: calloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==4534== by 0x5300580: g_malloc0 (in > /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > ==4534== by 0x4E49774: thrift_binary_protocol_read_string > (thrift_binary_protocol.c:797) > ==4534== by 0x4E48E55: thrift_binary_protocol_read_message_begin > (thrift_binary_protocol.c:431) > ==4534== by 0x4E46013: thrift_multiplexed_processor_process_impl > (thrift_multiplexed_processor.c:60) > ==4534== by 0x4E51864: thrift_simple_server_serve (thrift_simple_server.c:58) > ==4534== by 0x108DAF: test_server_initialize (test_server.c:74) > ==4534== by 0x5321459: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > ==4534== by 0x532138A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > ==4534== by 0x5321631: g_test_run_suite (in > /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) > I'm testing on trunk master so will fix it there. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4332) Binary protocol has memory leaks
Gonzalo Aguilar created THRIFT-4332: --- Summary: Binary protocol has memory leaks Key: THRIFT-4332 URL: https://issues.apache.org/jira/browse/THRIFT-4332 Project: Thrift Issue Type: Bug Components: C glib - Library Affects Versions: 0.11.0 Reporter: Gonzalo Aguilar Assignee: Gonzalo Aguilar Fix For: 0.11.0 It seems that binary protocol has memory leaks, it's loosing few bytes per request. ==4534== 2,399,952 bytes in 99,998 blocks are definitely lost in loss record 611 of 611 ==4534== at 0x4C2FB25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==4534== by 0x5300580: g_malloc0 (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) ==4534== by 0x4E49774: thrift_binary_protocol_read_string (thrift_binary_protocol.c:797) ==4534== by 0x4E48E55: thrift_binary_protocol_read_message_begin (thrift_binary_protocol.c:431) ==4534== by 0x4E46013: thrift_multiplexed_processor_process_impl (thrift_multiplexed_processor.c:60) ==4534== by 0x4E51864: thrift_simple_server_serve (thrift_simple_server.c:58) ==4534== by 0x108DAF: test_server_initialize (test_server.c:74) ==4534== by 0x5321459: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) ==4534== by 0x532138A: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) ==4534== by 0x5321631: g_test_run_suite (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.5306.0) I'm testing on trunk master so will fix it there. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-4329: Summary: c_glib Doesn't have a multiplexed processor (was: c_glib multiplexed protocol doesn't support receiving multiplexed messages. Only written) > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 1.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 1.0 > > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (THRIFT-4329) c_glib Doesn't have a multiplexed processor
[ https://issues.apache.org/jira/browse/THRIFT-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-4329: Description: It seems that multiplexed protocol only implements thrift_multiplexed_protocol_write_message_begin that's ok for sending messages to a multiplexed server but not for the C server. We also need a multiplexed processor for the server. was:It seems that multiplexed protocol only implements thrift_multiplexed_protocol_write_message_begin that's ok for sending messages to a multiplexed server but not for the C server. > c_glib Doesn't have a multiplexed processor > --- > > Key: THRIFT-4329 > URL: https://issues.apache.org/jira/browse/THRIFT-4329 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 1.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 1.0 > > > It seems that multiplexed protocol only implements > thrift_multiplexed_protocol_write_message_begin that's ok for sending > messages to a multiplexed server but not for the C server. We also need a > multiplexed processor for the server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4329) c_glib multiplexed protocol doesn't support receiving multiplexed messages. Only written
Gonzalo Aguilar created THRIFT-4329: --- Summary: c_glib multiplexed protocol doesn't support receiving multiplexed messages. Only written Key: THRIFT-4329 URL: https://issues.apache.org/jira/browse/THRIFT-4329 Project: Thrift Issue Type: Bug Components: C glib - Library Affects Versions: 1.0 Reporter: Gonzalo Aguilar Assignee: Gonzalo Aguilar Fix For: 1.0 It seems that multiplexed protocol only implements thrift_multiplexed_protocol_write_message_begin that's ok for sending messages to a multiplexed server but not for the C server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (THRIFT-4212) c_glib flush tries to close SSL even if socket is invalid
Gonzalo Aguilar created THRIFT-4212: --- Summary: c_glib flush tries to close SSL even if socket is invalid Key: THRIFT-4212 URL: https://issues.apache.org/jira/browse/THRIFT-4212 Project: Thrift Issue Type: Bug Components: C glib - Library Affects Versions: 1.0 Reporter: Gonzalo Aguilar Assignee: Gonzalo Aguilar Fix For: 1.0 It seems that SSL is trying to get info from socket even when socket is already invalid, making the app to crash. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4211) Fix GError glib management under Thrift
[ https://issues.apache.org/jira/browse/THRIFT-4211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16024847#comment-16024847 ] Gonzalo Aguilar commented on THRIFT-4211: - It seems we were aborting due to wrong understanding of how g_error works. There's room for improvement but for now it seems correct > Fix GError glib management under Thrift > --- > > Key: THRIFT-4211 > URL: https://issues.apache.org/jira/browse/THRIFT-4211 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 1.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 1.0 > > > It seems that current Gerror management done in thrift is not quite ok and > causes the library to fail. > This issue tracks and fixes all problems found during testing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4211) Fix GError glib management under Thrift
Gonzalo Aguilar created THRIFT-4211: --- Summary: Fix GError glib management under Thrift Key: THRIFT-4211 URL: https://issues.apache.org/jira/browse/THRIFT-4211 Project: Thrift Issue Type: Bug Components: C glib - Library Affects Versions: 1.0 Reporter: Gonzalo Aguilar Assignee: Gonzalo Aguilar Fix For: 1.0 It seems that current Gerror management done in thrift is not quite ok and causes the library to fail. This issue tracks and fixes all problems found during testing. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4205) c_glib is not linking against glib + gobject
Gonzalo Aguilar created THRIFT-4205:
---
Summary: c_glib is not linking against glib + gobject
Key: THRIFT-4205
URL: https://issues.apache.org/jira/browse/THRIFT-4205
Project: Thrift
Issue Type: Improvement
Components: C glib - Library
Affects Versions: 1.0
Reporter: Gonzalo Aguilar
Assignee: Gonzalo Aguilar
Priority: Critical
Fix For: 1.0
The library is not linking against glib and gobject depedencies. It means that
it will work if the library is linked against a program that uses that
libraries but it will fail in environments like Android.
Since the reference to gobject (for example) will not be there and in
System.Loadlibrary('libthrift_c_glib') it will fail to load because missing
symbols.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (THRIFT-4152) HTML Documentation doesn't link correctly structs
[ https://issues.apache.org/jira/browse/THRIFT-4152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15953110#comment-15953110 ] Gonzalo Aguilar commented on THRIFT-4152: - Yes. Don't do it. We want to check what's the correct behavior it should do. And maybe adjust the patch a little bit. We did this as a hotfix for one of our customers. Since otherwise the output was wrong. Let us investigate a little bit more, since we don't know much about the compiler stuff. > HTML Documentation doesn't link correctly structs > - > > Key: THRIFT-4152 > URL: https://issues.apache.org/jira/browse/THRIFT-4152 > Project: Thrift > Issue Type: Bug > Components: HTML - Compiler >Affects Versions: 0.10.0 > Environment: Thrift Master on commit > 431732d39e89f1661dc7dddffedb2c5c1e019cc7 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar >Priority: Minor > > We discovered the html documents are not correctly generated because the > links of structs are sometimes done as Struct and sometimes as Typedef. > None of the Typedef links are working. Mainly because they are Structs in our > case and thus no link is performed. > We made a patch for structs. but we have to check if it works for the rest of > types. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4152) HTML Documentation doesn't link correctly structs
Gonzalo Aguilar created THRIFT-4152: --- Summary: HTML Documentation doesn't link correctly structs Key: THRIFT-4152 URL: https://issues.apache.org/jira/browse/THRIFT-4152 Project: Thrift Issue Type: Bug Components: HTML - Compiler Affects Versions: 1.0 Environment: Thrift Master on commit 431732d39e89f1661dc7dddffedb2c5c1e019cc7 Reporter: Gonzalo Aguilar Assignee: Gonzalo Aguilar Priority: Minor Fix For: 1.0 We discovered the html documents are not correctly generated because the links of structs are sometimes done as Struct and sometimes as Typedef. None of the Typedef links are working. Mainly because they are Structs in our case and thus no link is performed. We made a patch for structs. but we have to check if it works for the rest of types. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4125) Thrift is not compiling
Gonzalo Aguilar created THRIFT-4125: --- Summary: Thrift is not compiling Key: THRIFT-4125 URL: https://issues.apache.org/jira/browse/THRIFT-4125 Project: Thrift Issue Type: Bug Components: Compiler (General) Affects Versions: 1.0 Environment: Version 6582757752e62efea3f9786dddf0260efaa1f450 ARM32 arm-linux-androideabi/4.9 android Reporter: Gonzalo Aguilar Priority: Critical It seems that thrift is not compiling on ARM32 target. I don't know if for others still doesn't work. This was working few weeks before so someone broke it. const&, std::string const&): error: undefined reference to 'std::basic_ios >::fail() const' src/thrift/generate/thrift-t_generator.o:t_generator.cc:function t_generator::generate_docstring_comment(std::ostream&, std::string const&, std::string const&, std::string const&, std::string const&): error: undefined reference to 'std::basic_ostream >& std::endl >(std::basic_ostream >&)' src/thrift/generate/thrift-t_generator.o:t_generator.cc:typeinfo for t_generator: error: undefined reference to 'vtable for __cxxabiv1::__class_type_info' /tmp/ndk-build/android-toolchain-arm/bin/../lib/gcc/arm-linux-androideabi/4.9/../../../../arm-linux-androideabi/bin/ld: the vtable symbol may be undefined because the class is missing its key function src/thrift/libparse.a(thrift_libparse_a-thriftl.o):thriftl.cc:function yylex: error: undefined reference to 'std::string::push_back(char)' collect2: error: ld returned 1 exit status Makefile:1170: fallo en las instrucciones para el objetivo 'thrift' make[3]: *** [thrift] Error 1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4104) Add a CI build job that runs without libevent, openssl, or zlib
[ https://issues.apache.org/jira/browse/THRIFT-4104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897785#comment-15897785 ] Gonzalo Aguilar commented on THRIFT-4104: - I can fix for autotools but no idea on how to do it for CMake. If I have time I will try to take a look also to it. > Add a CI build job that runs without libevent, openssl, or zlib > --- > > Key: THRIFT-4104 > URL: https://issues.apache.org/jira/browse/THRIFT-4104 > Project: Thrift > Issue Type: Improvement >Affects Versions: 0.10.0 >Reporter: James E. King, III > > After THRIFT-3369 was committed (passed CI tests) it was found to rely on > openssl being around. Since we support builds without libevent, openssl, and > zlib then we should have a CI build job that builds without them and make > sure build and test still work. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (THRIFT-4108) c_glib thrift ssl has multiple bugs and deprecated functions
[ https://issues.apache.org/jira/browse/THRIFT-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar reassigned THRIFT-4108: --- Assignee: Gonzalo Aguilar > c_glib thrift ssl has multiple bugs and deprecated functions > > > Key: THRIFT-4108 > URL: https://issues.apache.org/jira/browse/THRIFT-4108 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 1.0 >Reporter: Gonzalo Aguilar >Assignee: Gonzalo Aguilar > Fix For: 1.0 > > > The function thrift_ssl_socket_finalize_openssl doesn't work because uses a > deprecated global static variable that should be removed in the latests > patches. It breaks program > Specifically the functions thrift_ssl_socket_new_with_host, > thrift_ssl_socket_new must be removed or refactored. > But due to the fact that the constructor is not able to get Protocol version > to be used with SSL, no one can select the protocol for SSL but LATEST is > always used. > So it must be addressed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4108) c_glib thrift ssl has multiple bugs and deprecated functions
[ https://issues.apache.org/jira/browse/THRIFT-4108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897166#comment-15897166 ] Gonzalo Aguilar commented on THRIFT-4108: - I'm fixing them... > c_glib thrift ssl has multiple bugs and deprecated functions > > > Key: THRIFT-4108 > URL: https://issues.apache.org/jira/browse/THRIFT-4108 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 1.0 >Reporter: Gonzalo Aguilar > Fix For: 1.0 > > > The function thrift_ssl_socket_finalize_openssl doesn't work because uses a > deprecated global static variable that should be removed in the latests > patches. It breaks program > Specifically the functions thrift_ssl_socket_new_with_host, > thrift_ssl_socket_new must be removed or refactored. > But due to the fact that the constructor is not able to get Protocol version > to be used with SSL, no one can select the protocol for SSL but LATEST is > always used. > So it must be addressed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-4108) c_glib thrift ssl has multiple bugs and deprecated functions
Gonzalo Aguilar created THRIFT-4108: --- Summary: c_glib thrift ssl has multiple bugs and deprecated functions Key: THRIFT-4108 URL: https://issues.apache.org/jira/browse/THRIFT-4108 Project: Thrift Issue Type: Bug Components: C glib - Library Affects Versions: 1.0 Reporter: Gonzalo Aguilar Fix For: 1.0 The function thrift_ssl_socket_finalize_openssl doesn't work because uses a deprecated global static variable that should be removed in the latests patches. It breaks program Specifically the functions thrift_ssl_socket_new_with_host, thrift_ssl_socket_new must be removed or refactored. But due to the fact that the constructor is not able to get Protocol version to be used with SSL, no one can select the protocol for SSL but LATEST is always used. So it must be addressed. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880746#comment-15880746 ] Gonzalo Aguilar commented on THRIFT-3369: - Please James, add the bug report. I will do the job on c_glib. but for autoconf. As I'm not proficient with CMake yet. OFFTOPIC: We are testing internally meson + ninja and it's incredible how fast it builds... > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar >Assignee: James E. King, III > Labels: features, patch > Fix For: 0.11.0 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15879131#comment-15879131 ] Gonzalo Aguilar commented on THRIFT-3369: - Yes now is a requirement to have ssl installed. I suppose we can get this out if the library is not installed for development. But I think C++ requires OpenSSL. So does it worth it to opt out SSL? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar >Assignee: James E. King, III > Labels: features, patch > Fix For: 0.11.0 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866087#comment-15866087 ] Gonzalo Aguilar commented on THRIFT-3369: - Why I'm not the committer for this incident? > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar >Assignee: James E. King, III > Labels: features, patch > Fix For: 0.11.0 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4037) [CMake] Use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15863455#comment-15863455 ] Gonzalo Aguilar commented on THRIFT-4037: - Looking at the build time figures. Ninja can be a great addition to the CMake build. It seems it can generate result files so it's okay. > [CMake] Use a single build system for thrift to make development easier > --- > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Epic > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Critical > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # All existing platforms, targets, and tests are converted to use cmake > ## Including cross-compilation > # All CI builds are converted to use cmake > # autoconf build environment is removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4037) [CMake] Use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15862707#comment-15862707 ] Gonzalo Aguilar commented on THRIFT-4037: - I don't like the m4 interface of autotools but I can recognize it's doing a great job outside Windows. Anyway if CMake do the trick and is as extendable as autoconf then we must go for it. There's a problem and must be resolved. And it seems Windows compatibility is highly required. +1 > [CMake] Use a single build system for thrift to make development easier > --- > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Epic > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Critical > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # All existing platforms, targets, and tests are converted to use cmake > ## Including cross-compilation > # All CI builds are converted to use cmake > # autoconf build environment is removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-4037) [CMake] As a developer, I want to use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861329#comment-15861329 ] Gonzalo Aguilar edited comment on THRIFT-4037 at 2/10/17 2:42 PM: -- I understand that all move is to support Windows because the proper lack of tools to build, that are Makes and shell... Since windows doesn't have until very recent a decent shell scripting it's normal that autoconf doesn't fit for windows users. We were talking internally about autoconf, not everyone likes it. We are evaluating about moving from autoconf but today it makes sense for us. Suppose you move everything to CMake. What will you do with the dependencies? Because for example c_glib build requires glib that's currently built with autoconf. And as I said it's building flawlessly in all architectures for linux and android. So in the case you build everything with CMake it doesn't make sense because at least, glib requires autoconf. I must say that also openssl is built with it and maybe many others. So what's the win? Okay you can build thrift with Visual Studio XXX but you cannot build the dependencies. Autotools is a good choice because it only requires Makefiles and shell. And this is a great option. It's true that m4 sucks but's there for a long time. So if you think CMake is the solution we will go for it. But I feel autoconf pretty comfortable. Maybe because not a windows developer. Anyway Windows developers don't use Makefiles they just like Visual Studio. For Mac the support is in so no changes requires. So the title of the task should be something like "Change the build system because my Windows doesn't support it" was (Author: gad): I understand that all move is to support Windows because the proper lack of tools to build, that are Makes and shell... Since windows doesn't have until very recent a decent shell scripting it's normal that autoconf doesn't fit for windows users. > [CMake] As a developer, I want to use a single build system for thrift to > make development easier > - > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Epic > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Critical > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # autoconf build environment is removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (THRIFT-4037) [CMake] As a developer, I want to use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861329#comment-15861329 ] Gonzalo Aguilar edited comment on THRIFT-4037 at 2/10/17 2:23 PM: -- I understand that all move is to support Windows because the proper lack of tools to build, that are Makes and shell... Since windows doesn't have until very recent a decent shell scripting it's normal that autoconf doesn't fit for windows users. was (Author: gad): I understand that all move is to support Windows because the proper lack of tools to build... > [CMake] As a developer, I want to use a single build system for thrift to > make development easier > - > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Epic > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Critical > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # autoconf build environment is removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4037) [CMake] As a developer, I want to use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861329#comment-15861329 ] Gonzalo Aguilar commented on THRIFT-4037: - I understand that all move is to support Windows because the proper lack of tools to build... > [CMake] As a developer, I want to use a single build system for thrift to > make development easier > - > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Epic > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Critical > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # autoconf build environment is removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (THRIFT-4037) [CMake] As a developer, I want to use a single build system for thrift to make development easier
[ https://issues.apache.org/jira/browse/THRIFT-4037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861327#comment-15861327 ] Gonzalo Aguilar commented on THRIFT-4037: - If I can comment on this. I must say that autoconf is able to do everything CMake is able to do but also it gives nice argument like syntax to enable an disable options. It's fully integrated on the main linux developments and it can compile cross chains. We are compiling with autoconf everything. This is, at least, x86, x86_64, arm, arm64v8, mips. So cross compiling is not a problem. The good thing also is that you can generate the full compilation system and package it with the code. Only few cases you need to do an autogen.sh, in that case you can also do it. Ok maybe is not the best tool on windows. But I have a friend that has also Mac Os and it's working perfectly. I suppose that windows guys can use mingw. For the editor support Eclipse supports autotools since long time ago. Configure, and build is fully integrated on the project. > [CMake] As a developer, I want to use a single build system for thrift to > make development easier > - > > Key: THRIFT-4037 > URL: https://issues.apache.org/jira/browse/THRIFT-4037 > Project: Thrift > Issue Type: Epic > Components: Build Process >Affects Versions: 0.10.0 > Environment: All >Reporter: James E. King, III >Assignee: James E. King, III >Priority: Critical > > h1. Background > The thrift project currently carries two build systems. The original build > system is based on autoconf and is used to build a complete deliverable > including extensive cross-language testing. > The other build system was introduced a few years ago, with roots tracing > back to THRIFT-797. CMake allows thrift to build natively on multiple > platforms - unix and windows. Autoconf is no longer under active development > with the last release in 2012, and it does not allow for native windows > builds using native tools that are used by a majority of consumers. > Maintaining two build systems for a project incurs a lot of overhead. Every > change that touches the build system needs to be done twice, in two > completely different ways. We need twice as many CI jobs to verify that all > of the builds are working, whereas with a single cmake build environment we > could likely use a single CI build job per platform that does everything > using the docker image on linux and appveyor on windows. > h1. Proposal > We should officially deprecate autoconf in favor of cmake, and continue (more > aggressively) the effort to make the cmake build environment as functional as > the autoconf build environment. During this transition, folks will be > required to make changes to both build systems (which are proven out mostly > through the Travis CI build jobs; only CMake is used on AppVeyor). > h1. Acceptance Criteria > # autoconf build environment is removed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (THRIFT-3717) Compact protocol will not work on android c_glib
Gonzalo Aguilar created THRIFT-3717: --- Summary: Compact protocol will not work on android c_glib Key: THRIFT-3717 URL: https://issues.apache.org/jira/browse/THRIFT-3717 Project: Thrift Issue Type: Bug Components: C glib - Library Affects Versions: 0.9.3 Reporter: Gonzalo Aguilar Fix For: 0.10.0 The compact protocol is not building on android. src/thrift/c_glib/protocol/thrift_compact_protocol.c:35:3: error: #error "Unable to determine the behavior of a signed right shift" There should be some directives or configure tests that are not well built for android. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-3369: Attachment: (was: feature-thrift-3369-tls-impl.patch.bz2) > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.10.0, 1.0 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (THRIFT-3706) There's no support for Multiplexed protocol on c_glib library
Gonzalo Aguilar created THRIFT-3706: --- Summary: There's no support for Multiplexed protocol on c_glib library Key: THRIFT-3706 URL: https://issues.apache.org/jira/browse/THRIFT-3706 Project: Thrift Issue Type: Improvement Components: C glib - Library Affects Versions: 0.9.3 Reporter: Gonzalo Aguilar Assignee: Gonzalo Aguilar Fix For: 0.10.0 There's no multiplexed protocol. I will implement the same way it's done in Java an C++ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3370) errno extern variable redefined. Not compiling in Android
[ https://issues.apache.org/jira/browse/THRIFT-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948896#comment-14948896 ] Gonzalo Aguilar commented on THRIFT-3370: - Hi I have already fixed and tested on x86_64, i386 and android and it seems it's okay. I will submit a patch. Best regards, > errno extern variable redefined. Not compiling in Android > - > > Key: THRIFT-3370 > URL: https://issues.apache.org/jira/browse/THRIFT-3370 > Project: Thrift > Issue Type: Bug > Components: C glib - Library >Affects Versions: 0.9.3 >Reporter: Gonzalo Aguilar > Labels: build, c, easyfix > > It seems that the definition of errno we are using on the c_glib transport is > not 100% correct. While it's ok for ISO C99 compilers it fails under Android. > My opinion is that Android is behaving incorrectly here but I cannot be sure > until I check with you. > In the thrift_socket.c an thrift_server_socket.c implementations there's a > errno variable declared. > /* for errors coming from socket() and connect() */ > extern int errno; > This variable is redefined in the ndk of the in the file > arch-arm/usr/include/errno.h > I don't know why. > /* a macro expanding to the errno l-value */ > #define errno (*__errno()) > So the compilation fails because redefined. > Commenting out the extern definition on these files it compiles, it was > tested and it works. But I don't know how this can work since the definition > of errno on the files change from int to pointer. > Can someone comment this please? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (THRIFT-3370) errno extern variable redefined. Not compiling in Android
Gonzalo Aguilar created THRIFT-3370: --- Summary: errno extern variable redefined. Not compiling in Android Key: THRIFT-3370 URL: https://issues.apache.org/jira/browse/THRIFT-3370 Project: Thrift Issue Type: Bug Components: C glib - Library Affects Versions: 0.9.3 Reporter: Gonzalo Aguilar It seems that the definition of errno we are using on the c_glib transport is not 100% correct. While it's ok for ISO C99 compilers it fails under Android. My opinion is that Android is behaving incorrectly here but I cannot be sure until I check with you. In the thrift_socket.c an thrift_server_socket.c implementations there's a errno variable declared. /* for errors coming from socket() and connect() */ extern int errno; This variable is redefined in the ndk of the in the file arch-arm/usr/include/errno.h I don't know why. /* a macro expanding to the errno l-value */ #define errno (*__errno()) So the compilation fails because redefined. Commenting out the extern definition on these files it compiles, it was tested and it works. But I don't know how this can work since the definition of errno on the files change from int to pointer. Can someone comment this please? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-1016) using GSocket in c_glib library
[ https://issues.apache.org/jira/browse/THRIFT-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947120#comment-14947120 ] Gonzalo Aguilar commented on THRIFT-1016: - I don't know what's the effort of this but's not small. I opened a new bug THRIFT-3369 that can or cannot benefit of this development. But I think then I will have to switch to something like: GTlsClientConnection — TLS client-side connection GTlsServerConnection — TLS server-side connection Please comment when someone will take this task. > using GSocket in c_glib library > --- > > Key: THRIFT-1016 > URL: https://issues.apache.org/jira/browse/THRIFT-1016 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Reporter: david han >Priority: Minor > > I looking the source of the c_glib library implement, It using the posix > socket to implement the ThriftSocket. > but there already realize the it as GSocket in GIO (a part in GLib) module, > and the GSocket is crossing OS platform. > so we can use it as the basic socket in ThriftSocket. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-3369: Fix Version/s: 1.0 > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.9.4, 1.0 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-3369: Attachment: feature-thrift-3369-tls-impl.patch.bz2 Server part is still under work. Tests are no complete either. > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.9.4, 1.0 > > Attachments: feature-thrift-3369-tls-impl.patch.bz2 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-3369: Attachment: (was: feature-thrift-3369-tls-impl.patch.bz2) > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.9.4 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-3369: Affects Version/s: 1.0 > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3, 1.0 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.9.4 > > Attachments: feature-thrift-3369-tls-impl.patch.bz2 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3369) Implement SSL/TLS support on C with c_glib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-3369: Summary: Implement SSL/TLS support on C with c_glib (was: Implement SSL/TLS support on C with g_lib) > Implement SSL/TLS support on C with c_glib > -- > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.9.4 > > Attachments: feature-thrift-3369-tls-impl.patch.bz2 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3369) Implement SSL/TLS support on C with g_lib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946990#comment-14946990 ] Gonzalo Aguilar commented on THRIFT-3369: - I forgot to say that's required to do this on init: thrift_ssl_socket_initialize_openssl(); and thrift_ssl_socket_finalize_openssl(); when system finished using ssl. I plan to manage this also inside the library but currently is not there. Also SSLContext management is a little bit spartan. I will do it better. My client does something like this to negotiate the connection: manager->socket = thrift_ssl_socket_new_with_host(cipher, host, port, error); > Implement SSL/TLS support on C with g_lib > - > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.9.4 > > Attachments: feature-thrift-3369-tls-impl.patch.bz2 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3369) Implement SSL/TLS support on C with g_lib
[ https://issues.apache.org/jira/browse/THRIFT-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo Aguilar updated THRIFT-3369: Attachment: feature-thrift-3369-tls-impl.patch.bz2 The current implementation, work in progress but already working. Missing, authorization manager, and some other features I will add. > Implement SSL/TLS support on C with g_lib > - > > Key: THRIFT-3369 > URL: https://issues.apache.org/jira/browse/THRIFT-3369 > Project: Thrift > Issue Type: Improvement > Components: C glib - Library >Affects Versions: 0.9.1, 0.9.2, 0.9.3 >Reporter: Gonzalo Aguilar > Labels: features, patch > Fix For: 0.9.4 > > Attachments: feature-thrift-3369-tls-impl.patch.bz2 > > > Implement SSL/TLS based on plain openssl instead of going through the way > defined in THRIFT-1016. > This help us to maintain a reference implementation and later switch over GIO > or whatever is defined. But also does not add any other dependencies to the > project. So bare minimum installation for supporting SSL/TLS is there and > aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (THRIFT-3369) Implement SSL/TLS support on C with g_lib
Gonzalo Aguilar created THRIFT-3369: --- Summary: Implement SSL/TLS support on C with g_lib Key: THRIFT-3369 URL: https://issues.apache.org/jira/browse/THRIFT-3369 Project: Thrift Issue Type: Improvement Components: C glib - Library Affects Versions: 0.9.3, 0.9.2, 0.9.1 Reporter: Gonzalo Aguilar Fix For: 0.9.4 Implement SSL/TLS based on plain openssl instead of going through the way defined in THRIFT-1016. This help us to maintain a reference implementation and later switch over GIO or whatever is defined. But also does not add any other dependencies to the project. So bare minimum installation for supporting SSL/TLS is there and aligned with CPP counterpart. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-1530) thrift c_glib code has no support for timeouts
[ https://issues.apache.org/jira/browse/THRIFT-1530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620830#comment-14620830 ] Gonzalo Aguilar commented on THRIFT-1530: - Hi, I don't understand this part of the patch: -ret = recv (socket->sd, buf+got, len-got, 0); +ret = recv (socket->sd, buf, len, 0); Because for me your patch will not work if you apply that then data will be overwritten in the buffer > thrift c_glib code has no support for timeouts > -- > > Key: THRIFT-1530 > URL: https://issues.apache.org/jira/browse/THRIFT-1530 > Project: Thrift > Issue Type: Bug > Components: C glib - Compiler, C glib - Library >Affects Versions: 0.8, 0.9 >Reporter: Mina Naguib > Labels: c, c_glib, glib, out, thrift, time, timeout > Attachments: thrift-c-glib-with-timeout.patch > > > There's no mention of "timeout" anywhere in the c_glib compiler's code, nor > (obviously) in the generated gen-c_glib code -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2284) java.lang.OutOfMemoryError: Java heap space
[
https://issues.apache.org/jira/browse/THRIFT-2284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14557219#comment-14557219
]
Gonzalo Aguilar commented on THRIFT-2284:
-
I have the same problem. I start the server do a request. And do nothing. After
few hours:
23:01:23,695 ERROR [org.apache.thrift.server.TThreadedSelectorServer]
(Thread-90) run() exiting due to uncaught error: java.lang.OutOfMemoryError:
Java heap space
at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
[rt.jar:1.7.0_80]
at java.nio.ByteBuffer.allocate(ByteBuffer.java:331) [rt.jar:1.7.0_80]
at
org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.read(AbstractNonblockingServer.java:371)
[libthrift-0.9.2.jar:0.9.2]
at
org.apache.thrift.server.AbstractNonblockingServer$AbstractSelectThread.handleRead(AbstractNonblockingServer.java:203)
[libthrift-0.9.2.jar:0.9.2]
at
org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:590)
[libthrift-0.9.2.jar:0.9.2]
at
org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:545)
[libthrift-0.9.2.jar:0.9.2]
23:01:23,804 INFO [com.seglan.tvm.thrift.mc.mobile.ThriftDaemon] (Thread-88)
Thrift server is finished
And this is the offending code:
TNonblockingServerSocket serverTransport = null;
InetSocketAddress address = new
InetSocketAddress(serverURI.getHost(), serverURI.getPort());
log.info("Running " + address.getHostString() + " port " +
address.getPort());
try {
serverTransport = new TNonblockingServerSocket(address);
log.info("Server is created as asynchronous server non
blocking");
} catch (TTransportException e) {
log.warn("Cannot create server: " + e.getMessage());
return;
}
/*
* TThreadedSelectorServer allows you to have multiple threads
for network I/O. It maintains 2 thread pools,
* one for handling network I/O, and one for handling request
processing.
* TThreadedSelectorServer performs better than THsHaServer
when the network io is the bottleneck.
*/
TThreadedSelectorServer.Args serverArgs = new
TThreadedSelectorServer.Args(serverTransport);
/*
* TFramedTransport is a buffered TTransport that ensures a
fully read message every time
* by preceding messages with a 4-byte frame size.
*/
serverArgs.transportFactory(new TFramedTransport.Factory());
/*
* We want to transcode everything to binary format for
performance reasons
*/
serverArgs.protocolFactory(new TBinaryProtocol.Factory());
/*
* This is the processor that will call handler
*/
serverArgs.processor(this.getServerProcessor(this.getServerHandler()));
/*
* We want to receive messages with 4 threads
*/
serverArgs.selectorThreads(4);
/*
* There will be 8 threads for serving messages
*/
serverArgs.workerThreads(8);
/*
* Fix heap problem
* https://issues.apache.org/jira/browse/THRIFT-2284
*/
serverArgs.maxReadBufferBytes = Integer.MAX_VALUE;
server = new TThreadedSelectorServer(serverArgs);
log.info("Server is running...");
server.serve();
> java.lang.OutOfMemoryError: Java heap space
> ---
>
> Key: THRIFT-2284
> URL: https://issues.apache.org/jira/browse/THRIFT-2284
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
>Affects Versions: 0.7, 0.9.1
> Environment: Thrift Server start up by Resin Server at Linux system.
>Reporter: hiyoucai
>Priority: Critical
> Fix For: 0.9.2
>
>
> 【1】The first version application Environment:
> {code}
> # cat /proc/version
> Linux version 3.5.0-23-generic (buildd@komainu) (gcc version 4.6.3
> (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #35~precise1-Ubuntu SMP Fri Jan 25 17:13:26
> UTC 2013
> # java -version
> java version "1.6.0_45"
> Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
> Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)
> #thrift version is 0.7
> {code}
> Java Server code like following:use TNonblockingServer type server.
> {code}
> public void start() {
> try {
> logger.info("T
