[jira] [Commented] (THRIFT-4031) Go plugin generates invalid code for lists of typedef'ed built-in types
[
https://issues.apache.org/jira/browse/THRIFT-4031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876901#comment-15876901
]
Benoit Sigoure commented on THRIFT-4031:
For the example {{.thrift}} file that I provided, the code compile fines before
this commit, but breaks after that commit. I imagine the commit intended to
fix something but broke something else in the process.
> Go plugin generates invalid code for lists of typedef'ed built-in types
> ---
>
> Key: THRIFT-4031
> URL: https://issues.apache.org/jira/browse/THRIFT-4031
> Project: Thrift
> Issue Type: Bug
> Components: Go - Compiler
>Affects Versions: 0.10.0
> Environment: Thrift version 0.10.0
> go version go1.7.4 linux/386
>Reporter: Benoit Sigoure
>Priority: Critical
>
> Reproduction:
> {code}
> mkdir /tmp/bug
> cd /tmp/bug
> cat >test.thrift < typedef i32 foo
> struct s {
> 1:list a
> }
> EOF
> mkdir _build
> thrift -out _build --gen go:package=pkg -r test.thrift
> {code}
> Then try to compile the resulting {{go build _build/pkg/test.go}} and you'll
> get:
> {code}
> _build/pkg/test.go:81: cannot use _elem0 (type int32) as type Foo in append
> {code}
> Here's the generated code with line numbers and a couple comments I added:
> {code}
> 67 func (p *S) ReadField1(iprot thrift.TProtocol) error {
> 68 _, size, err := iprot.ReadListBegin()
> 69 if err != nil {
> 70 return thrift.PrependError("error reading list begin: ", err)
> 71 }
> 72 tSlice := make([]Foo, 0, size) // The slice contain Foo values
> 73 p.A = tSlice
> 74 for i := 0; i < size; i ++ {
> 75 var _elem0 int32
> 76 if v, err := iprot.ReadI32(); err != nil {
> 77 return thrift.PrependError("error reading field 0: ", err)
> 78 } else {
> 79 _elem0 = v
> 80 }
> 81 p.A = append(p.A, _elem0) // Here the code should do append(p.A,
> Foo(_elem0))
> 82 }
> 83 if err := iprot.ReadListEnd(); err != nil {
> 84 return thrift.PrependError("error reading list end: ", err)
> 85 }
> 86 return nil
> 87 }
> {code}
> This was working fine with 0.9.3 so this is a regression in 0.10.0. With
> 0.9.3 the slice {{tSlice}} is a {{[]int32}}, as opposed to a {{[]Foo}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (THRIFT-4031) Go plugin generates invalid code for lists of typedef'ed built-in types
Benoit Sigoure created THRIFT-4031:
--
Summary: Go plugin generates invalid code for lists of typedef'ed
built-in types
Key: THRIFT-4031
URL: https://issues.apache.org/jira/browse/THRIFT-4031
Project: Thrift
Issue Type: Bug
Components: Go - Compiler
Affects Versions: 0.10.0
Environment: Thrift version 0.10.0
go version go1.7.4 linux/386
Reporter: Benoit Sigoure
Priority: Critical
Reproduction:
{code}
mkdir /tmp/bug
cd /tmp/bug
cat >test.thrift < a
}
EOF
mkdir _build
thrift -out _build --gen go:package=pkg -r test.thrift
{code}
Then try to compile the resulting {{go build _build/pkg/test.go}} and you'll
get:
{code}
_build/pkg/test.go:81: cannot use _elem0 (type int32) as type Foo in append
{code}
Here's the generated code with line numbers and a couple comments I added:
{code}
67 func (p *S) ReadField1(iprot thrift.TProtocol) error {
68 _, size, err := iprot.ReadListBegin()
69 if err != nil {
70 return thrift.PrependError("error reading list begin: ", err)
71 }
72 tSlice := make([]Foo, 0, size) // The slice contain Foo values
73 p.A = tSlice
74 for i := 0; i < size; i ++ {
75 var _elem0 int32
76 if v, err := iprot.ReadI32(); err != nil {
77 return thrift.PrependError("error reading field 0: ", err)
78 } else {
79 _elem0 = v
80 }
81 p.A = append(p.A, _elem0) // Here the code should do append(p.A,
Foo(_elem0))
82 }
83 if err := iprot.ReadListEnd(); err != nil {
84 return thrift.PrependError("error reading list end: ", err)
85 }
86 return nil
87 }
{code}
This was working fine with 0.9.3 so this is a regression in 0.10.0. With 0.9.3
the slice {{tSlice}} is a {{[]int32}}, as opposed to a {{[]Foo}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-4027) Compilation error with boost 1.63.0
[
https://issues.apache.org/jira/browse/THRIFT-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Sigoure updated THRIFT-4027:
---
Attachment: 1005-Workaround-for-Boost-1.63.0.patch
Patch to address the issue.
> Compilation error with boost 1.63.0
> ---
>
> Key: THRIFT-4027
> URL: https://issues.apache.org/jira/browse/THRIFT-4027
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.10.0
> Environment: Boost 1.63.0
>Reporter: Benoit Sigoure
> Attachments: 1005-Workaround-for-Boost-1.63.0.patch
>
>
> It's kinda stupid but {{Boost.Test}} introduced a global variable called
> {{VERSION}} in one of their inline headers ([in this
> commit|https://github.com/boostorg/test/commit/86bcffea6dfb2513142c42721bf2af3e80ea068d])
> and this causes the build of Thrift 0.10.0 to fail with:
> {code}
> make[1]: Entering directory
> `/bld/thrift/Artools-rpmbuild/thrift-0.10.0/compiler/cpp/test'
> g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src/thrift
> -I../../../lib/c_glib/src/thrift -I/usr/include -I../../../compiler/cpp/src
> -I../../../lib/cpp/src -I../../../lib/cpp/src -Wall -Wextra -pedantic -O2 -g
> -pipe -Wall -Wp,-D
> _FORTIFY_SOURCE=2 -fexceptions -fstack-protector -fno-var-tracking
> -fno-var-tracking-assignments --param=ssp-buffer-size=4 -m32 -march=i686
> -mtune=atom -fasynchronous-unwind-tables -std=c++11 -c -o
> plugin/conversion_test.o plugin/convers
> ion_test.cc
> In file included from /usr/include/boost/test/included/unit_test.hpp:32:0,
> from plugin/conversion_test.cc:28:
> /usr/include/boost/test/impl/unit_test_parameters.ipp:102:12: error: expected
> unqualified-id before string constant
> std::string VERSION = "version";
> ^
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-4027) Compilation error with boost 1.63.0
Benoit Sigoure created THRIFT-4027:
--
Summary: Compilation error with boost 1.63.0
Key: THRIFT-4027
URL: https://issues.apache.org/jira/browse/THRIFT-4027
Project: Thrift
Issue Type: Bug
Components: C++ - Compiler
Affects Versions: 0.10.0
Environment: Boost 1.63.0
Reporter: Benoit Sigoure
It's kinda stupid but {{Boost.Test}} introduced a global variable called
{{VERSION}} in one of their inline headers ([in this
commit|https://github.com/boostorg/test/commit/86bcffea6dfb2513142c42721bf2af3e80ea068d])
and this causes the build of Thrift 0.10.0 to fail with:
{code}
make[1]: Entering directory
`/bld/thrift/Artools-rpmbuild/thrift-0.10.0/compiler/cpp/test'
g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../lib/cpp/src/thrift
-I../../../lib/c_glib/src/thrift -I/usr/include -I../../../compiler/cpp/src
-I../../../lib/cpp/src -I../../../lib/cpp/src -Wall -Wextra -pedantic -O2 -g
-pipe -Wall -Wp,-D
_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -fno-var-tracking
-fno-var-tracking-assignments --param=ssp-buffer-size=4 -m32 -march=i686
-mtune=atom -fasynchronous-unwind-tables -std=c++11 -c -o
plugin/conversion_test.o plugin/convers
ion_test.cc
In file included from /usr/include/boost/test/included/unit_test.hpp:32:0,
from plugin/conversion_test.cc:28:
/usr/include/boost/test/impl/unit_test_parameters.ipp:102:12: error: expected
unqualified-id before string constant
std::string VERSION = "version";
^
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-4026) TSSLSocket doesn't work with Python 2.7
[
https://issues.apache.org/jira/browse/THRIFT-4026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15817193#comment-15817193
]
Benoit Sigoure commented on THRIFT-4026:
Also after fixing this, you'll have to fix {{test_client_cert}}
{code}
==
ERROR: test_client_cert (__main__.TSSLSocketTest)
--
Traceback (most recent call last):
File "test/test_sslsocket.py", line 242, in test_client_cert
certfile=SERVER_CERT, ca_certs=CLIENT_CERT)
File "test/test_sslsocket.py", line 115, in _server_socket
return TSSLServerSocket(port=0, **kwargs)
File
"/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
line 349, in __init__
raise ValueError('Need ipaddress and backports.ssl_match_hostname '
ValueError: Need ipaddress and backports.ssl_match_hostname module to verify
client certificate
--
{code}
> TSSLSocket doesn't work with Python 2.7
> ---
>
> Key: THRIFT-4026
> URL: https://issues.apache.org/jira/browse/THRIFT-4026
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
>Affects Versions: 0.10.0
> Environment: Python 2.7.5
>Reporter: Benoit Sigoure
>Priority: Critical
>
> As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a
> {{TypeError}} in {{open()}}:
> {code}
> File
> "/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
> line 293, in open
> self._validate_callback(self.peercert, self._server_hostname)
> TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
> {code}
> Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument,
> which cannot possibly be compatible with the signature of
> [{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
> (which was added in Python 3.2).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-4026) TSSLSocket doesn't work with Python 2.7
Benoit Sigoure created THRIFT-4026:
--
Summary: TSSLSocket doesn't work with Python 2.7
Key: THRIFT-4026
URL: https://issues.apache.org/jira/browse/THRIFT-4026
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.10.0
Environment: Python 2.7.5
Reporter: Benoit Sigoure
Priority: Critical
As a result of a change made in THRIFT-3917, {{TSSLSocket}} now fails with a
{{TypeError}} in {{open()}}:
{code}
File
"/bld/thrift/Artools-rpmbuild/thrift-0.10.0/lib/py/build/lib.linux-i686-2.7/thrift/transport/TSSLSocket.py",
line 293, in open
self._validate_callback(self.peercert, self._server_hostname)
TypeError: legacy_validate_callback() takes exactly 3 arguments (2 given)
{code}
Indeed, {{legacy_validate_callback()}} takes an extra {{self}} argument, which
cannot possibly be compatible with the signature of
[{{ssl.match_hostname()}}|https://docs.python.org/3/library/ssl.html#ssl.match_hostname]
(which was added in Python 3.2).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-2516) TProcessPoolServer.py can get stuck forever trying to acquire a semaphore
Benoit Sigoure created THRIFT-2516:
--
Summary: TProcessPoolServer.py can get stuck forever trying to
acquire a semaphore
Key: THRIFT-2516
URL: https://issues.apache.org/jira/browse/THRIFT-2516
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
In our build environment we observed that {{RunClientServer.py}} was hanging
forever, because the {{TestServer.py}} was hung trying to acquire a semaphore.
Process list (from {{ps afux}}:
{code}
arastra 1144 0.0 0.0 10444 3820 pts/19 SN+ May05 0:00 |
| | |
\_ python ./RunClientServer.py
arastra 3962 0.0 0.0 11824 5076 pts/19 SN+ May05 0:00 |
| | |
\_ /usr/bin/python ./TestServer.py
--genpydir=gen-py-newstyleslots --proto=compact --port=9090 --ssl
TProcessPoolServer
arastra 3974 0.0 0.0 0 0 pts/19 ZN+ May05 0:00 |
| | |
| \_ [python] defunct
arastra 3975 0.0 0.0 0 0 pts/19 ZN+ May05 0:00 |
| | |
| \_ [python] defunct
arastra 3976 0.0 0.0 0 0 pts/19 ZN+ May05 0:00 |
| | |
| \_ [python] defunct
arastra 3977 0.0 0.0 0 0 pts/19 ZN+ May05 0:00 |
| | |
| \_ [python] defunct
arastra 3978 0.0 0.0 0 0 pts/19 ZN+ May05 0:00 |
| | |
| \_ [python] defunct
arastra 3981 0.0 0.0 11772 5056 pts/19 SN+ May05 0:00 |
| | |
\_ /usr/bin/python ./TestClient.py
--genpydir=gen-py-newstyleslots --proto=compact --port=9090 --ssl
{code}
Stack trace of the server (from gdb):
{code}
(gdb) attach 3962
Attaching to process 3962
[...]
(gdb) bt
[34/2139]
#0 0xf77dc430 in __kernel_vsyscall ()
#1 0xf7612765 in sem_wait@@GLIBC_2.1 () from /lib/libpthread.so.0
#2 0xf723f4ce in semlock_acquire (self=0x8d39050, args=unknown at remote
0xfe00, kwds=unknown at remote 0xfe00) at
/usr/src/debug/Python-2.7/Modules/_multiprocessing/semaphore.c:310
#3 0xf768f798 in PyCFunction_Call (func=built-in method acquire of
_multiprocessing.SemLock object at remote 0x8ef9ba0, arg=(), kw=0x0) at
/usr/src/debug/Python-2.7/Objects/methodobject.c:85
#4 0xf76f2147 in call_function (f=Frame 0x8f3a714, for file
/usr/lib/python2.7/multiprocessing/synchronize.py, line 241, in notify
(self=Condition(_wait_semaphore=Semaphore(release=built-in method release of
_multiprocessing.SemLock o
bject at remote 0x8ef9c20, _semlock=_multiprocessing.SemLock at remote
0x8ef9c20, acquire=built-in method acquire of _multiprocessing.SemLock object
at remote 0x8ef9c20) at remote 0x8ef9c6c,
_sleeping_count=Semaphore(release=built
-in method release of _multiprocessing.SemLock object at remote 0x8ef9b20,
_semlock=_multiprocessing.SemLock at remote 0x8ef9b20, acquire=built-in
method acquire of _multiprocessing.SemLock object at remote 0x8ef9b20) at
remote 0x8ef
9b6c, release=built-in method release of _multiprocessing.SemLock object at
remote 0x8ef9ae0, acquire=built-in method acquire of _multiprocessing.SemLock
object at remote 0x8ef9ae0, _lock=RLock(release=built-in method release of _m
ultiprocessing.SemLock object at remote 0x8ef9ae0,
_semlock=_multiprocessing.SemLock at remote 0x8ef9ae0...(truncated),
throwflag=0) at /usr/src/debug/Python-2.7/Python/ceval.c:4071
#5 PyEval_EvalFrameEx (f=Frame 0x8f3a714, for file
/usr/lib/python2.7/multiprocessing/synchronize.py, line 241, in notify
(self=Condition(_wait_semaphore=Semaphore(release=built-in method release of
_multiprocessing.SemLock object at
remote 0x8ef9c20, _semlock=_multiprocessing.SemLock at remote 0x8ef9c20,
acquire=built-in method acquire of _multiprocessing.SemLock object at remote
0x8ef9c20) at remote 0x8ef9c6c, _sleeping_count=Semaphore(release=built-in
metho
d release of _multiprocessing.SemLock object
[jira] [Commented] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
[
https://issues.apache.org/jira/browse/THRIFT-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967772#comment-13967772
]
Benoit Sigoure commented on THRIFT-2463:
I may have a patch, I added some debugging and I don't see us tripping on the
{{SIGALRM}} (event though it still looks fishy to me). There are some
interlock issues in {{RunClientServer.py}} that I'm fixing to see if that
indeed stops the flakiness of my CI system.
test/py/RunClientServer.py fails sometimes
--
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py,
line 149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
[
https://issues.apache.org/jira/browse/THRIFT-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967773#comment-13967773
]
Benoit Sigoure commented on THRIFT-2463:
Maybe the problem is completely different than what I thought. I just saw this:
{code}
Test run #2: (includes gen-py-default) Server=TSimpleServer, Proto=accel,
zlib=False, SSL=True
Testing server TSimpleServer: /usr/bin/python ./TestServer.py
--genpydir=gen-py-default --proto=accel --port=9090 --ssl TSimpleServer
Testing client: /usr/bin/python ./TestClient.py --genpydir=gen-py-default
--proto=accel --port=9090 --ssl
ERROR:root:'NoneType' object has no attribute 'read'
Traceback (most recent call last):
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/server/TServer.py, line
84, in serve
self.processor.process(iprot, oprot)
File gen-py-default/ThriftTest/ThriftTest.py, line 995, in process
(name, type, seqid) = iprot.readMessageBegin()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/protocol/TBinaryProtocol.py,
line 126, in readMessageBegin
sz = self.readI32()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/protocol/TBinaryProtocol.py,
line 206, in readI32
buff = self.trans.readAll(4)
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py, line
58, in readAll
chunk = self.read(sz - have)
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py, line
159, in read
self.__rbuf = StringIO(self.__trans.read(max(sz, self.__rbuf_size)))
AttributeError: 'NoneType' object has no attribute 'read'
Traceback (most recent call last):
File ./TestServer.py, line 243, in module
server.serve()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/server/TServer.py, line
90, in serve
itrans.close()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py, line
152, in close
return self.__trans.close()
AttributeError: 'NoneType' object has no attribute 'close'
{code}
I haven't modified anything that could be causing this. Weird.
test/py/RunClientServer.py fails sometimes
--
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py,
line 149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
[
https://issues.apache.org/jira/browse/THRIFT-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967778#comment-13967778
]
Benoit Sigoure commented on THRIFT-2463:
Ah OK, while trying to fix this bug, I tripped on another bug, namely that
opening and closing a connection to a thrift server that uses SSL without
actually performing an SSL handshake triggers the above {{AttributeError}} due
to lack of error checking in {{TSimpleServer}}.
test/py/RunClientServer.py fails sometimes
--
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py,
line 149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (THRIFT-2466) Improper error handling for SSL/TLS connections that don't complete a handshake
Benoit Sigoure created THRIFT-2466:
--
Summary: Improper error handling for SSL/TLS connections that
don't complete a handshake
Key: THRIFT-2466
URL: https://issues.apache.org/jira/browse/THRIFT-2466
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
The code in {{TSSLServerSocket.accept()}} silently drops all {{SSLError}} and
returns {{None}} instead, but none of the {{TServer}} implementations handle
this case properly, which cause them to pass {{None}} around a bunch, which
eventually cause weird {{AttributeError}} exceptions.
This bug is easy to reproduce: just open a socket to a Python Thrift server
that uses SSL/TLS and close the connection right away.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
[
https://issues.apache.org/jira/browse/THRIFT-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13968021#comment-13968021
]
Benoit Sigoure commented on THRIFT-2463:
I think my fix works, I filed a separate issue for the lack of error checking
in the {{TServer}} implementations (it's not just {{TSimpleServer}}):
THRIFT-2466
test/py/RunClientServer.py fails sometimes
--
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py,
line 149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2466) Improper error handling for SSL/TLS connections that don't complete a handshake
[
https://issues.apache.org/jira/browse/THRIFT-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Sigoure updated THRIFT-2466:
---
Patch Info: Patch Available
Improper error handling for SSL/TLS connections that don't complete a
handshake
---
Key: THRIFT-2466
URL: https://issues.apache.org/jira/browse/THRIFT-2466
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
Attachments:
THRIFT-2466-Silently-ignore-clients-that-couldn-t-be-created.patch
The code in {{TSSLServerSocket.accept()}} silently drops all {{SSLError}} and
returns {{None}} instead, but none of the {{TServer}} implementations handle
this case properly, which cause them to pass {{None}} around a bunch, which
eventually cause weird {{AttributeError}} exceptions.
This bug is easy to reproduce: just open a socket to a Python Thrift server
that uses SSL/TLS and close the connection right away.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2466) Improper error handling for SSL/TLS connections that don't complete a handshake
[
https://issues.apache.org/jira/browse/THRIFT-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Sigoure updated THRIFT-2466:
---
Attachment:
THRIFT-2466-Silently-ignore-clients-that-couldn-t-be-created.patch
Patch to fix the issue.
Improper error handling for SSL/TLS connections that don't complete a
handshake
---
Key: THRIFT-2466
URL: https://issues.apache.org/jira/browse/THRIFT-2466
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
Attachments:
THRIFT-2466-Silently-ignore-clients-that-couldn-t-be-created.patch
The code in {{TSSLServerSocket.accept()}} silently drops all {{SSLError}} and
returns {{None}} instead, but none of the {{TServer}} implementations handle
this case properly, which cause them to pass {{None}} around a bunch, which
eventually cause weird {{AttributeError}} exceptions.
This bug is easy to reproduce: just open a socket to a Python Thrift server
that uses SSL/TLS and close the connection right away.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
[
https://issues.apache.org/jira/browse/THRIFT-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Sigoure updated THRIFT-2463:
---
Patch Info: Patch Available
test/py/RunClientServer.py fails sometimes
--
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
Attachments:
THRIFT-2463-Fix-a-timing-bug-by-properly-waiting-for-the-server.patch
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py,
line 149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
[
https://issues.apache.org/jira/browse/THRIFT-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Sigoure updated THRIFT-2463:
---
Attachment:
THRIFT-2463-Fix-a-timing-bug-by-properly-waiting-for-the-server.patch
Patch that I believe fixes the issue. Need the patch of THRIFT-2466 first,
otherwise this patch will cause the test to run into that bug.
test/py/RunClientServer.py fails sometimes
--
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
Attachments:
THRIFT-2463-Fix-a-timing-bug-by-properly-waiting-for-the-server.patch
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py,
line 149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
Benoit Sigoure created THRIFT-2463:
--
Summary: test/py/RunClientServer.py fails sometimes
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py, line
149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2463) test/py/RunClientServer.py fails sometimes
[
https://issues.apache.org/jira/browse/THRIFT-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967739#comment-13967739
]
Benoit Sigoure commented on THRIFT-2463:
I'm wondering whether this could be caused by a spurious SIGALRM timeout,
because {{TestServer.py}} arms the alarm for only 2 seconds and it's possible
that if the machine was under heavy load, it would take more than 2 seconds for
{{TestServer.py}} to start accepting connections.
Excerpt from the code:
{code}
elif server_type == TProcessPoolServer:
import signal
from thrift.server import TProcessPoolServer
server = TProcessPoolServer.TProcessPoolServer(processor, transport,
tfactory, pfactory)
server.setNumWorkers(5)
def set_alarm():
def clean_shutdown(signum, frame):
print SIGALRM: Shutting down server
for worker in server.workers:
if options.verbose 0:
print 'Terminating worker: %s' % worker
worker.terminate()
if options.verbose 0:
print 'Requesting server to stop()'
try:
server.stop()
except:
pass
signal.signal(signal.SIGALRM, clean_shutdown)
signal.alarm(2)
set_alarm()
{code}
I'm sure why the alarm is even armed here, and why so aggressively. This was
added in THRIFT-1094 by [~bryanduxbury].
test/py/RunClientServer.py fails sometimes
--
Key: THRIFT-2463
URL: https://issues.apache.org/jira/browse/THRIFT-2463
Project: Thrift
Issue Type: Bug
Components: Python - Library
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
This test is flaky in our CI system and the flakiness is also visible on
Jenkins (see examples of failed builds
[here|http://mail-archives.apache.org/mod_mbox/thrift-dev/201309.mbox/%3C1012268498.737.1378727603714.JavaMail.hudson@aegis%3E]
and [here|https://www.mail-archive.com/dev@thrift.apache.org/msg10124.html]).
All the test cases of {{AcceleratedBinaryTest}} fail with this signature:
{code}
==
ERROR: testByte (__main__.AcceleratedBinaryTest)
--
Traceback (most recent call last):
File ./TestClient.py, line 85, in setUp
self.transport.open()
File
./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TTransport.py,
line 149, in open
return self.__trans.open()
File ./../../lib/py/build/lib.linux-i686-2.7/thrift/transport/TSocket.py,
line 99, in open
message=message)
TTransportException: Could not connect to localhost:9090
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (THRIFT-2431) TFileTransportTest fails with check delta XXX failed
[
https://issues.apache.org/jira/browse/THRIFT-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13967741#comment-13967741
]
Benoit Sigoure commented on THRIFT-2431:
Looks like a timing problem when the machine is under heavy load.
TFileTransportTest fails with check delta XXX failed
Key: THRIFT-2431
URL: https://issues.apache.org/jira/browse/THRIFT-2431
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.1
Environment: Linux 3.4.43
Building the SRPM from Fedora Core 21
Reporter: Benoit Sigoure
Priority: Minor
This test is flaky, I can easily make it fail:
{code}
$ ./TFileTransportTest
Running 5 test cases...
TFileTransportTest.cpp(289): error in test_flush_max_us1: check delta
max_allowed_delta failed [17031 = 15000]
*** 1 failure detected in test suite TFileTransportTest
$ ./TFileTransportTest
Running 5 test cases...
*** No errors detected
$ ./TFileTransportTest
Running 5 test cases...
*** No errors detected
$ ./TFileTransportTest
Running 5 test cases...
TFileTransportTest.cpp(339): fatal error in test_noop_flush: critical check
delta 200 failed [3000242 = 200]
*** 1 failure detected in test suite TFileTransportTest
$ ./TFileTransportTest
Running 5 test cases...
TFileTransportTest.cpp(339): fatal error in test_noop_flush: critical check
delta 200 failed [3000137 = 200]
*** 1 failure detected in test suite TFileTransportTest
{code}
Seems like this has hit a
[couple|http://mail-archives.apache.org/mod_mbox/thrift-dev/201107.mbox/%3C412700474.6601310132626839.JavaMail.hudson@aegis%3E]
[times|http://mail-archives.apache.org/mod_mbox/thrift-dev/201110.mbox/%3C566967061.2611319633097563.JavaMail.hudson@aegis%3E]
in Jenkins already.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (THRIFT-2431) TFileTransportTest fails with check delta XXX failed
Benoit Sigoure created THRIFT-2431:
--
Summary: TFileTransportTest fails with check delta XXX failed
Key: THRIFT-2431
URL: https://issues.apache.org/jira/browse/THRIFT-2431
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.1
Environment: Linux 3.4.43
Building the SRPM from Fedora Core 21
Reporter: Benoit Sigoure
Priority: Minor
This test is flaky, I can easily make it fail:
{code}
$ ./TFileTransportTest
Running 5 test cases...
TFileTransportTest.cpp(289): error in test_flush_max_us1: check delta
max_allowed_delta failed [17031 = 15000]
*** 1 failure detected in test suite TFileTransportTest
$ ./TFileTransportTest
Running 5 test cases...
*** No errors detected
$ ./TFileTransportTest
Running 5 test cases...
*** No errors detected
$ ./TFileTransportTest
Running 5 test cases...
TFileTransportTest.cpp(339): fatal error in test_noop_flush: critical check
delta 200 failed [3000242 = 200]
*** 1 failure detected in test suite TFileTransportTest
$ ./TFileTransportTest
Running 5 test cases...
TFileTransportTest.cpp(339): fatal error in test_noop_flush: critical check
delta 200 failed [3000137 = 200]
*** 1 failure detected in test suite TFileTransportTest
{code}
Seems like this has hit a
[couple|http://mail-archives.apache.org/mod_mbox/thrift-dev/201107.mbox/%3C412700474.6601310132626839.JavaMail.hudson@aegis%3E]
[times|http://mail-archives.apache.org/mod_mbox/thrift-dev/201110.mbox/%3C566967061.2611319633097563.JavaMail.hudson@aegis%3E]
in Jenkins already.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2432) Flaky parallel build
[
https://issues.apache.org/jira/browse/THRIFT-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Sigoure updated THRIFT-2432:
---
Patch Info: Patch Available
Flaky parallel build
Key: THRIFT-2432
URL: https://issues.apache.org/jira/browse/THRIFT-2432
Project: Thrift
Issue Type: Bug
Components: C++ - Compiler
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
Priority: Minor
Attachments: THRIFT-2432.patch
Parallel builds sometime fail with:
{code}
src/thriftl.ll:51:21: fatal error: thrifty.h: No such file or directory
compilation terminated.
make[3]: *** [libparse_a-thriftl.o] Error 1
{code}
This is because the Makefile doesn't require that {{thrifty.cc}} (and its
accompanying header) be generated before {{thriftl.o}} is compiled. This is
normally done via {{BUILT_SOURCES}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (THRIFT-2432) Flaky parallel build
[
https://issues.apache.org/jira/browse/THRIFT-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Sigoure updated THRIFT-2432:
---
Attachment: THRIFT-2432.patch
Patch to fix the issue.
Flaky parallel build
Key: THRIFT-2432
URL: https://issues.apache.org/jira/browse/THRIFT-2432
Project: Thrift
Issue Type: Bug
Components: C++ - Compiler
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
Priority: Minor
Attachments: THRIFT-2432.patch
Parallel builds sometime fail with:
{code}
src/thriftl.ll:51:21: fatal error: thrifty.h: No such file or directory
compilation terminated.
make[3]: *** [libparse_a-thriftl.o] Error 1
{code}
This is because the Makefile doesn't require that {{thrifty.cc}} (and its
accompanying header) be generated before {{thriftl.o}} is compiled. This is
normally done via {{BUILT_SOURCES}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (THRIFT-2432) Flaky parallel build
Benoit Sigoure created THRIFT-2432:
--
Summary: Flaky parallel build
Key: THRIFT-2432
URL: https://issues.apache.org/jira/browse/THRIFT-2432
Project: Thrift
Issue Type: Bug
Components: C++ - Compiler
Affects Versions: 0.9.1
Reporter: Benoit Sigoure
Priority: Minor
Attachments: THRIFT-2432.patch
Parallel builds sometime fail with:
{code}
src/thriftl.ll:51:21: fatal error: thrifty.h: No such file or directory
compilation terminated.
make[3]: *** [libparse_a-thriftl.o] Error 1
{code}
This is because the Makefile doesn't require that {{thrifty.cc}} (and its
accompanying header) be generated before {{thriftl.o}} is compiled. This is
normally done via {{BUILT_SOURCES}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
