[jira] [Created] (MESOS-6616) error: dereferencing type-punned pointer will break strict-aliasing rules

2016-11-20 Thread Orion Poplawski (JIRA)
Orion Poplawski created MESOS-6616:
--

 Summary: error: dereferencing type-punned pointer will break 
strict-aliasing rules
 Key: MESOS-6616
 URL: https://issues.apache.org/jira/browse/MESOS-6616
 Project: Mesos
  Issue Type: Bug
Affects Versions: 1.1.0
 Environment: Fedora Rawhide
Reporter: Orion Poplawski


Trying to update the mesos package to 1.1.0 in Fedora.  Getting:

libtool: compile:  g++ -DPACKAGE_NAME=\"mesos\" -DPACKAGE_TARNAME=\"mesos\" 
-DPACKAGE_VERSION=\"1.1.0\" "-DPACKAGE_STRING=\"mesos 1.1.0\"" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mesos\" 
-DVERSION=\"1.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -DHAVE_CXX11=1 -DHAVE_PTHREAD_PRIO_INHERIT=1 
-DHAVE_PTHREAD=1 -DHAVE_LIBZ=1 -DHAVE_FTS_H=1 -DHAVE_APR_POOLS_H=1 
-DHAVE_LIBAPR_1=1 -DHAVE_BOOST_VERSION_HPP=1 -DHAVE_LIBCURL=1 
-DHAVE_ELFIO_ELFIO_HPP=1 -DHAVE_GLOG_LOGGING_H=1 -DHAVE_HTTP_PARSER_H=1 
-DMESOS_HAS_JAVA=1 -DHAVE_LEVELDB_DB_H=1 -DHAVE_LIBNL_3=1 
-DHAVE_LIBNL_ROUTE_3=1 -DHAVE_LIBNL_IDIAG_3=1 -DWITH_NETWORK_ISOLATOR=1 
-DHAVE_GOOGLE_PROTOBUF_MESSAGE_H=1 -DHAVE_EV_H=1 -DHAVE_PICOJSON_H=1 
-DHAVE_LIBSASL2=1 -DHAVE_SVN_VERSION_H=1 -DHAVE_LIBSVN_SUBR_1=1 
-DHAVE_SVN_DELTA_H=1 -DHAVE_LIBSVN_DELTA_1=1 -DHAVE_LIBZ=1 -DHAVE_ZOOKEEPER_H=1 
-DHAVE_PYTHON=\"2.7\" -DMESOS_HAS_PYTHON=1 -I. -Wall -Werror -Wsign-compare 
-DLIBDIR=\"/usr/lib64\" -DPKGLIBEXECDIR=\"/usr/libexec/mesos\" 
-DPKGDATADIR=\"/usr/share/mesos\" -DPKGMODULEDIR=\"/usr/lib64/mesos/modules\" 
-I../include -I../include -I../include/mesos -DPICOJSON_USE_INT64 
-D__STDC_FORMAT_MACROS -I../3rdparty/libprocess/include 
-I../3rdparty/nvml-352.79 -I../3rdparty/stout/include -DHAS_AUTHENTICATION=1 
-Iyes/include -I/usr/include/subversion-1 -Iyes/include -Iyes/include 
-Iyes/include/libnl3 -Iyes/include -I/ -Iyes/include -I/usr/include/apr-1 
-I/usr/include/apr-1.0 -I/builddir/build/BUILD/mesos-1.1.0/libev-4.15/include 
-isystem yes/include -Iyes/include -I/usr/src/gmock -I/usr/src/gmock/include 
-I/usr/src/gmock/src -I/usr/src/gmock/gtest -I/usr/src/gmock/gtest/include 
-I/usr/src/gmock/gtest/src -Iyes/include -Iyes/include -I/usr/include 
-I/builddir/build/BUILD/mesos-1.1.0/libev4.15/include -Iyes/include 
-I/usr/include -I/usr/include/zookeeper -pthread -O2 -g -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic 
-DEV_CHILD_ENABLE=0 -I/builddir/build/BUILD/mesos-1.1.0/libev-4.15 
-Wno-unused-local-typedefs -Wno-maybe-uninitialized -std=c++11 -c 
health-check/health_checker.cpp  -fPIC -DPIC -o 
health-check/.libs/libmesos_no_3rdparty_la-health_checker.o
In file included from health-check/health_checker.cpp:51:0:
./linux/ns.hpp: In function 'Try ns::clone(pid_t, int, const 
std::function&, int)':
./linux/ns.hpp:480:69: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
 pid_t pid = ((struct ucred*) CMSG_DATA(CMSG_FIRSTHDR()))->pid;
 ^~
./linux/ns.hpp: In lambda function:
./linux/ns.hpp:581:59: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
   ((struct ucred*) CMSG_DATA(CMSG_FIRSTHDR()))->pid = ::getpid();
   ^~
./linux/ns.hpp:582:59: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
   ((struct ucred*) CMSG_DATA(CMSG_FIRSTHDR()))->uid = ::getuid();
   ^~
./linux/ns.hpp:583:59: error: dereferencing type-punned pointer will break 
strict-aliasing rules [-Werror=strict-aliasing]
   ((struct ucred*) CMSG_DATA(CMSG_FIRSTHDR()))->gid = ::getgid();
   ^~
cc1plus: all warnings being treated as errors
make[2]: *** [Makefile:6655: 
health-check/libmesos_no_3rdparty_la-health_checker.lo] Error 1




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


[jira] [Updated] (MESOS-6615) Running mesos-slave in the docker that leave many zombie process

2016-11-20 Thread Lei Xu (JIRA)

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

Lei Xu updated MESOS-6615:
--
Component/s: containerization

> Running mesos-slave in the docker that leave many zombie process
> 
>
> Key: MESOS-6615
> URL: https://issues.apache.org/jira/browse/MESOS-6615
> Project: Mesos
>  Issue Type: Bug
>  Components: containerization, slave
>Affects Versions: 0.28.2
> Environment: Mesos 0.28.2 
> Docker 1.12.1
>Reporter: Lei Xu
>Priority: Critical
>
> Here are some zombie process if I run mesos-slave in the docker.
> {code}
> root 10547 19464  0 Oct25 ?00:00:00 [docker] 
> root 14505 19464  0 Oct25 ?00:00:00 [docker] 
> root 16069 19464  0 Oct25 ?00:00:00 [docker] 
> root 19962 19464  0 Oct25 ?00:00:00 [docker] 
> root 23346 19464  0 Oct25 ?00:00:00 [docker] 
> root 24544 19464  0 Oct25 ?00:00:00 [docker] 
> {code}
> And I find the zombies come from {{mesos-slave}} process:
> {code}
> pstree -p -s 10547
> systemd(1)───docker-containe(19448)───mesos-slave(19464)───docker(10547)
> {code}
> The logs has been deleted by the cron job a few weeks ago, but I remember so 
> many {{Failed to shutdown socket with fd xx: Transport endpoint is not 
> connected}} in the log.



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


[jira] [Created] (MESOS-6615) Running mesos-slave in the docker that leave many zombie process

2016-11-20 Thread Lei Xu (JIRA)
Lei Xu created MESOS-6615:
-

 Summary: Running mesos-slave in the docker that leave many zombie 
process
 Key: MESOS-6615
 URL: https://issues.apache.org/jira/browse/MESOS-6615
 Project: Mesos
  Issue Type: Bug
  Components: slave
Affects Versions: 0.28.2
 Environment: Mesos 0.28.2 
Docker 1.12.1
Reporter: Lei Xu
Priority: Critical


Here are some zombie process if I run mesos-slave in the docker.

{code}
root 10547 19464  0 Oct25 ?00:00:00 [docker] 
root 14505 19464  0 Oct25 ?00:00:00 [docker] 
root 16069 19464  0 Oct25 ?00:00:00 [docker] 
root 19962 19464  0 Oct25 ?00:00:00 [docker] 
root 23346 19464  0 Oct25 ?00:00:00 [docker] 
root 24544 19464  0 Oct25 ?00:00:00 [docker] 
{code}

And I find the zombies come from {{mesos-slave}} process:

{code}
pstree -p -s 10547
systemd(1)───docker-containe(19448)───mesos-slave(19464)───docker(10547)
{code}

The logs has been deleted by the cron job a few weeks ago, but I remember so 
many {{Failed to shutdown socket with fd xx: Transport endpoint is not 
connected}} in the log.



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


[jira] [Commented] (MESOS-5540) Support building with non-GNU libc

2016-11-20 Thread Lei Xu (JIRA)

[ 
https://issues.apache.org/jira/browse/MESOS-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15682353#comment-15682353
 ] 

Lei Xu commented on MESOS-5540:
---

join this thread, very useful issue for building mesos in the musl-libc. thanks 
all !

> Support building with non-GNU libc
> --
>
> Key: MESOS-5540
> URL: https://issues.apache.org/jira/browse/MESOS-5540
> Project: Mesos
>  Issue Type: Improvement
>  Components: general
>Reporter: Neil Conway
>Assignee: Neil Conway
>Priority: Minor
>  Labels: mesosphere
> Fix For: 1.0.0
>
>
> Some Linux distributions don't use glibc -- e.g., Alpine Linux uses musl. 
> Mesos currently fails to compile using musl for at least the following two 
> reasons:
> 1. {{linux/fs.hpp}} includes {{fstab.h}}, which isn't provided by musl.
> 2. various places use {{fts.h}}, which isn't provided by musl
> For (1), it seems this functionality is only needed by 
> {{FsTest.FileSystemTableRead}}, so I think it can be safely removed.
> For (2), there are standalone implementations of the FTS functions, e.g., 
> https://github.com/pullmoll/musl-fts/ . We could either vendor such an 
> implementation or require the user to install an FTS implementation as a 
> library (e.g., https://pkgs.alpinelinux.org/package/edge/main/x86_64/fts). If 
> we do the latter, we'd need to be prepared to link against {{libfts.a}} if 
> needed.



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


[jira] [Updated] (MESOS-5662) Call parent class `SetUpTestCase` function in our test fixtures.

2016-11-20 Thread Anand Mazumdar (JIRA)

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

Anand Mazumdar updated MESOS-5662:
--
Description: 
There are some occurrences in our code where we don't invoke the parent's 
{{SetUpTestCase}} method from a child test fixture. This can be a bit 
problematic if the parent class has its own custom {{SetUpTestCase}} logic or 
someone adds one in the future. It would be good to do a sweep across the code 
and explicitly invoke the parent class's method.

Some examples (there are more):
https://github.com/apache/mesos/blob/master/src/tests/mesos.cpp#L80
https://github.com/apache/mesos/blob/master/src/tests/module_tests.cpp#L59

  was:
There are some occurrences in our code where we don't invoke the parent's 
{{SetUpTestCase}} method from a child test fixture. This can be a bit 
problematic if someone adds the method in the parent class sometime in the 
future. It would be good to do a sweep across the code and explicitly invoke 
the parent class's method.

Some examples (there are more):
https://github.com/apache/mesos/blob/master/src/tests/mesos.cpp#L80
https://github.com/apache/mesos/blob/master/src/tests/module_tests.cpp#L59


> Call parent class `SetUpTestCase` function in our test fixtures.
> 
>
> Key: MESOS-5662
> URL: https://issues.apache.org/jira/browse/MESOS-5662
> Project: Mesos
>  Issue Type: Bug
>  Components: test
>Reporter: Anand Mazumdar
>Assignee: Manuwela Kanade
>  Labels: mesosphere, newbie
>
> There are some occurrences in our code where we don't invoke the parent's 
> {{SetUpTestCase}} method from a child test fixture. This can be a bit 
> problematic if the parent class has its own custom {{SetUpTestCase}} logic or 
> someone adds one in the future. It would be good to do a sweep across the 
> code and explicitly invoke the parent class's method.
> Some examples (there are more):
> https://github.com/apache/mesos/blob/master/src/tests/mesos.cpp#L80
> https://github.com/apache/mesos/blob/master/src/tests/module_tests.cpp#L59



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


[jira] [Updated] (MESOS-6604) Uninitialized member ObjectApprover::weight_info.

2016-11-20 Thread Alexander Rukletsov (JIRA)

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

Alexander Rukletsov updated MESOS-6604:
---
  Sprint: Mesosphere Sprint 47
Story Points: 1
  Labels: coverity mesosphere tech-debt  (was: coverity tech-debt)
Priority: Minor  (was: Major)

> Uninitialized member ObjectApprover::weight_info.
> -
>
> Key: MESOS-6604
> URL: https://issues.apache.org/jira/browse/MESOS-6604
> Project: Mesos
>  Issue Type: Bug
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>Priority: Minor
>  Labels: coverity, mesosphere, tech-debt
>
> In {{include/mesos/authorizer/authorizer.hpp}} the member 
> {{ObjectApprover::weight_info}} is a raw ptr which is not initialized (with 
> {{nullptr}}) in the ctr.
> While the member is {{public}}, requiring users to set up the {{class}} is 
> error-prone; it is also contrary to what is done  for other members.
> Instead this member should be initialized to {{nullptr}}. As a more long-term 
> solution we should consider introducing some non-owning wrapper for raw ptrs 
> to stout which on construction initializes the raw ptr, see MESOS-6603.
> This was detected by coverity as CID 1394390.



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


[jira] [Updated] (MESOS-6604) Uninitialized member ObjectApprover::weight_info.

2016-11-20 Thread Alexander Rukletsov (JIRA)

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

Alexander Rukletsov updated MESOS-6604:
---
Summary: Uninitialized member ObjectApprover::weight_info.  (was: 
Uninitialized member ObjectApprover::weight_info)

> Uninitialized member ObjectApprover::weight_info.
> -
>
> Key: MESOS-6604
> URL: https://issues.apache.org/jira/browse/MESOS-6604
> Project: Mesos
>  Issue Type: Bug
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: coverity, tech-debt
>
> In {{include/mesos/authorizer/authorizer.hpp}} the member 
> {{ObjectApprover::weight_info}} is a raw ptr which is not initialized (with 
> {{nullptr}}) in the ctr.
> While the member is {{public}}, requiring users to set up the {{class}} is 
> error-prone; it is also contrary to what is done  for other members.
> Instead this member should be initialized to {{nullptr}}. As a more long-term 
> solution we should consider introducing some non-owning wrapper for raw ptrs 
> to stout which on construction initializes the raw ptr, see MESOS-6603.
> This was detected by coverity as CID 1394390.



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


[jira] [Updated] (MESOS-6604) Uninitialized member ObjectApprover::weight_info

2016-11-20 Thread Benjamin Bannier (JIRA)

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

Benjamin Bannier updated MESOS-6604:

Shepherd: Alexander Rukletsov
Assignee: Benjamin Bannier

> Uninitialized member ObjectApprover::weight_info
> 
>
> Key: MESOS-6604
> URL: https://issues.apache.org/jira/browse/MESOS-6604
> Project: Mesos
>  Issue Type: Bug
>Reporter: Benjamin Bannier
>Assignee: Benjamin Bannier
>  Labels: coverity, tech-debt
>
> In {{include/mesos/authorizer/authorizer.hpp}} the member 
> {{ObjectApprover::weight_info}} is a raw ptr which is not initialized (with 
> {{nullptr}}) in the ctr.
> While the member is {{public}}, requiring users to set up the {{class}} is 
> error-prone; it is also contrary to what is done  for other members.
> Instead this member should be initialized to {{nullptr}}. As a more long-term 
> solution we should consider introducing some non-owning wrapper for raw ptrs 
> to stout which on construction initializes the raw ptr, see MESOS-6603.
> This was detected by coverity as CID 1394390.



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


[jira] [Updated] (MESOS-6603) Introduce non-owning wrapper for raw ptrs.

2016-11-20 Thread Alexander Rukletsov (JIRA)

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

Alexander Rukletsov updated MESOS-6603:
---
Summary: Introduce non-owning wrapper for raw ptrs.  (was: Introduce 
non-owning wrapper for raw ptrs)

> Introduce non-owning wrapper for raw ptrs.
> --
>
> Key: MESOS-6603
> URL: https://issues.apache.org/jira/browse/MESOS-6603
> Project: Mesos
>  Issue Type: Wish
>  Components: stout
>Reporter: Benjamin Bannier
>
> A number of classes have non-owning raw ptrs, typically as some member 
> {{[const] T*}}. Raw C ptrs are not initialized on declaration which makes it 
> very convenient to introduce uninitialized variables.
> We should consider introducing a very thin, non-owning wrapper around raw 
> ptrs which ensures the wrapper raw ptr is properly initialized to 
> {{nullptr}}. It should be possible to implement such a wrapper without adding 
> new runtime overhead to correct usage of raw ptrs.



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