[jira] [Commented] (YETUS-70) add support for make, including cmake and autoconf
[
https://issues.apache.org/jira/browse/YETUS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102072#comment-15102072
]
Yetus QA commented on YETUS-70:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s {color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
0s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 17m 42s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/yetus:577e74f |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782095/YETUS-70.08.patch |
| JIRA Issue | YETUS-70 |
| Optional Tests | shellcheck |
| uname | Linux fce7e606b729 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | nobuild |
| git revision | master / d49f2ff |
| shellcheck | v0.4.3 |
| modules | C: . U: . |
| Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-YETUS-Build/230/console |
This message was automatically generated.
> add support for make, including cmake and autoconf
> --
>
> Key: YETUS-70
> URL: https://issues.apache.org/jira/browse/YETUS-70
> Project: Yetus
> Issue Type: New Feature
> Components: Test Patch
>Reporter: Allen Wittenauer
>Assignee: Allen Wittenauer
> Attachments: YETUS-70.00.patch, YETUS-70.01.patch, YETUS-70.02.patch,
> YETUS-70.03.patch, YETUS-70.04.patch, YETUS-70.05.patch, YETUS-70.06.patch,
> YETUS-70.07.patch, YETUS-70.08.patch
>
>
> Given make is still likely the #1 build tool used in the world, we should add
> support.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (YETUS-285) flag to enable/disable docker privileged mode
Allen Wittenauer created YETUS-285: -- Summary: flag to enable/disable docker privileged mode Key: YETUS-285 URL: https://issues.apache.org/jira/browse/YETUS-285 Project: Yetus Issue Type: New Feature Components: Test Patch Reporter: Allen Wittenauer Assignee: Allen Wittenauer Priority: Blocker Some commands (such as ps, ld, etc) will use PTRACE in order to perform some operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we should run docker in privileged mode with the capability to disable it. Later on, when 1.10 becomes more common, we can flip the default to false. https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-70) add support for make, including cmake and autoconf
[ https://issues.apache.org/jira/browse/YETUS-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102050#comment-15102050 ] Yetus QA commented on YETUS-70: --- (!) A patch to the testing environment has been detected. Re-executing against the patched versions to perform further tests. The console is at https://builds.apache.org/job/PreCommit-YETUS-Build/230/console in case of problems. > add support for make, including cmake and autoconf > -- > > Key: YETUS-70 > URL: https://issues.apache.org/jira/browse/YETUS-70 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer > Attachments: YETUS-70.00.patch, YETUS-70.01.patch, YETUS-70.02.patch, > YETUS-70.03.patch, YETUS-70.04.patch, YETUS-70.05.patch, YETUS-70.06.patch, > YETUS-70.07.patch, YETUS-70.08.patch > > > Given make is still likely the #1 build tool used in the world, we should add > support. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-285) flag to enable/disable docker privileged mode
[
https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102213#comment-15102213
]
Yetus QA commented on YETUS-285:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} shellcheck {color} | {color:red} 0m 5s
{color} | {color:red} The applied patch generated 2 new shellcheck issues
(total was 13, now 15). {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
1s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 18s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/yetus:577e74f |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782573/YETUS-285.00.patch |
| JIRA Issue | YETUS-285 |
| Optional Tests | shellcheck |
| uname | Linux 1b5ca8a5dd44 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | nobuild |
| git revision | master / d49f2ff |
| shellcheck | v0.4.1 |
| shellcheck |
https://builds.apache.org/job/PreCommit-YETUS-Build/231/artifact/patchprocess/diff-patch-shellcheck.txt
|
| modules | C: U: |
| Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-YETUS-Build/231/console |
This message was automatically generated.
> flag to enable/disable docker privileged mode
> -
>
> Key: YETUS-285
> URL: https://issues.apache.org/jira/browse/YETUS-285
> Project: Yetus
> Issue Type: New Feature
> Components: Test Patch
>Reporter: Allen Wittenauer
>Assignee: Allen Wittenauer
>Priority: Blocker
> Attachments: YETUS-285.00.patch
>
>
> Some commands (such as ps, ld, etc) will use PTRACE in order to perform some
> operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied
> by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we
> should run docker in privileged mode with the capability to disable it.
> Later on, when 1.10 becomes more common, we can flip the default to false.
> https://github.com/docker/docker/issues/7276 has the gory details.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-285) flag to enable/disable docker privileged mode
[ https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102265#comment-15102265 ] Yetus QA commented on YETUS-285: (!) A patch to the testing environment has been detected. Re-executing against the patched versions to perform further tests. The console is at https://builds.apache.org/job/PreCommit-YETUS-Build/232/console in case of problems. > flag to enable/disable docker privileged mode > - > > Key: YETUS-285 > URL: https://issues.apache.org/jira/browse/YETUS-285 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Blocker > Attachments: YETUS-285.00.patch, YETUS-285.01.patch > > > Some commands (such as ps, ld, etc) will use PTRACE in order to perform some > operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied > by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we > should run docker in privileged mode with the capability to disable it. > Later on, when 1.10 becomes more common, we can flip the default to false. > https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-285) flag to enable/disable docker privileged mode
[ https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102255#comment-15102255 ] Allen Wittenauer commented on YETUS-285: Hmm. Looks like shellcheck calcdiffs has a bug? > flag to enable/disable docker privileged mode > - > > Key: YETUS-285 > URL: https://issues.apache.org/jira/browse/YETUS-285 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Blocker > Attachments: YETUS-285.00.patch > > > Some commands (such as ps, ld, etc) will use PTRACE in order to perform some > operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied > by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we > should run docker in privileged mode with the capability to disable it. > Later on, when 1.10 becomes more common, we can flip the default to false. > https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-285) flag to enable/disable docker privileged mode
[
https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102293#comment-15102293
]
Allen Wittenauer commented on YETUS-285:
Temporary(?) network failure:
{code}
QuickCheck-2.8.2 failed while downloading the package. The exception was:
user error (openTCPConnection: host lookup failure for "hackage.haskell.org")
{code}
> flag to enable/disable docker privileged mode
> -
>
> Key: YETUS-285
> URL: https://issues.apache.org/jira/browse/YETUS-285
> Project: Yetus
> Issue Type: New Feature
> Components: Test Patch
>Reporter: Allen Wittenauer
>Assignee: Allen Wittenauer
>Priority: Blocker
> Attachments: YETUS-285.00.patch, YETUS-285.01.patch
>
>
> Some commands (such as ps, ld, etc) will use PTRACE in order to perform some
> operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied
> by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we
> should run docker in privileged mode with the capability to disable it.
> Later on, when 1.10 becomes more common, we can flip the default to false.
> https://github.com/docker/docker/issues/7276 has the gory details.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (YETUS-285) flag to enable/disable docker privileged mode
[ https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102255#comment-15102255 ] Allen Wittenauer edited comment on YETUS-285 at 1/15/16 6:31 PM: - Hmm. Looks like shellcheck calcdiffs has a bug? Edit: nope, shellcheck got smarter. Drat. (hahah) was (Author: aw): Hmm. Looks like shellcheck calcdiffs has a bug? > flag to enable/disable docker privileged mode > - > > Key: YETUS-285 > URL: https://issues.apache.org/jira/browse/YETUS-285 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Blocker > Attachments: YETUS-285.00.patch > > > Some commands (such as ps, ld, etc) will use PTRACE in order to perform some > operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied > by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we > should run docker in privileged mode with the capability to disable it. > Later on, when 1.10 becomes more common, we can flip the default to false. > https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-285) flag to enable/disable docker privileged mode
[ https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102286#comment-15102286 ] Yetus QA commented on YETUS-285: (!) A patch to the testing environment has been detected. Re-executing against the patched versions to perform further tests. The console is at https://builds.apache.org/job/PreCommit-YETUS-Build/233/console in case of problems. > flag to enable/disable docker privileged mode > - > > Key: YETUS-285 > URL: https://issues.apache.org/jira/browse/YETUS-285 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Blocker > Attachments: YETUS-285.00.patch, YETUS-285.01.patch > > > Some commands (such as ps, ld, etc) will use PTRACE in order to perform some > operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied > by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we > should run docker in privileged mode with the capability to disable it. > Later on, when 1.10 becomes more common, we can flip the default to false. > https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (YETUS-285) flag to enable/disable docker privileged mode
[ https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer updated YETUS-285: --- Attachment: YETUS-285.01.patch 01: * fix shellcheck errors > flag to enable/disable docker privileged mode > - > > Key: YETUS-285 > URL: https://issues.apache.org/jira/browse/YETUS-285 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Blocker > Attachments: YETUS-285.00.patch, YETUS-285.01.patch > > > Some commands (such as ps, ld, etc) will use PTRACE in order to perform some > operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied > by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we > should run docker in privileged mode with the capability to disable it. > Later on, when 1.10 becomes more common, we can flip the default to false. > https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-285) flag to enable/disable docker privileged mode
[
https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102303#comment-15102303
]
Yetus QA commented on YETUS-285:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s {color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
0s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 6m 58s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/yetus:577e74f |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782580/YETUS-285.01.patch |
| JIRA Issue | YETUS-285 |
| Optional Tests | shellcheck |
| uname | Linux 8ef8dd2807b1 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | nobuild |
| git revision | master / d49f2ff |
| shellcheck | v0.4.3 |
| modules | C: U: |
| Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-YETUS-Build/233/console |
This message was automatically generated.
> flag to enable/disable docker privileged mode
> -
>
> Key: YETUS-285
> URL: https://issues.apache.org/jira/browse/YETUS-285
> Project: Yetus
> Issue Type: New Feature
> Components: Test Patch
>Reporter: Allen Wittenauer
>Assignee: Allen Wittenauer
>Priority: Blocker
> Attachments: YETUS-285.00.patch, YETUS-285.01.patch
>
>
> Some commands (such as ps, ld, etc) will use PTRACE in order to perform some
> operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied
> by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we
> should run docker in privileged mode with the capability to disable it.
> Later on, when 1.10 becomes more common, we can flip the default to false.
> https://github.com/docker/docker/issues/7276 has the gory details.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102418#comment-15102418
]
Colin Patrick McCabe commented on YETUS-286:
I did some Googling and most of the people complaining about "failed to map
segment from shared object: Permission denied" are complaining about selinux.
Is selinux enabled in any of our Docker images? Of course, that begs the
question of why the build failure would be intermittent, rather than repeatable.
Another random theory I had is that some process is updating {{libxml2.so.2}},
etc. etc. while the build is in progress, potentially deleting or renaming the
old version and causing this failure. However, I thought this had been
addressed during Dockerization.
Examples of this failure:
https://builds.apache.org/job/PreCommit-HADOOP-Build/8414/artifact/patchprocess/patch-compile-root-jdk1.8.0_66.txt
https://builds.apache.org/job/PreCommit-HADOOP-Build/8414/artifact/patchprocess/patch-compile-root-jdk1.7.0_91.txt
Obviously this is really frustrating and until we can fix this, we're going to
burn a lot of jenkins time re-running native patches... :(
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to randomly fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built. When
> this happens, the native build fails and returns a -1 even if there was no
> actual problem. This requires us to re-run Jenkins to get a correct result.
> The problem does not seem to reproduce locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102433#comment-15102433
]
Colin Patrick McCabe commented on YETUS-286:
We now we have some C++ code in the tree whose build time is drastically
reduced by using a higher concurrency level. Typical maven builds don't peg
the CPU because maven spends a lot of its time downloading things from the
internet, writing files, running unit tests, and so on. gcc processes also
don't use a lot of memory when compared to maven (most of the time). So I'm
skeptical that running make -j 16 will be that harmful in practice. We could
certainly look into tuning this, but I don't see why it would be the root cause
of "failed to map segment from shared object" failures.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
Colin Patrick McCabe created YETUS-286:
--
Summary: The native build randomly fails with "failed to map
segment from shared object"
Key: YETUS-286
URL: https://issues.apache.org/jira/browse/YETUS-286
Project: Yetus
Issue Type: Bug
Components: Test Patch
Affects Versions: 0.2.0
Reporter: Colin Patrick McCabe
Assignee: Sean Busbey
Priority: Critical
On Jenkins, the native build seems to randomly fail with "failed to map segment
from shared object." For example:
{code}
[WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
failed to map segment from shared object: Permission denied
{code}
We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
other native libraries which are dependencies of the thing being built. When
this happens, the native build fails and returns a -1 even if there was no
actual problem. This requires us to re-run Jenkins to get a correct result.
The problem does not seem to reproduce locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102425#comment-15102425
]
Allen Wittenauer commented on YETUS-286:
Hmm:
{code}
[INFO] Running make -j 16 VERBOSE=1
{code}
Why is it suddenly running so many make's at one time? That's going to pretty
much burn all of the nodes resources to the ground, especially when two builds
are running at once
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to randomly fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built. When
> this happens, the native build fails and returns a -1 even if there was no
> actual problem. This requires us to re-run Jenkins to get a correct result.
> The problem does not seem to reproduce locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colin Patrick McCabe updated YETUS-286:
---
Description:
On Jenkins, the native build seems to intermittently fail with "failed to map
segment from shared object." For example:
{code}
[WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
failed to map segment from shared object: Permission denied
{code}
We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
other native libraries which are dependencies of the thing being built.
Basically, there is some random chance any particular native dependency will
get "failed to map segment." When this happens, the native build fails and
returns a -1 even if there was no actual problem. This requires us to re-run
Jenkins to get a correct result. The problem does not seem to reproduce
locally.
was:
On Jenkins, the native build seems to randomly fail with "failed to map segment
from shared object." For example:
{code}
[WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
failed to map segment from shared object: Permission denied
{code}
We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
other native libraries which are dependencies of the thing being built. When
this happens, the native build fails and returns a -1 even if there was no
actual problem. This requires us to re-run Jenkins to get a correct result.
The problem does not seem to reproduce locally.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (YETUS-285) flag to enable/disable docker privileged mode
[ https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer updated YETUS-285: --- Description: Some commands (such as ps, etc) will use PTRACE in order to perform some operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we should run docker in privileged mode with the capability to disable it. Later on, when 1.10 becomes more common, we can flip the default to false. https://github.com/docker/docker/issues/7276 has the gory details. was: Some commands (such as ps, ld, etc) will use PTRACE in order to perform some operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we should run docker in privileged mode with the capability to disable it. Later on, when 1.10 becomes more common, we can flip the default to false. https://github.com/docker/docker/issues/7276 has the gory details. > flag to enable/disable docker privileged mode > - > > Key: YETUS-285 > URL: https://issues.apache.org/jira/browse/YETUS-285 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Blocker > Attachments: YETUS-285.00.patch, YETUS-285.01.patch > > > Some commands (such as ps, etc) will use PTRACE in order to perform some > operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied > by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we > should run docker in privileged mode with the capability to disable it. > Later on, when 1.10 becomes more common, we can flip the default to false. > https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102503#comment-15102503
]
Colin Patrick McCabe commented on YETUS-286:
We can definitely tune the concurrency level of make... or use cgroups as
[~andrew.wang] has suggested.
However, even assuming that we ran out of memory because of running too many
{{make}} processes at once, I don't understand how that would lead to a
{{failed to map segment from shared object: Permission denied}} error. This
corresponds to the POSIX error code {{EACESS}}. If we couldn't allocate
memory, I would expect to see {{Cannot allocate memory}}, which corresponds to
{{ENOMEM}}. Or I would expect to see the OOM killer send a SIGKILL, which
would lead to "Terminated" messages. Perhaps I am missing something, but I am
having a hard time seeing how running out of memory or CPU would cause
"Permission denied" errors.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102509#comment-15102509
]
Sean Busbey commented on YETUS-286:
---
the few complaints I can find about this online all appear to be based on
trying to make use of libraries that are in a place with noexec.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102507#comment-15102507
]
Colin Patrick McCabe commented on YETUS-286:
I'd also add that we've seen this in the past before we increased the
concurrency of {{make}} past 1. I don't think anyone ever definitively
identified the problem. I always assumed that it had something to do with
{{apt-get}} running in the background, but that was a pure guess, I admit.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102517#comment-15102517
]
Sean Busbey commented on YETUS-286:
---
looks like Mesos hit the same issue using docker on asf infra in MESOS-2233.
let's try their fix.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102529#comment-15102529
]
Sean Busbey commented on YETUS-286:
---
yes, exactly! how serendipitous!
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-285) flag to enable/disable docker privileged mode
[ https://issues.apache.org/jira/browse/YETUS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102538#comment-15102538 ] Sean Busbey commented on YETUS-285: --- +1 > flag to enable/disable docker privileged mode > - > > Key: YETUS-285 > URL: https://issues.apache.org/jira/browse/YETUS-285 > Project: Yetus > Issue Type: New Feature > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer >Priority: Blocker > Attachments: YETUS-285.00.patch, YETUS-285.01.patch > > > Some commands (such as ps, etc) will use PTRACE in order to perform some > operations. In older versions (read: pre-1.10) of Docker, PTRACE is denied > by AppArmor on Ubunutu, causing spurious errors.In order to fix this, we > should run docker in privileged mode with the capability to disable it. > Later on, when 1.10 becomes more common, we can flip the default to false. > https://github.com/docker/docker/issues/7276 has the gory details. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (YETUS-173) report fixed issues
[ https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer updated YETUS-173: --- Attachment: YETUS-173.00.patch > report fixed issues > --- > > Key: YETUS-173 > URL: https://issues.apache.org/jira/browse/YETUS-173 > Project: Yetus > Issue Type: Improvement > Components: Test Patch >Reporter: Allen Wittenauer > Attachments: YETUS-173.00.patch > > > We should do a better job of reporting when issues are fixed, such as in > findbugs or javac. Minimally, report the old and new numbers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (YETUS-173) report fixed issues
[ https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer reassigned YETUS-173: -- Assignee: Allen Wittenauer > report fixed issues > --- > > Key: YETUS-173 > URL: https://issues.apache.org/jira/browse/YETUS-173 > Project: Yetus > Issue Type: Improvement > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer > Attachments: YETUS-173.00.patch > > > We should do a better job of reporting when issues are fixed, such as in > findbugs or javac. Minimally, report the old and new numbers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102796#comment-15102796
]
Xiao Chen commented on YETUS-286:
-
FYI - the above build succeeded!
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102637#comment-15102637
]
Xiao Chen commented on YETUS-286:
-
Thanks everyone for the work here!
I've been running into this in HADOOP-12715 twice consecutively this today. I
just kicked off another build with that same patch at
https://builds.apache.org/job/PreCommit-HADOOP-Build/8424/ . Hopefully this run
can help confirm.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-173) report fixed issues
[
https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102744#comment-15102744
]
Yetus QA commented on YETUS-173:
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
7s {color} | {color:green} The applied patch generated 0 new + 13 unchanged - 1
fixed = 13 total (was 14) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
0s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 20m 30s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/yetus:577e74f |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782640/YETUS-173.01.patch |
| JIRA Issue | YETUS-173 |
| Optional Tests | shellcheck |
| uname | Linux 3e94e61fd8a9 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | nobuild |
| git revision | master / 5056bd9 |
| shellcheck | v0.4.3 |
| modules | C: U: |
| Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-YETUS-Build/235/console |
This message was automatically generated.
> report fixed issues
> ---
>
> Key: YETUS-173
> URL: https://issues.apache.org/jira/browse/YETUS-173
> Project: Yetus
> Issue Type: Improvement
> Components: Test Patch
>Reporter: Allen Wittenauer
>Assignee: Allen Wittenauer
> Attachments: YETUS-173.00.patch, YETUS-173.01.patch
>
>
> We should do a better job of reporting when issues are fixed, such as in
> findbugs or javac. Minimally, report the old and new numbers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102856#comment-15102856
]
Allen Wittenauer commented on YETUS-286:
I think the Linux kernel's ability to find new and inventive ways to be bad is
probably it's most interesting feature.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102896#comment-15102896
]
Sean Busbey commented on YETUS-286:
---
good to hear it worked. I'll leave this open until later next week, presuming
y'all are actively working on the native code?
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-173) report fixed issues
[ https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102679#comment-15102679 ] Allen Wittenauer commented on YETUS-173: Going to remove YETUS-70 as a blocker since this will likely end up going in first. :/ > report fixed issues > --- > > Key: YETUS-173 > URL: https://issues.apache.org/jira/browse/YETUS-173 > Project: Yetus > Issue Type: Improvement > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer > Attachments: YETUS-173.00.patch > > > We should do a better job of reporting when issues are fixed, such as in > findbugs or javac. Minimally, report the old and new numbers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-173) report fixed issues
[ https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102677#comment-15102677 ] Allen Wittenauer commented on YETUS-173: -00: * for plugins that provide numbers, status is now an equation. e.g.: hadoop-tools/hadoop-azure: patch generated 2 new + 57 unchanged - 9 fixed = 59 total (was 0) * if a patch fixes issues, still report the equation. previously test-patch would only report on new problems. if the status is unchanged, the "passed" message is retained. > report fixed issues > --- > > Key: YETUS-173 > URL: https://issues.apache.org/jira/browse/YETUS-173 > Project: Yetus > Issue Type: Improvement > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer > Attachments: YETUS-173.00.patch > > > We should do a better job of reporting when issues are fixed, such as in > findbugs or javac. Minimally, report the old and new numbers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-173) report fixed issues
[
https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102700#comment-15102700
]
Yetus QA commented on YETUS-173:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} shellcheck {color} | {color:red} 0m 7s
{color} | {color:red} The applied patch generated 13 new + 12 unchanged - 1
fixed = 25 total (was 0) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
0s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 38s {color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/yetus:577e74f |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782638/YETUS-173.00.patch |
| JIRA Issue | YETUS-173 |
| Optional Tests | shellcheck |
| uname | Linux 8da4f6a74e5b 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | nobuild |
| git revision | master / 5056bd9 |
| shellcheck | v0.4.1 |
| shellcheck |
https://builds.apache.org/job/PreCommit-YETUS-Build/234/artifact/patchprocess/diff-patch-shellcheck.txt
|
| modules | C: U: |
| Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org |
| Console output |
https://builds.apache.org/job/PreCommit-YETUS-Build/234/console |
This message was automatically generated.
> report fixed issues
> ---
>
> Key: YETUS-173
> URL: https://issues.apache.org/jira/browse/YETUS-173
> Project: Yetus
> Issue Type: Improvement
> Components: Test Patch
>Reporter: Allen Wittenauer
>Assignee: Allen Wittenauer
> Attachments: YETUS-173.00.patch
>
>
> We should do a better job of reporting when issues are fixed, such as in
> findbugs or javac. Minimally, report the old and new numbers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (YETUS-173) report fixed issues
[ https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102697#comment-15102697 ] Yetus QA commented on YETUS-173: (!) A patch to the testing environment has been detected. Re-executing against the patched versions to perform further tests. The console is at https://builds.apache.org/job/PreCommit-YETUS-Build/234/console in case of problems. > report fixed issues > --- > > Key: YETUS-173 > URL: https://issues.apache.org/jira/browse/YETUS-173 > Project: Yetus > Issue Type: Improvement > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer > Attachments: YETUS-173.00.patch > > > We should do a better job of reporting when issues are fixed, such as in > findbugs or javac. Minimally, report the old and new numbers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-173) report fixed issues
[ https://issues.apache.org/jira/browse/YETUS-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102711#comment-15102711 ] Yetus QA commented on YETUS-173: (!) A patch to the testing environment has been detected. Re-executing against the patched versions to perform further tests. The console is at https://builds.apache.org/job/PreCommit-YETUS-Build/235/console in case of problems. > report fixed issues > --- > > Key: YETUS-173 > URL: https://issues.apache.org/jira/browse/YETUS-173 > Project: Yetus > Issue Type: Improvement > Components: Test Patch >Reporter: Allen Wittenauer >Assignee: Allen Wittenauer > Attachments: YETUS-173.00.patch, YETUS-173.01.patch > > > We should do a better job of reporting when issues are fixed, such as in > findbugs or javac. Minimally, report the old and new numbers. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YETUS-286) The native build randomly fails with "failed to map segment from shared object"
[
https://issues.apache.org/jira/browse/YETUS-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102783#comment-15102783
]
Colin Patrick McCabe commented on YETUS-286:
Thanks, all. We'll keep an eye out... hopefully this is the last we'll see
this.
> The native build randomly fails with "failed to map segment from shared
> object"
> ---
>
> Key: YETUS-286
> URL: https://issues.apache.org/jira/browse/YETUS-286
> Project: Yetus
> Issue Type: Bug
> Components: Test Patch
>Affects Versions: 0.2.0
>Reporter: Colin Patrick McCabe
>Assignee: Sean Busbey
>Priority: Critical
>
> On Jenkins, the native build seems to intermittently fail with "failed to map
> segment from shared object." For example:
> {code}
> [WARNING] /usr/bin/cmake: error while loading shared libraries: libxml2.so.2:
> failed to map segment from shared object: Permission denied
> {code}
> We have also seen this happen with {{librtmp.so.0}}, {{libcurl.so.4}}, and
> other native libraries which are dependencies of the thing being built.
> Basically, there is some random chance any particular native dependency will
> get "failed to map segment." When this happens, the native build fails and
> returns a -1 even if there was no actual problem. This requires us to re-run
> Jenkins to get a correct result. The problem does not seem to reproduce
> locally.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (YETUS-270) precommit javadoc warning is confusing
[ https://issues.apache.org/jira/browse/YETUS-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved YETUS-270. Resolution: Duplicate Closing this as a dupe of YETUS-173. > precommit javadoc warning is confusing > -- > > Key: YETUS-270 > URL: https://issues.apache.org/jira/browse/YETUS-270 > Project: Yetus > Issue Type: Bug >Reporter: Wei-Chiu Chuang >Priority: Minor > > For example, in https://issues.apache.org/jira/browse/HDFS-9612, > a warning states:: > "-1 javadoc 1m 7s hadoop-tools_hadoop-distcp-jdk1.8.0_66 with JDK > v1.8.0_66 generated 1 new issues (was 51, now 51)." > Since 51+1 != 51, this warning is confusing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
