[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...

2017-08-12 Thread Johnny-Liao 
Github user Johnny-Liao commented on the issue:

https://github.com/apache/thrift/pull/1313
  
My linux kernel is 3.10.0 when this bug occured. And I'm pretty sure that 
still trouble many people who dependence Thrift to implements theirs server 
program. Netty uses this approach to mask the underlying problem and why can't 
we.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] thrift issue #1313: THRIFT-4251 Fix JDK Epoll Bug in Thrift of TThreadedSele...

2017-08-12 Thread jeking3 
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1313
  
According to the documentation of the defect that triggered this 
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6670302), it indicates 
this only occurs in kernel 2.4 series, and if you move to kernel 2.6 this issue 
goes away.  Given this is an operating system defect, I'm inclined to recommend 
we do not merge this and resolve it as won't fix, because it isn't a defect in 
Thrift or in Java, but rather in the operating system it is running on.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-4251) Epoll Selector Bug

2017-08-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-4251:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1313
  
According to the documentation of the defect that triggered this 
(http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6670302), it indicates 
this only occurs in kernel 2.4 series, and if you move to kernel 2.6 this issue 
goes away.  Given this is an operating system defect, I'm inclined to recommend 
we do not merge this and resolve it as won't fix, because it isn't a defect in 
Thrift or in Java, but rather in the operating system it is running on.


> Epoll Selector Bug
> --
>
> Key: THRIFT-4251
> URL: https://issues.apache.org/jira/browse/THRIFT-4251
> Project: Thrift
>  Issue Type: Bug
>  Components: Java - Compiler, Java - Library
>Affects Versions: 0.10.0
> Environment: Linux version 3.10.0-327.el7.x86_64 
> (buil...@kbuilder.dev.centos.org)
> java version "1.8.0_131"
>Reporter: JohnnyLiao
>  Labels: epoll, jdk, selector
>
> Thrift java unsolve the infamous epoll bug. It's consum 100% cpu resource 
> when this occured. It seems to affect any NIO based Java server applications 
> running in the specified environment. Some projects provide workarounds for 
> similar JDK bugs, for example replaces the current Selector of this 
> SelectorThread.select with newly created Selector.
> Stack Trace：
> "Thread-46" #95 prio=5 os_prio=0 tid=0x7fc79cd02800 nid=0xb1 runnable 
> [0x7fc580bd1000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> - locked <0x8012f748> (a sun.nio.ch.Util$3)
> - locked <0x8012f738> (a 
> java.util.Collections$UnmodifiableSet)
> - locked <0x80120f58> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.select(TThreadedSelectorServer.java:570)
> at 
> org.apache.thrift.server.TThreadedSelectorServer$SelectorThread.run(TThreadedSelectorServer.java:541)



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

[GitHub] thrift pull request #1314: THRIFT-4263: Fix use after free bug for thrown ex...

2017-08-12 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1314


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-4263) Fix use after free bug for thrown exceptions

2017-08-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-4263:


Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1314


> Fix use after free bug for thrown exceptions
> 
>
> Key: THRIFT-4263
> URL: https://issues.apache.org/jira/browse/THRIFT-4263
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0, 0.11.0
> Environment: Verified both on Debian unstable and Centos 7 under 
> valgrind
>Reporter: Roy Sindre Norangshol
>Assignee: James E. King, III
>Priority: Critical
> Fix For: 0.11.0
>
>
> Fix use after free bug for thrown exceptions
> Exceptions thrown through PHPExceptionWrapper are prematurely freed at
> the end of the catch block, even though zend_throw_exception_object
> expects to take ownership of the value.



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

[jira] [Resolved] (THRIFT-4263) Fix use after free bug for thrown exceptions

2017-08-12 Thread James E. King, III (JIRA) 

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

James E. King, III resolved THRIFT-4263.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.11.0

> Fix use after free bug for thrown exceptions
> 
>
> Key: THRIFT-4263
> URL: https://issues.apache.org/jira/browse/THRIFT-4263
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Library
>Affects Versions: 0.10.0, 0.11.0
> Environment: Verified both on Debian unstable and Centos 7 under 
> valgrind
>Reporter: Roy Sindre Norangshol
>Assignee: James E. King, III
>Priority: Critical
> Fix For: 0.11.0
>
>
> Fix use after free bug for thrown exceptions
> Exceptions thrown through PHPExceptionWrapper are prematurely freed at
> the end of the catch block, even though zend_throw_exception_object
> expects to take ownership of the value.



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

[jira] [Resolved] (THRIFT-3821) TMemoryBuffer buffer may overflow when resizing

2017-08-12 Thread James E. King, III (JIRA) 

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

James E. King, III resolved THRIFT-3821.

   Resolution: Fixed
 Assignee: James E. King, III
Fix Version/s: 0.11.0

> TMemoryBuffer buffer may overflow when resizing
> ---
>
> Key: THRIFT-3821
> URL: https://issues.apache.org/jira/browse/THRIFT-3821
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Huaisi Xu
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> In ensurecanwrite():
> {code}
>   uint32_t new_size = bufferSize_;
>   while (len > avail) {
> new_size = new_size > 0 ? new_size * 2 : 1;
> avail = available_write() + (new_size - bufferSize_);
>   }
>   // Allocate into a new pointer so we don't bork ours if it fails.
>   uint8_t* new_buffer = static_cast(std::realloc(buffer_, 
> new_size));
>   if (new_buffer == NULL) {
> throw std::bad_alloc();
>   }
>   rBase_ = new_buffer + (rBase_ - buffer_);
>   rBound_ = new_buffer + (rBound_ - buffer_);
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
>   buffer_ = new_buffer;
>   bufferSize_ = new_size;
> {code}
> If old bufferSize_ is lager than 2gb, then calculating new size will overflow.
> i.e. if bufferSize_ = 3355443200, then new buffer size will be 2415919104, 
> which is less than old size.
> However, 
> {code}
> avail = available_write() + (new_size - bufferSize_) 
> {code}
> overflows again, so we will end up with an shrinked buffer.
> What is worse is that after
> {code}
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
> {code}
> wBase_ stays the same, but wBound_ becomes lower than it. What happens next 
> is that   uint32_t avail = available_write() may overflow every time 
> subsequently. and thrift writes to unknown memory.



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

[jira] [Commented] (THRIFT-3821) TMemoryBuffer buffer may overflow when resizing

2017-08-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-3821:


Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1326


> TMemoryBuffer buffer may overflow when resizing
> ---
>
> Key: THRIFT-3821
> URL: https://issues.apache.org/jira/browse/THRIFT-3821
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Huaisi Xu
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>
> In ensurecanwrite():
> {code}
>   uint32_t new_size = bufferSize_;
>   while (len > avail) {
> new_size = new_size > 0 ? new_size * 2 : 1;
> avail = available_write() + (new_size - bufferSize_);
>   }
>   // Allocate into a new pointer so we don't bork ours if it fails.
>   uint8_t* new_buffer = static_cast(std::realloc(buffer_, 
> new_size));
>   if (new_buffer == NULL) {
> throw std::bad_alloc();
>   }
>   rBase_ = new_buffer + (rBase_ - buffer_);
>   rBound_ = new_buffer + (rBound_ - buffer_);
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
>   buffer_ = new_buffer;
>   bufferSize_ = new_size;
> {code}
> If old bufferSize_ is lager than 2gb, then calculating new size will overflow.
> i.e. if bufferSize_ = 3355443200, then new buffer size will be 2415919104, 
> which is less than old size.
> However, 
> {code}
> avail = available_write() + (new_size - bufferSize_) 
> {code}
> overflows again, so we will end up with an shrinked buffer.
> What is worse is that after
> {code}
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
> {code}
> wBase_ stays the same, but wBound_ becomes lower than it. What happens next 
> is that   uint32_t avail = available_write() may overflow every time 
> subsequently. and thrift writes to unknown memory.



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

[GitHub] thrift pull request #1326: THRIFT-3821

2017-08-12 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1326


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-3821) TMemoryBuffer buffer may overflow when resizing

2017-08-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-3821:


Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1326
  
I'd prefer if we refactored it to make the limit configurable with a 
default matching what it is now; that way tests won't need multiple gigabytes 
of memory to function properly.  I'll approve and merge this for now as it is 
an improvement.


> TMemoryBuffer buffer may overflow when resizing
> ---
>
> Key: THRIFT-3821
> URL: https://issues.apache.org/jira/browse/THRIFT-3821
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Huaisi Xu
>
> In ensurecanwrite():
> {code}
>   uint32_t new_size = bufferSize_;
>   while (len > avail) {
> new_size = new_size > 0 ? new_size * 2 : 1;
> avail = available_write() + (new_size - bufferSize_);
>   }
>   // Allocate into a new pointer so we don't bork ours if it fails.
>   uint8_t* new_buffer = static_cast(std::realloc(buffer_, 
> new_size));
>   if (new_buffer == NULL) {
> throw std::bad_alloc();
>   }
>   rBase_ = new_buffer + (rBase_ - buffer_);
>   rBound_ = new_buffer + (rBound_ - buffer_);
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
>   buffer_ = new_buffer;
>   bufferSize_ = new_size;
> {code}
> If old bufferSize_ is lager than 2gb, then calculating new size will overflow.
> i.e. if bufferSize_ = 3355443200, then new buffer size will be 2415919104, 
> which is less than old size.
> However, 
> {code}
> avail = available_write() + (new_size - bufferSize_) 
> {code}
> overflows again, so we will end up with an shrinked buffer.
> What is worse is that after
> {code}
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
> {code}
> wBase_ stays the same, but wBound_ becomes lower than it. What happens next 
> is that   uint32_t avail = available_write() may overflow every time 
> subsequently. and thrift writes to unknown memory.



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

[GitHub] thrift issue #1326: THRIFT-3821

2017-08-12 Thread jeking3 
Github user jeking3 commented on the issue:

https://github.com/apache/thrift/pull/1326
  
I'd prefer if we refactored it to make the limit configurable with a 
default matching what it is now; that way tests won't need multiple gigabytes 
of memory to function properly.  I'll approve and merge this for now as it is 
an improvement.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-3821) TMemoryBuffer buffer may overflow when resizing

2017-08-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-3821:


Github user asuhan commented on the issue:

https://github.com/apache/thrift/pull/1326
  
Are there any additional changes I should make to this pull request? As 
I've said in the inline comment, I believe comparing to 
`std::numeric_limits::max()` is actually consistent with what the 
error message says.


> TMemoryBuffer buffer may overflow when resizing
> ---
>
> Key: THRIFT-3821
> URL: https://issues.apache.org/jira/browse/THRIFT-3821
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3
>Reporter: Huaisi Xu
>
> In ensurecanwrite():
> {code}
>   uint32_t new_size = bufferSize_;
>   while (len > avail) {
> new_size = new_size > 0 ? new_size * 2 : 1;
> avail = available_write() + (new_size - bufferSize_);
>   }
>   // Allocate into a new pointer so we don't bork ours if it fails.
>   uint8_t* new_buffer = static_cast(std::realloc(buffer_, 
> new_size));
>   if (new_buffer == NULL) {
> throw std::bad_alloc();
>   }
>   rBase_ = new_buffer + (rBase_ - buffer_);
>   rBound_ = new_buffer + (rBound_ - buffer_);
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
>   buffer_ = new_buffer;
>   bufferSize_ = new_size;
> {code}
> If old bufferSize_ is lager than 2gb, then calculating new size will overflow.
> i.e. if bufferSize_ = 3355443200, then new buffer size will be 2415919104, 
> which is less than old size.
> However, 
> {code}
> avail = available_write() + (new_size - bufferSize_) 
> {code}
> overflows again, so we will end up with an shrinked buffer.
> What is worse is that after
> {code}
>   wBase_ = new_buffer + (wBase_ - buffer_);
>   wBound_ = new_buffer + new_size;
> {code}
> wBase_ stays the same, but wBound_ becomes lower than it. What happens next 
> is that   uint32_t avail = available_write() may overflow every time 
> subsequently. and thrift writes to unknown memory.



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

[GitHub] thrift issue #1326: THRIFT-3821

2017-08-12 Thread asuhan 
Github user asuhan commented on the issue:

https://github.com/apache/thrift/pull/1326
  
Are there any additional changes I should make to this pull request? As 
I've said in the inline comment, I believe comparing to 
`std::numeric_limits::max()` is actually consistent with what the 
error message says.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-4106) concurrency_test fails randomly on MinGW

2017-08-12 Thread James E. King, III (JIRA) 

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

James E. King, III commented on THRIFT-4106:


It also seems to fail on WIN32 x86 (32-bit) builds, which is why it is disabled 
in appveyor.yml.

> concurrency_test fails randomly on MinGW
> 
>
> Key: THRIFT-4106
> URL: https://issues.apache.org/jira/browse/THRIFT-4106
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.10.0
> Environment: MinGW (appveyor)
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> While adding Appveyor build support for MinGW (THRIFT-4081), this test failed 
> periodically.  It would throw an exception in ThreadFactoryTest reapTest 
> where it calls monitor.wait(1000).  It is reproducible locally as well if you 
> have msys2/mingw64 and can use the instructions in the msys2 readme in 
> build/cmake.  The test has been disabled in mingw appveyor builds for now 
> (those builds are new...)



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

[jira] [Updated] (THRIFT-4106) concurrency_test fails randomly on MinGW

2017-08-12 Thread James E. King, III (JIRA) 

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

James E. King, III updated THRIFT-4106:
---
Affects Version/s: (was: 0.11.0)
   0.10.0

> concurrency_test fails randomly on MinGW
> 
>
> Key: THRIFT-4106
> URL: https://issues.apache.org/jira/browse/THRIFT-4106
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.10.0
> Environment: MinGW (appveyor)
>Reporter: James E. King, III
>Assignee: James E. King, III
>
> While adding Appveyor build support for MinGW (THRIFT-4081), this test failed 
> periodically.  It would throw an exception in ThreadFactoryTest reapTest 
> where it calls monitor.wait(1000).  It is reproducible locally as well if you 
> have msys2/mingw64 and can use the instructions in the msys2 readme in 
> build/cmake.  The test has been disabled in mingw appveyor builds for now 
> (those builds are new...)



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

[GitHub] thrift pull request #1034: THRIFT-3857

2017-08-12 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1034


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-4284) File contains a NBSP: lib/nodejs/lib/thrift/web_server.js

2017-08-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-4284:


Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1330


> File contains a NBSP: lib/nodejs/lib/thrift/web_server.js
> -
>
> Key: THRIFT-4284
> URL: https://issues.apache.org/jira/browse/THRIFT-4284
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Affects Versions: 0.9.2, 0.9.3, 0.10.0
>Reporter: Claudio Procida
>Assignee: James E. King, III
> Fix For: 0.11.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> This file contains a non-breaking space ({{\u00a0}}): 
> {{lib/nodejs/lib/thrift/web_server.js}}
> We found the issue while bundling the npm module [thrift|https://npm.im] with 
> {{browserify}}, resulting into a syntax error in the browser.
> If you look at line 287 in [the raw 
> file|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob_plain;f=lib/nodejs/lib/thrift/web_server.js;hb=HEAD],
>  there is an {{'Â'}} character between a value and the next key. 
> Interestingly, the [web 
> UI|https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=lib/nodejs/lib/thrift/web_server.js;hb=HEAD#l287]
>  doesn't show the issue.
> The [raw file on the GitHub 
> mirror|https://raw.githubusercontent.com/apache/thrift/master/lib/nodejs/lib/thrift/web_server.js]
>  is not garbled.



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

[GitHub] thrift pull request #1330: THRIFT-4284: remove extraneous character

2017-08-12 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1330


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (THRIFT-3974) Using clang-3.8 and ThreadSanitizer on the concurrency_test claims bad PThread behavior

2017-08-12 Thread James E. King, III (JIRA) 

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

James E. King, III resolved THRIFT-3974.

   Resolution: Fixed
Fix Version/s: 0.11.0

> Using clang-3.8 and ThreadSanitizer on the concurrency_test claims bad 
> PThread behavior
> ---
>
> Key: THRIFT-3974
> URL: https://issues.apache.org/jira/browse/THRIFT-3974
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
> Fix For: 0.11.0
>
>
> After using ThreadSanitizer to prove THRIFT-2755 is no longer present after 
> THRIFT-3932 was completed, it looks like there are some issues in the 
> PThreadThread class, specifically that the destructor calls a virtual method. 
>  ThreadSanitizer picks calls this out (many, many times).  
> The usage may be correct, but since we're not using C++11 we cannot seal the 
> class (mark it with the final keyword) which would tell ThreadSanitizer 
> nothing can inherit from the class, making that behavior safe.
> Another way to deal with this is to move the join implementation to a 
> non-virtual method and have both the dtor and join() call it.



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

[GitHub] thrift pull request #1331: THRIFT-3974: fix ThreadSanitizer identified issue...

2017-08-12 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/1331


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (THRIFT-3974) Using clang-3.8 and ThreadSanitizer on the concurrency_test claims bad PThread behavior

2017-08-12 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on THRIFT-3974:


GitHub user jeking3 opened a pull request:

https://github.com/apache/thrift/pull/1331

THRIFT-3974: fix ThreadSanitizer identified issues

Tested with pthread, boost and std threads and -fsanitizer=thread with 
clang-4.0.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jeking3/thrift THRIFT-3974

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1331.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1331


commit 8a7d13e6a7acde8883be88ecca6506fb0ee695d7
Author: James E. King, III 
Date:   2017-08-12T20:04:55Z

THRIFT-3974: fix ThreadSanitizer identified issues




> Using clang-3.8 and ThreadSanitizer on the concurrency_test claims bad 
> PThread behavior
> ---
>
> Key: THRIFT-3974
> URL: https://issues.apache.org/jira/browse/THRIFT-3974
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.3, 0.10.0
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> After using ThreadSanitizer to prove THRIFT-2755 is no longer present after 
> THRIFT-3932 was completed, it looks like there are some issues in the 
> PThreadThread class, specifically that the destructor calls a virtual method. 
>  ThreadSanitizer picks calls this out (many, many times).  
> The usage may be correct, but since we're not using C++11 we cannot seal the 
> class (mark it with the final keyword) which would tell ThreadSanitizer 
> nothing can inherit from the class, making that behavior safe.
> Another way to deal with this is to move the join implementation to a 
> non-virtual method and have both the dtor and join() call it.



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

[GitHub] thrift pull request #1331: THRIFT-3974: fix ThreadSanitizer identified issue...

2017-08-12 Thread jeking3 
GitHub user jeking3 opened a pull request:

https://github.com/apache/thrift/pull/1331

THRIFT-3974: fix ThreadSanitizer identified issues

Tested with pthread, boost and std threads and -fsanitizer=thread with 
clang-4.0.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jeking3/thrift THRIFT-3974

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/thrift/pull/1331.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1331


commit 8a7d13e6a7acde8883be88ecca6506fb0ee695d7
Author: James E. King, III 
Date:   2017-08-12T20:04:55Z

THRIFT-3974: fix ThreadSanitizer identified issues




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---