Problem with the millionaire problem

Hi everybody,
I followed the steps in the creation of the millionaire problem, but then my dapp will get stuck computing the richest millionaire.

I am on MacOS, what should I try?

Thank you,
Fadi

Hi @Fadi,

I’m tagging @adi, as he’s the one that wrote the millionaire problem, and may be in a better position to help out. Regardless, we need to know more details about the problem you are facing. Please include any debug information that you see where it errors out, either in the browser console, or output from the terminals. Somewhere it’s throwing an error, and we need to see that to be able to troubleshoot it with you.

Victor

Thank you for your reply.

This is the only error I have

This is the output in the enigma-docker-network tab when I click on “Check richest”

contract_1_39e1a64dc8b2 | eth_call
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_getBlockByNumber
contract_1_39e1a64dc8b2 | eth_getBlockByNumber
contract_1_39e1a64dc8b2 | eth_getBalance
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_getBlockByNumber
contract_1_39e1a64dc8b2 | net_version
contract_1_39e1a64dc8b2 | eth_sendTransaction
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_getBlockByNumber
contract_1_39e1a64dc8b2 | 
contract_1_39e1a64dc8b2 |   Transaction: 0x812548ecd744f7051ed3adc68a2614e38ac09f34ac1a2ba05b11c15f41ac4bc3
contract_1_39e1a64dc8b2 |   Gas usage: 228499
contract_1_39e1a64dc8b2 |   Block Number: 21
contract_1_39e1a64dc8b2 |   Block Time: Tue Dec 04 2018 12:14:32 GMT+0000 (Coordinated Universal Time)
contract_1_39e1a64dc8b2 | 
contract_1_39e1a64dc8b2 | eth_getTransactionReceipt
contract_1_39e1a64dc8b2 | net_version
contract_1_39e1a64dc8b2 | eth_call
contract_1_39e1a64dc8b2 | eth_blockNumber
contract_1_39e1a64dc8b2 | eth_getBlockByNumber
contract_1_39e1a64dc8b2 | eth_getBlockByNumber
contract_1_39e1a64dc8b2 | eth_getBalance
contract_1_39e1a64dc8b2 | net_version
contract_1_39e1a64dc8b2 | eth_call
contract_1_39e1a64dc8b2 | net_version
contract_1_39e1a64dc8b2 | eth_call
contract_1_39e1a64dc8b2 | net_version
contract_1_39e1a64dc8b2 | eth_call
contract_1_39e1a64dc8b2 | eth_blockNumber

Again, thank you.

Thank you @Fadi,
the problem is with this line:
e7c36b44d7ed9385587972ced90ab115a7f3fd6b
where it’s missing the address of the other container running core. The last part should read instead something like: Connecting via zmq to: tcp://172.23.0.3:5552. And because no IP address is specified correctly, the program throws an error, of which you see the back trace right after that line.

So, I understand what the problem is, but I am not quite sure why it happens if this runs inside a docker container that should run consistently across operating systems. I am investigating, and I will come back with a solution.

Hold on tight :slight_smile:

you’re too kind, thanks!

Hi @Fadi,

I have been looking into this problem, but I cannot replicate it in two different machines running different OSes (Mac & Linux), where the latest version of all the repos involved runs just fine for me, so I believe it’s something specific to your setup where there must be a difference on some version of some piece of software on your host that causes this error.

Here’s the context:

  • When the docker network launches, it launches at least 3 different containers named contract, core and surface that form a network and talk to each other.

Here’s the problem:

  • Let’s focus on the surface container which is the one giving trouble. This is the one that interfaces both with the enclave (core) and the local Ethereum network (contract) from which it gets the secret computations to run, and passes them to the enclave, and gets the results and passes them back to the network. When surface launches, it doesn’t know where core is (since it’s a different/independent container), and has to “query” the local network to discover it and communicate with it via the ZMQ protocol that you see erring out above. This is where a small shell script kicks in, that executes when the container boots up, finds the IP and passes it to surface upon launch to communicate with core. Specifically, this is the script that must be failing (Lines 4 & 23 are the relevant ones): https://github.com/enigmampc/enigma-docker-network/blob/master/surface/wait_launch.bash

Here’s some troubleshooting:

  • First of all launch the network as before and let it fail. You should have 3 containers up, where you are seeing the error that you are reporting
  • On a separate/new terminal in the same folder where you have docker-enigma-network execute the following to get inside the surface container that is failing:
    docker-compose exec surface /bin/bash
    which basically is requesting to open a shell session inside the desired container
  • Now run the following commands and post the output of what you see on this thread:
    ps -aef (I want to see how surface is running, and whether it got the right params at launch)
    echo $HOSTNAME (I want to verify that it has its own name configured correctly)
    getent hosts (I want to see that the network is configured correctly locally)
    getent hosts enigma_core_1 (I want to see if it can “see” the other container)

This is what the output to the above 4 commands looks like in my environment (and what I would expect):

Let me know what you find :slight_smile:

So, I followed everything you wrote step by step. This is what I obtained:
image

Last command has a different output than yours.

Thank you for your time :slight_smile:

Just a note @victor, when I encounter this problem, neither contract nor core containers launch (or they launch and immediately close… too fast for me to see)

*Also, I ran the instructions as you asked and I got the exact same output as @Fadi

I tried running the following: docker-compose exec core /bin/bash

And got back this response:
root@enigma_core_1:~# core_1_46e7e72b38f7 | aesm_service[162]: SGX Service unavailable

core_1_46e7e72b38f7 | aesm_service[162]: Fail to start service.

Thank you both @pmp & @Fadi for your prompt answers. I’m interested in @pmp’s hint that the other containers may not be running. Two more requests to troubleshoot this:

  • Run docker network inspect enigma_net from the same folder (not inside the container, but the host, the same folder from where you run launch.bash). This should tell us what containers are running and the network setup for these (my sample output below).
  • Bring the network down (if you had it up) with docker-compose down and the launch then docker network all in one terminal: ./launch.bash -s (without the -t, and copy/paste the output here). It’s going to be long, but I’m looking for more error messages that the other containers may be putting out that you can’t see right now because the terminals open and close too fast.

Sample output from docker network inspect enigma_net:

Should just @pmp do this, or both of us?

just so I dont spam the conversation

Either one of you, whoever gets to it first, because my understanding is that both of you are experiencing the same problem, so any input from either one of you would be very helpful :slight_smile:

Just ran docker network inspect enigma_net. Mostly the same output as you…except my docker-compose is 1.23.0. I updated and I’m seeing three terminals now.

these are the outputs:
when i run docker network inspect enigma_neti obtain:

…Darn, I was too eager on my last post. The same problems persist, except now I can see all the terminals. This is the output of enigma_core:

Then I run the other commands and I obtain:

the rest of the output is seeable here:

Thank you both. I see one of the problems here, on the network structure screenshot:

82d155b0f3731c1ebcb4c2f7b21c2d5b4650b416

They look mostly similar, but the fact that the name of the container has the 2a272b585a16 (which is presumably the container ID) attached to it, throws off the network configuration. Compare it with my screenshot above (where the name is just enigma_core_1, and that’s the most significant difference. It must be a difference in docker or docker-compose versions. Can both of you confirm what versions are you running? Run docker --version and docker-compose --version

@Fadi, the rest of the output from launching the network looks fine, thanks for including that.

@pmp, we can look later at the Rust compilation error that you include above, I cannot replicate that either, but I’ll treat that as a secondary error for the time being…

docker version:

I was able to get a working testnet after I installed the newest docker-compose and then removed and reinstalled the git repo. Thanks so much for your help @victor!

2 Likes