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

/cc @jbergstroem @danbev @addaleax @trevnorris @bnoordhuis

rubber-stamp lgtm if CI passes

Thanks for this. Bots pass again -- LGTM.

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

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!

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/

LGTM if CI is green

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!

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...

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

Landed in 809aabc. Thanks, everyone!

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.

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.

@addaleax Thanks for the link to the compilation error.

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.

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

@bnoordhuis Ah great, thanks for that.

Just confirming: we're using devtoolset-2.