Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

src: fix build on CentOS #7873

Closed
wants to merge 1 commit into from
Closed

Conversation

Trott
Copy link
Member

@Trott Trott commented Jul 25, 2016

Checklist
  • make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
  • commit message follows commit guidelines
Affected core subsystem(s)
Description of change

85af1a6 was added (squashed into another commit) without running through CI. Unfortunately, it breaks some of the CI builds, notably on three of the CentOS setups.

Undoing that one small change to get builds green again.

@Trott Trott added the wip Issues and PRs that are still a work in progress. label Jul 25, 2016
@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Jul 25, 2016
85af1a6 was added (squashed into another commit) without running
through CI. Unfortunately, it breaks some of the CI builds, notably on
three of the CentOS setups.

Undoing that one small change to get builds green again.

Refs: nodejs#7547 (comment)
PR-URL: nodejs#7873
@Trott Trott removed the wip Issues and PRs that are still a work in progress. label Jul 25, 2016
@Trott Trott changed the title WIP: 85af1a609fc05 src: fix build on CentOS Jul 25, 2016
@Trott
Copy link
Member Author

Trott commented Jul 25, 2016

@Trott
Copy link
Member Author

Trott commented Jul 25, 2016

@Fishrock123
Copy link
Contributor

rubber-stamp lgtm if CI passes

@jbergstroem
Copy link
Member

Thanks for this. Bots pass again -- LGTM.

@bnoordhuis
Copy link
Member

LGTM. ci.nodejs.org 502s for me so I don't know what the actual build error was.

@jbergstroem
Copy link
Member

Jenkins just had a OOM. Sometimes 28G ram just ain't enough -- should be back now, but it seems to be running a git gc over 12 cores so give it some breathing room!

@Trott
Copy link
Member Author

Trott commented Jul 25, 2016

Hmmm...old CI is now 404, and I'm not sure if anyone saw it finish or not, so let's try again:

CI: https://ci.nodejs.org/job/node-test-pull-request/3406/

@addaleax
Copy link
Member

LGTM if CI is green

@Trott
Copy link
Member Author

Trott commented Jul 25, 2016

If CI is green, I'm going to land this right away to fix the CI builds. If anyone objects, please lodge your objection ASAP here. Thanks!

@Trott
Copy link
Member Author

Trott commented Jul 25, 2016

ubuntu1604-arm64 has been failing builds for two or three days now for apparently different reasons so I'm going to ignore that one. Otherwise, CI is green so far...

@Trott
Copy link
Member Author

Trott commented Jul 25, 2016

One Raspberry Pi buildbot failure too, but that's it. Landing...

Trott added a commit to Trott/io.js that referenced this pull request Jul 25, 2016
85af1a6 was added (squashed into another commit) without running
through CI. Unfortunately, it breaks some of the CI builds, notably on
three of the CentOS setups.

Undoing that one small change to get builds green again.

Refs: nodejs#7547 (comment)
PR-URL: nodejs#7873
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@Trott
Copy link
Member Author

Trott commented Jul 25, 2016

Landed in 809aabc. Thanks, everyone!

@Trott Trott closed this Jul 25, 2016
@danbev
Copy link
Contributor

danbev commented Jul 26, 2016

Sorry about causing this and creating the extra work for you, and thanks for fixing it.

I went looking at the failing CI builds but was not able to find much information, which might just be that I don't have the correct permission or something. What I wanted was to see any logs of the failure to help me understand the mistake I made to avoid this in the future.

What I had originally done was added an empty destructor:

    ~ConnectionWrap() {
    }

I later changed this to be an explicitly defaulted destructor generated by the compiler:

    ~ConnectionWrap() = default; 

My understanding/assumption was that these two would be equivalent.

To give some context, this is what the inheritance tree for ConnectionWrap looks like, with regards to destructors:

    class ConnectionWrap : public StreamWrap
      protected:
        ~ConnectionWrap() {}

    class StreamWrap : public HandleWrap, public StreamBase
      protected:
        ~StreamWrap() { }

    class HandleWrap : public AsyncWrap
      protected:
        ~HandleWrap() override;

    class AsyncWrap : public BaseObject
      public:
        inline virtual ~AsyncWrap();

    class BaseObject
      public:
        inline virtual ~BaseObject();

    class StreamBase : public StreamResource
      public:
        virtual ~StreamBase() = default;

    class StreamResource
      public:
        virtual ~StreamResource() = default;

If anyone can explain what I'm missing here it would be much appreciated.

@addaleax
Copy link
Member

The CI is a bit hard to navigate, you can find an output of a “real” compilation e.g. here. It shows internal compiler errors, so it’s definitely not your fault, and rather mine than anyone else’s for not running CI again with the last commit included before landing.

@danbev
Copy link
Contributor

danbev commented Jul 26, 2016

@addaleax Thanks for the link to the compilation error.

@danbev
Copy link
Contributor

danbev commented Jul 26, 2016

From looking at the error:

In file included from ../src/pipe_wrap.h:7:0,
                 from ../src/pipe_wrap.cc:1:
../src/connection_wrap.h:26:3: internal compiler error: in use_thunk, at cp/method.c:338
   ~ConnectionWrap() = default;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccvbqQz3.out file, please attach this to your bugreport.
ERROR: Cannot create report: [Errno 17] File exists: '/var/crash/_usr_lib_gcc_x86_64-linux-gnu_4.8_cc1plus.1000.crash'
make[2]: *** [/home/iojs/build/workspace/node-test-commit-linux/nodes/ubuntu1204-64/out/Release/obj.target/node/src/pipe_wrap.o] Error 1

it looks like GCC (G++) 4.8 is being used. The reason for asking is I did a search and found a few indications that this might be a bug in the compiler. This is reported as sovled in 4.8.3 which is also why I'm curious about the compiler version.

I'm don't mean to imply that the compiler version should be updated, just want to understand the issue here.

@bnoordhuis
Copy link
Member

I believe the centos machines use devtoolset-2, which comes with g++ 4.8.2.

@danbev
Copy link
Contributor

danbev commented Jul 26, 2016

@bnoordhuis Ah great, thanks for that.

@jbergstroem
Copy link
Member

Just confirming: we're using devtoolset-2.

@cjihrig cjihrig mentioned this pull request Aug 8, 2016
cjihrig pushed a commit that referenced this pull request Aug 10, 2016
85af1a6 was added (squashed into another commit) without running
through CI. Unfortunately, it breaks some of the CI builds, notably on
three of the CentOS setups.

Undoing that one small change to get builds green again.

Refs: #7547 (comment)
PR-URL: #7873
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
@cjihrig cjihrig mentioned this pull request Aug 11, 2016
@Trott Trott deleted the revert-revert-revert branch January 13, 2022 22:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ Issues and PRs that require attention from people who are familiar with C++.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants