[jira] [Created] (MESOS-6616) error: dereferencing type-punned pointer will break strict-aliasing rules
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
[ 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
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
[ 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.
[ 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.
[ 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.
[ 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
[ 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.
[ 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)