Solidity: Getting 'Segmentation fault: 11' error when compiling with solc

[makoto]

http://ethereum.stackexchange.com/questions/2828/getting-segmentation-fault-while-compiling-solidity-contract

[chriseth]

Can you run it inside gdb to see where the segfault happens?
Furthermore, I am pretty sure this is a build error. How did you install solc?

[winsvega]

--bin -o solcoutput contract.sol

contract test { function multiply(uint a) returns(uint d) { return a * 7; } }

works

[adetante]

Same problem on Mac OS X El Capitan (10.11.4) using solc in command line.

Version: 0.3.2-9e36bdda/RelWithDebInfo-Darwin/appleclang/Interpreter

[bobsummerwill]

Hey @adetante,
Sorry to hear that.
Did you build the binary yourself? Or install from Homebrew?

[adetante]

I tried both, installing from homebrew and building from webthree-umbrella

[bobsummerwill]

And the exact same result for both?

[adetante]

Yes, same result: segfault when compiling with --bin a simple contract.

I'll try to run with gdb to see if I have more infos about the error.

[VoR0220]

@adetante do you get a seg fault when running --ast or --gas?

[adetante]

@VoR0220 yes, seg fault with --ast, --gas or --bin

[adetante]

Here is the trace when running with --gas with lldb :

* thread #1: tid = 0x4d4730, 0x00000001002e1241 libsolidity.dylib`dev::solidity::CompilerContext::CompilerContext(dev::solidity::CompilerContext&&) [inlined] std::__1::__tree<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::__map_value_compare<dev::solidity::Declaration const*, std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::less<dev::solidity::Declaration const*>, true>, std::__1::allocator<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem> > >::__tree(std::__1::__tree<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::__map_value_compare<dev::solidity::Declaration const*, std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::less<dev::solidity::Declaration const*>, true>, std::__1::allocator<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem> > >&&) + 45 at __tree:1302, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00000001002e1241 libsolidity.dylib`dev::solidity::CompilerContext::CompilerContext(dev::solidity::CompilerContext&&) [inlined] std::__1::__tree<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::__map_value_compare<dev::solidity::Declaration const*, std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::less<dev::solidity::Declaration const*>, true>, std::__1::allocator<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem> > >::__tree(std::__1::__tree<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::__map_value_compare<dev::solidity::Declaration const*, std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem>, std::__1::less<dev::solidity::Declaration const*>, true>, std::__1::allocator<std::__1::__value_type<dev::solidity::Declaration const*, dev::eth::AssemblyItem> > >&&) + 45 at __tree:1302
   1299         __end_node()->__left_->__parent_ = static_cast<__node_base_pointer>(__end_node());
   1300         __t.__begin_node() = __t.__end_node();
   1301         __t.__end_node()->__left_ = nullptr;
-> 1302         __t.size() = 0;
   1303     }
   1304 }
   1305

[VoR0220]

yep...same problem I've been running into. May want to close this in favor of https://github.com/ethereum/solidity/issues/502 ....though if my findings are correct, the problem should go away on its own soon as we move away from the Solidity execution framework.

[bobsummerwill]

what do you mean exactly with "as we move away from the Solidity execution framework.", please, @VoR0220?

[VoR0220]

talked with @chriseth and if the problem truly is the SolidityExecutionFramework....then we're moving away from it...don't know the full details quite yet. :)

[elenadimitrova]

+1 exact same issue running solc Version: 0.3.2-9e36bdda/Release-Darwin/appleclang/Interpreter

[boestin]

Same here, thinking about changing to a windows box

[VoR0220]

go to an ubuntu box before you go to a windows box....

[VoR0220]

What I want to know is how is the Jenkins bot still passing the seg faults when it runs the soltests...thats the primary failure is in the gas meter tests.

[adetante]

@boestin as a workaround, I'm using solc in a Docker container and it's OK for me. Look at this image : https://hub.docker.com/r/kunstmaan/ethereum-eth/

[boestin]

@adetante
Not quite familiar with Docker yet. So I've checked it out a bit but havent installed it yet.
Since I am - not a true - developer: I am wondering if I could install your supposed container inside my mac, without having to " touch" the existing code.

Furthermore, does the container has it's own blockchain? Or is it simple the solc compiler.

Thanks

[boestin]

So, on Windows I have another issue.. Getting tired of it

[adetante]

@boestin to run the container on a Mac, you need :

1. To install Docker (docker-machine is recommanded) : https://docs.docker.com/machine/install-machine/
2. To pull an image containg cpp-ethereum binaries

This image contains binaries from cpp-ethereum, including the solc compiler.
If needed, you can contact me on gitter for more informations.

[VoR0220]

@adetante I'm very intrigued...where might I find said image?

[boestin]

@VoR0220

1. OSX install https://www.docker.com/products/docker-toolbox
2. then when finished, check if the daemon is running: docker-machine ls
3. If not: eval "$(docker-machine env default)"
4. Pull the image @adetante is talking about: docker pull kunstmaan/ethereum-eth

[raineorshine]

@boestin Thank you, I was able to get Docker set up and the image pulled. What do I do after step 4? I have never used Docker before. I still have my local solc that segfaults.

[tymat]

https://github.com/ethereum/solidity/issues/571

[VoR0220]

So we have a temporary work around it would seem. I would like all who are experiencing this error to try this out. Try rebuilding through the webthree umbrella, but try this.

./webthree-helpers/scripts/ethbuild.sh --no-git --clean-build --project solidity -DETHASHCL=0 -DEVMJIT=0 --cores 10

adjust your cores as necessary. This is fixing the bug for the meantime on my machine. Let me know what it does for you.

[bobsummerwill]

So from this, and another thread, @VoR0220, it looks like "the thing" is inside EVMJIT? @chfast.

[bobsummerwill]

Closed as dupe of "The Heisenbug" - https://github.com/ethereum/webthree-umbrella/issues/565. We can reopen if we later find there is anything unique here.