Compiling contracts with solc 0.6.2 (commit.bacdbe57) fails with spawnSync /bin/sh ENOBUFS

Archive SDK
1

@pcowgill reported on Telegram

any idea how to get around this after running oz compile?
:heavy_multiplication_x: Compiling contracts with solc 0.6.2 (commit.bacdbe57)
spawnSync /bin/sh ENOBUFS

Using solc 0.6.2
OpenZeppelin CLI v 2.7.1

2

Hi @pcowgill,

It would be great to reproduce this problem. When you have recovered from the hackathon, any information you could provide would be great.

ENOBUFS looks like it may be an issue with the compiler:
https://github.com/ethereum/solidity/issues/8133

ENOBUFS does not sound like a problem with the memory used by the compiler, but rather with the buffers used to send input and output back and forth. Maybe you selected too much output from the compiler and nodejs cannot handle it?

Last time I saw this (Oz compile fails with spawnSync /bin/sh ENOBUFS) we got around it by changing the compiler version, though you are using solc 0.6.2 which is the latest.

3

Thanks for flagging this as an issue.

Sure, I can share a reproduction. We ended up building our contracts using a different tool for speed reasons at the hackathon once we encountered this bug, I’m afraid.

Can you also share an “unreproduction”? That is, an example where it is working? Thanks!

1 Like
4

Hi @pcowgill,

It would be great to be able to reproduce. I had assumed that this was a compiler issue, so interesting that another build tool didn’t have this issue.

I can compile the following simple example importing from OpenZeppelin Contracts 3.0 Beta with solc 0.6.3 on node 13.8.0. (on Windows Subsystem for Linux)

$ npx oz compile
✓ Compiled contracts with solc 0.6.3 (commit.8dda9521)

SimpleERC721Token.sol

pragma solidity ^0.6.0;

import "@openzeppelin/contracts/token/ERC721/ERC721Full.sol";
import "@openzeppelin/contracts/ownership/Ownable.sol";
import "@openzeppelin/contracts/drafts/Strings.sol";

contract SimpleERC721Token is ERC721Full, Ownable {

    constructor () public ERC721Full("Simple ERC721 Token", "SIM") {
        _setBaseURI("https://example.com/tokens/");
    }

    function setBaseURI(string memory baseURI) public onlyOwner {
        _setBaseURI(baseURI);
    }

    function mint(address to) public onlyOwner {
        uint256 tokenId = totalSupply().add(1);
        _mint(to, tokenId);
        _setTokenURI(tokenId, Strings.fromUint256(tokenId));
    }
}
1 Like
5

Hi @pcowgill,

Would appreciate any information to help reproduce this issue.

Ideally the contract which resulted in this issue, along with the operating system, node, npm and CLI versions.

1 Like
6

These are the contracts that didn’t work with the oz CLI

1 Like
7

macOS 10.15.3
Node version - not sure, it was either 10 or 12
npm version - default when using latest 10 or 12 version with nvm
CLI version - hmm, wish I knew. Latest as of the day of ETHDenver?

1 Like
8

Thanks @pcowgill that is really helpful. I can see if I can reproduce.

1 Like
9

I tried on Windows Subsystem for Linux using node 10 and node 12 and haven’t been able to reproduce as yet.

1 Like
10

Is there anyone on the OpenZeppelin team with a Mac who can try it sometime when they have a moment? No rush, especially since it took me a while to share the reproduction details. Thanks!

1 Like
11

Oh, and I see that this was the oz CLI version ^

1 Like
12

Hi @pcowgill,

I have created an Issue: https://github.com/OpenZeppelin/openzeppelin-sdk/issues/1498 to track.

Closed solc Issue ethereum/solidity#8133 has the following comment:

ethereum/solidity#8133 (comment)
ENOBUFS does not sound like a problem with the memory used by the compiler, but rather with the buffers used to send input and output back and forth.

I tried to reproduce with a high memory load but haven't got the error. Will have to try with a Mac.

1 Like
13

Was not able to reproduce on Linux.

1 Like