[jira] [Commented] (THRIFT-3826) Appveyor builds cannot download winflexbison properly

[James E. King, III (JIRA)]

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

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


I don't think this is related to your changes, but you can probably fix it 
faster than I can.

> Appveyor builds cannot download winflexbison properly
> -
>
> Key: THRIFT-3826
> URL: https://issues.apache.org/jira/browse/THRIFT-3826
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appveyor
>Reporter: James E. King, III
>Assignee: Aki Sukegawa
>Priority: Blocker
>
> {noformat}
> cinst winflexbison
> Installing the following packages:
> winflexbison
> By installing you accept licenses for the packages.
>  
> winflexbison v2.4.3.20140715
>  Downloading winflexbison 32 bit
>from 
> 'http://sourceforge.net/projects/winflexbison/files/old_versions/win_flex_bison-2.4.3.zip'
>  Chocolatey expected a file at 
> 'C:\Users\appveyor\AppData\Local\Temp\1\chocolate
>  y\winflexbison\2.4.3.20140715\winflexbisonInstall.zip' to be of length 
>  '667674' but the length was '69240'.
>  At C:\ProgramData\chocolatey\helpers\functions\Get-ChocolateyWebFile.ps1:162 
>  char:101
>  + if ($headers.ContainsKey("Content-Length") -and ($fi.Length -ne 
>  $headers["Co ...
>  + 
> ~
>  ~~~{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (THRIFT-3826) Appveyor builds cannot download winflexbison properly

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-3826:
---
Assignee: Aki Sukegawa

> Appveyor builds cannot download winflexbison properly
> -
>
> Key: THRIFT-3826
> URL: https://issues.apache.org/jira/browse/THRIFT-3826
> Project: Thrift
>  Issue Type: Bug
>  Components: Build Process
>Affects Versions: 0.10.0
> Environment: Appveyor
>Reporter: James E. King, III
>Assignee: Aki Sukegawa
>Priority: Blocker
>
> {noformat}
> cinst winflexbison
> Installing the following packages:
> winflexbison
> By installing you accept licenses for the packages.
>  
> winflexbison v2.4.3.20140715
>  Downloading winflexbison 32 bit
>from 
> 'http://sourceforge.net/projects/winflexbison/files/old_versions/win_flex_bison-2.4.3.zip'
>  Chocolatey expected a file at 
> 'C:\Users\appveyor\AppData\Local\Temp\1\chocolate
>  y\winflexbison\2.4.3.20140715\winflexbisonInstall.zip' to be of length 
>  '667674' but the length was '69240'.
>  At C:\ProgramData\chocolatey\helpers\functions\Get-ChocolateyWebFile.ps1:162 
>  char:101
>  + if ($headers.ContainsKey("Content-Length") -and ($fi.Length -ne 
>  $headers["Co ...
>  + 
> ~
>  ~~~{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3826) Appveyor builds cannot download winflexbison properly

[James E. King, III (JIRA)]

James E. King, III created THRIFT-3826:
--

 Summary: Appveyor builds cannot download winflexbison properly
 Key: THRIFT-3826
 URL: https://issues.apache.org/jira/browse/THRIFT-3826
 Project: Thrift
  Issue Type: Bug
  Components: Build Process
Affects Versions: 0.10.0
 Environment: Appveyor
Reporter: James E. King, III
Priority: Blocker


{noformat}
cinst winflexbison
Installing the following packages:
winflexbison
By installing you accept licenses for the packages.
 
winflexbison v2.4.3.20140715
 Downloading winflexbison 32 bit
   from 
'http://sourceforge.net/projects/winflexbison/files/old_versions/win_flex_bison-2.4.3.zip'
 Chocolatey expected a file at 'C:\Users\appveyor\AppData\Local\Temp\1\chocolate
 y\winflexbison\2.4.3.20140715\winflexbisonInstall.zip' to be of length 
 '667674' but the length was '69240'.
 At C:\ProgramData\chocolatey\helpers\functions\Get-ChocolateyWebFile.ps1:162 
 char:101
 + if ($headers.ContainsKey("Content-Length") -and ($fi.Length -ne 
 $headers["Co ...
 + ~
 ~~~{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: Thrift-precommit #471

[Apache Jenkins Server]

See 

--
GitHub pull request #981 to apache/thrift
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-2 (docker Ubuntu ubuntu yahoo-not-h2) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository https://github.com/apache/thrift.git
 > git init  # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/thrift.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/apache/thrift.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/thrift.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/thrift.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/thrift.git
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/apache/thrift.git +refs/heads/*:refs/remotes/origin/*
 > git config core.sparsecheckout # timeout=10
 > git checkout -f origin/master # timeout=10
 > git branch -a # timeout=10
 > git rev-parse remotes/origin/0.1.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.2.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.3.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.4.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.5.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.6.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.7.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.8.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.1^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.2^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.3^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.x^{commit} # timeout=10
 > git rev-parse remotes/origin/master^{commit} # timeout=10
 > git rev-parse remotes/origin/py-compiler^{commit} # timeout=10
 > git checkout -b master origin/master
  Opening connection
Done: 0
  Counting objects
Done: 35
  Finding sources
Done: 35
  Getting sizes
Done: 27
  Compressing objects
Done: 28923
  Writing objects
Done: 35
  remote: Resolving deltas
  remote: Updating references
Merging refs/tags/changes/471
 > git rev-parse refs/tags/changes/471^{commit} # timeout=10
FATAL: Command "git rev-parse refs/tags/changes/471^{commit}" returned status 
code 128:
stdout: refs/tags/changes/471^{commit}

stderr: fatal: ambiguous argument 'refs/tags/changes/471^{commit}': unknown 
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

hudson.plugins.git.GitException: Command "git rev-parse 
refs/tags/changes/471^{commit}" returned status code 128:
stdout: refs/tags/changes/471^{commit}

stderr: fatal: ambiguous argument 'refs/tags/changes/471^{commit}': unknown 
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1669)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1665)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1307)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1319)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:677)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at 

Build failed in Jenkins: Thrift-precommit #470

[Apache Jenkins Server]

See 

--
GitHub pull request #980 to apache/thrift
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-2 (docker Ubuntu ubuntu yahoo-not-h2) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository https://github.com/apache/thrift.git
 > git init  # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/thrift.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/apache/thrift.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/thrift.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/thrift.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/thrift.git
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/apache/thrift.git +refs/heads/*:refs/remotes/origin/*
 > git config core.sparsecheckout # timeout=10
 > git checkout -f origin/master # timeout=10
 > git branch -a # timeout=10
 > git rev-parse remotes/origin/0.1.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.2.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.3.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.4.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.5.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.6.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.7.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.8.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.1^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.2^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.3^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.x^{commit} # timeout=10
 > git rev-parse remotes/origin/master^{commit} # timeout=10
 > git rev-parse remotes/origin/py-compiler^{commit} # timeout=10
 > git checkout -b master origin/master
  Opening connection
Done: 0
  Counting objects
Done: 82
  Finding sources
Done: 82
  Getting sizes
Done: 62
  Compressing objects
Done: 31097
  Writing objects
Done: 82
  remote: Resolving deltas
  remote: Updating references
Merging refs/tags/changes/470
 > git rev-parse refs/tags/changes/470^{commit} # timeout=10
FATAL: Command "git rev-parse refs/tags/changes/470^{commit}" returned status 
code 128:
stdout: refs/tags/changes/470^{commit}

stderr: fatal: ambiguous argument 'refs/tags/changes/470^{commit}': unknown 
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

hudson.plugins.git.GitException: Command "git rev-parse 
refs/tags/changes/470^{commit}" returned status code 128:
stdout: refs/tags/changes/470^{commit}

stderr: fatal: ambiguous argument 'refs/tags/changes/470^{commit}': unknown 
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1669)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1665)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1307)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1319)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:677)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at 

Build failed in Jenkins: Thrift-precommit #469

[Apache Jenkins Server]

See 

--
GitHub pull request #992 to apache/thrift
[EnvInject] - Loading node environment variables.
Building remotely on ubuntu-2 (docker Ubuntu ubuntu yahoo-not-h2) in workspace 

Wiping out workspace first.
Cloning the remote Git repository
Cloning repository https://github.com/apache/thrift.git
 > git init  # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/thrift.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/apache/thrift.git +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url https://github.com/apache/thrift.git # 
 > timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url https://github.com/apache/thrift.git # 
 > timeout=10
Fetching upstream changes from https://github.com/apache/thrift.git
 > git -c core.askpass=true fetch --tags --progress 
 > https://github.com/apache/thrift.git +refs/heads/*:refs/remotes/origin/*
 > git config core.sparsecheckout # timeout=10
 > git checkout -f origin/master # timeout=10
 > git branch -a # timeout=10
 > git rev-parse remotes/origin/0.1.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.2.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.3.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.4.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.5.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.6.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.7.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.8.x^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.1^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.2^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.3^{commit} # timeout=10
 > git rev-parse remotes/origin/0.9.x^{commit} # timeout=10
 > git rev-parse remotes/origin/master^{commit} # timeout=10
 > git rev-parse remotes/origin/py-compiler^{commit} # timeout=10
 > git checkout -b master origin/master
  Opening connection
Done: 0
  Counting objects
Done: 303
  Finding sources
Done: 303
  Getting sizes
Done: 207
  Compressing objects
Done: 434216
  Writing objects
Done: 303
  remote: Resolving deltas
  remote: Updating references
Merging refs/tags/changes/469
 > git rev-parse refs/tags/changes/469^{commit} # timeout=10
FATAL: Command "git rev-parse refs/tags/changes/469^{commit}" returned status 
code 128:
stdout: refs/tags/changes/469^{commit}

stderr: fatal: ambiguous argument 'refs/tags/changes/469^{commit}': unknown 
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

hudson.plugins.git.GitException: Command "git rev-parse 
refs/tags/changes/469^{commit}" returned status code 128:
stdout: refs/tags/changes/469^{commit}

stderr: fatal: ambiguous argument 'refs/tags/changes/469^{commit}': unknown 
revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1693)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1669)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1665)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1307)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1319)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:677)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:316)
at sun.reflect.GeneratedMethodAccessor93.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:608)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583)
at 
hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at 

[jira] [Updated] (THRIFT-3038) Use of volatile in cpp library

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-3038:
---
Description: 
In the cpp library there are several member variables which are declared 
volatile, I believe with the intention of providing some sort of thread-safety. 
While volatile can be used in this way in Java and C#, in C++ it cannot! It 
does not provide any guarantees with regard to instruction (re-)ordering, i.e. 
there are no implied memory barriers like you would get by using explicit 
locking or atomic variables.
This means that all uses of volatile should be examined, the volatile qualifier 
should be removed and replaced by proper synchronization.

The affected member variables are:

# NoStarveReadWriteMutex::writerWaiting_
Unprotected read access in acquireRead(). Data race can be seen by running the 
unit test with Helgrind.
# TFileTransport::forceFlush_ (already fixed)
Always accessed while holding mutex_. In this case, the volatile can just be 
removed.
# TFileTransport::closing_
Sometimes accessed while holding mutex_ (in combination with the notEmpty_ 
Monitor),
but, e.g., enqueueEvent reads closing_ without any synchronization.
# TThreadPoolServer::stop_, TThreadedServer::stop_ (already fixed)
Accessed (read and written) without synchronization. These would probably be 
fine using an atomic data type. Or, use explicit locking or signaling. 
# TThreadPoolServer::timeout_, TThreadPoolServer::taskExpiration_ (already 
fixed)
Should probably use a lock.
# Mutex.cpp has mutexProfilingCounter as static variable. This probably doesn’t 
break anything, but still the volatile serves no real purpose.

While some of the fixes are probably simple, in general I think someone with 
better knowledge of the code should have a look at this.

  was:
In the cpp library there are several member variables which are declared 
volatile, I believe with the intention of providing some sort of thread-safety. 
While volatile can be used in this way in Java and C#, in C++ it cannot! It 
does not provide any guarantees with regard to instruction (re-)ordering, i.e. 
there are no implied memory barriers like you would get by using explicit 
locking or atomic variables.
This means that all uses of volatile should be examined, the volatile qualifier 
should be removed and replaced by proper synchronization.

The affected member variables are:

# NoStarveReadWriteMutex::writerWaiting_
Unprotected read access in acquireRead(). Data race can be seen by running the 
unit test with Helgrind.
# TFileTransport::forceFlush_
Always accessed while holding mutex_. In this case, the volatile can just be 
removed.
# TFileTransport::closing_
Sometimes accessed while holding mutex_ (in combination with the notEmpty_ 
Monitor),
but, e.g., enqueueEvent reads closing_ without any synchronization.
# TThreadPoolServer::stop_, TThreadedServer::stop_
Accessed (read and written) without synchronization. These would probably be 
fine using an atomic data type. Or, use explicit locking or signaling. 
# TThreadPoolServer::timeout_, TThreadPoolServer::taskExpiration_
Should probably use a lock.
# Mutex.cpp has mutexProfilingCounter as static variable. This probably doesn’t 
break anything, but still the volatile serves no real purpose.

While some of the fixes are probably simple, in general I think someone with 
better knowledge of the code should have a look at this.


> Use of volatile in cpp library
> --
>
> Key: THRIFT-3038
> URL: https://issues.apache.org/jira/browse/THRIFT-3038
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: Adriaan Schmidt
>
> In the cpp library there are several member variables which are declared 
> volatile, I believe with the intention of providing some sort of 
> thread-safety. 
> While volatile can be used in this way in Java and C#, in C++ it cannot! It 
> does not provide any guarantees with regard to instruction (re-)ordering, 
> i.e. there are no implied memory barriers like you would get by using 
> explicit locking or atomic variables.
> This means that all uses of volatile should be examined, the volatile 
> qualifier should be removed and replaced by proper synchronization.
> The affected member variables are:
> # NoStarveReadWriteMutex::writerWaiting_
> Unprotected read access in acquireRead(). Data race can be seen by running 
> the unit test with Helgrind.
> # TFileTransport::forceFlush_ (already fixed)
> Always accessed while holding mutex_. In this case, the volatile can just be 
> removed.
> # TFileTransport::closing_
> Sometimes accessed while holding mutex_ (in combination with the notEmpty_ 
> Monitor),
> but, e.g., enqueueEvent reads closing_ without any synchronization.
> # TThreadPoolServer::stop_, TThreadedServer::stop_ 

[jira] [Updated] (THRIFT-3038) Use of volatile in cpp library

[James E. King, III (JIRA)]

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

James E. King, III updated THRIFT-3038:
---
Description: 
In the cpp library there are several member variables which are declared 
volatile, I believe with the intention of providing some sort of thread-safety. 
While volatile can be used in this way in Java and C#, in C++ it cannot! It 
does not provide any guarantees with regard to instruction (re-)ordering, i.e. 
there are no implied memory barriers like you would get by using explicit 
locking or atomic variables.
This means that all uses of volatile should be examined, the volatile qualifier 
should be removed and replaced by proper synchronization.

The affected member variables are:

# NoStarveReadWriteMutex::writerWaiting_
Unprotected read access in acquireRead(). Data race can be seen by running the 
unit test with Helgrind.
# (already fixed) TFileTransport::forceFlush_
Always accessed while holding mutex_. In this case, the volatile can just be 
removed.
# TFileTransport::closing_
Sometimes accessed while holding mutex_ (in combination with the notEmpty_ 
Monitor),
but, e.g., enqueueEvent reads closing_ without any synchronization.
# (already fixed) TThreadPoolServer::stop_, TThreadedServer::stop_
Accessed (read and written) without synchronization. These would probably be 
fine using an atomic data type. Or, use explicit locking or signaling. 
# (already fixed) TThreadPoolServer::timeout_, 
TThreadPoolServer::taskExpiration_
Should probably use a lock.
# Mutex.cpp has mutexProfilingCounter as static variable. This probably doesn’t 
break anything, but still the volatile serves no real purpose.

While some of the fixes are probably simple, in general I think someone with 
better knowledge of the code should have a look at this.

  was:
In the cpp library there are several member variables which are declared 
volatile, I believe with the intention of providing some sort of thread-safety. 
While volatile can be used in this way in Java and C#, in C++ it cannot! It 
does not provide any guarantees with regard to instruction (re-)ordering, i.e. 
there are no implied memory barriers like you would get by using explicit 
locking or atomic variables.
This means that all uses of volatile should be examined, the volatile qualifier 
should be removed and replaced by proper synchronization.

The affected member variables are:

# NoStarveReadWriteMutex::writerWaiting_
Unprotected read access in acquireRead(). Data race can be seen by running the 
unit test with Helgrind.
# TFileTransport::forceFlush_ (already fixed)
Always accessed while holding mutex_. In this case, the volatile can just be 
removed.
# TFileTransport::closing_
Sometimes accessed while holding mutex_ (in combination with the notEmpty_ 
Monitor),
but, e.g., enqueueEvent reads closing_ without any synchronization.
# TThreadPoolServer::stop_, TThreadedServer::stop_ (already fixed)
Accessed (read and written) without synchronization. These would probably be 
fine using an atomic data type. Or, use explicit locking or signaling. 
# TThreadPoolServer::timeout_, TThreadPoolServer::taskExpiration_ (already 
fixed)
Should probably use a lock.
# Mutex.cpp has mutexProfilingCounter as static variable. This probably doesn’t 
break anything, but still the volatile serves no real purpose.

While some of the fixes are probably simple, in general I think someone with 
better knowledge of the code should have a look at this.


> Use of volatile in cpp library
> --
>
> Key: THRIFT-3038
> URL: https://issues.apache.org/jira/browse/THRIFT-3038
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.2
>Reporter: Adriaan Schmidt
>
> In the cpp library there are several member variables which are declared 
> volatile, I believe with the intention of providing some sort of 
> thread-safety. 
> While volatile can be used in this way in Java and C#, in C++ it cannot! It 
> does not provide any guarantees with regard to instruction (re-)ordering, 
> i.e. there are no implied memory barriers like you would get by using 
> explicit locking or atomic variables.
> This means that all uses of volatile should be examined, the volatile 
> qualifier should be removed and replaced by proper synchronization.
> The affected member variables are:
> # NoStarveReadWriteMutex::writerWaiting_
> Unprotected read access in acquireRead(). Data race can be seen by running 
> the unit test with Helgrind.
> # (already fixed) TFileTransport::forceFlush_
> Always accessed while holding mutex_. In this case, the volatile can just be 
> removed.
> # TFileTransport::closing_
> Sometimes accessed while holding mutex_ (in combination with the notEmpty_ 
> Monitor),
> but, e.g., enqueueEvent reads closing_ without any synchronization.
> # 

[jira] [Commented] (THRIFT-2850) CMake for Apache Thrift

[James E. King, III (JIRA)]

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

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


So, is this one "Fixed" now?

> CMake for Apache Thrift
> ---
>
> Key: THRIFT-2850
> URL: https://issues.apache.org/jira/browse/THRIFT-2850
> Project: Thrift
>  Issue Type: Improvement
>  Components: Build Process
> Environment: all platforms
>Reporter: Roger Meier
>Assignee: Roger Meier
>  Labels: cmake, travis
> Fix For: 1.0
>
> Attachments: 0001-THRIFT-2850-CMake-for-Apache-Thrift.patch, 
> THRIFT-2850_change_name_add_test_py.patch
>
>
> Goal: Extend Apache Thrift's *make cross* approach to the build system.
> Due to growing the field of operating system support, a proper executable
> and library detection mechanism running on as much platforms as possible
> becomes required. The other aspect is simplify the release process and
> package generation process.
> As nice side benefit of CMake is the generation of development environment
> specific solution files(VisualStudio, Eclipse, Xcode, etc. ). => No solution 
> files within source tree.
> We are already building Apache Thrift with CMake for Linux-ARM, Linux-x86, 
> Windows CE and Windows.
> We are in preparation phase for a pull request here:
> https://github.com/siemens/thrift/commits/cmake-master



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (THRIFT-3825) Javascript test dependency is no longer available

[Aki Sukegawa (JIRA)]

Aki Sukegawa created THRIFT-3825:


 Summary: Javascript test dependency is no longer available
 Key: THRIFT-3825
 URL: https://issues.apache.org/jira/browse/THRIFT-3825
 Project: Thrift
  Issue Type: Bug
  Components: JavaScript - Library, Test Suite
Reporter: Aki Sukegawa
Priority: Critical


https://travis-ci.org/apache/thrift/jobs/130235249
{code}
[get] Getting: 
http://js-test-driver.googlecode.com/svn/trunk/JsTestDriver/contrib/qunit/src/equiv.js
[get] To: /thrift/src/lib/js/test/build/js/lib/equiv.js
[get] Error opening connection java.io.FileNotFoundException: 
http://js-test-driver.googlecode.com/svn/trunk/JsTestDriver/contrib/qunit/src/equiv.js
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] thrift pull request: THRIFT-3815 Put appveyor dependency versions ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request: THRIFT-3814 Fix contention in TNonblockingSer...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request: THRIFT-3816 Reduce docker build duration on T...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 pull request: #fix php CompactProtocol readI64 function, va...

[nsuke]

Github user nsuke commented on the pull request:

https://github.com/apache/thrift/pull/1008#issuecomment-219226708
  
@lnn1123 thanks for the fix !
Could you file a JIRA issue for this ?
https://github.com/apache/thrift/blob/master/CONTRIBUTING.md



---
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-3787) Node.js Connection object doesn't handle errors correctly

[Randy Abernethy (JIRA)]

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

Randy Abernethy resolved THRIFT-3787.
-
   Resolution: Fixed
Fix Version/s: 0.10.0

committed, thanks for the patch!

missed the attrib on this one, apologies. You are in the patch field. Will get 
you in the author field next go.

> Node.js Connection object doesn't handle errors correctly
> -
>
> Key: THRIFT-3787
> URL: https://issues.apache.org/jira/browse/THRIFT-3787
> Project: Thrift
>  Issue Type: Bug
>  Components: Node.js - Library
>Reporter: James Reggio
>Assignee: Randy Abernethy
>Priority: Minor
> Fix For: 0.10.0
>
>
> There are a handful of operation-ordering problems in the 
> Connection.prototype.connection_gone() method and its friends.
> See the pull request for more details.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)