ethereum/cpp-ethereum — pull request #17 by subtly (2014-02-03 02:44:38+00:00)
Title: check if _orig is null so place() initializes value

I looked for isEmpty throughout the codebase and found that isNull() is being used elsewhere alongside isEmpty(). So I've added that here as well. Some comments and questions below.

Gav (from pull #15):
> Neither of these patches resolve the issue.
>
> The return value of isEmpty() is true only for null, the empty string & the
> empty list: An integer is not "empty".
>
> All nodes in the trie (which is to say the RLP _orig within mergeAt() &
> place() ) must be either lists (2 or 17 items) or the empty string. They
> must not be integers or strings.

Agreed -- an integer is not empty. However isEmpty() is returning false if it's null; that is to say that, "null" is not empty. I think this maybe a bug however "fixing" it could break things.

bool isEmpty() const { return !isNull() && (m_data[0] == 0x40 || m_data[0] == 0x80); }

> If that assertion is firing, then the bug lies elsewhere. Dumping the
> database, finding what the offending RLP is exactly (an integer or a
> string?) and determining when & where the rogue node was inserted would be
> a good start.

This is occurs within the first call to commitToMine() when mining the genesis block, and as a part of testing, I also wiped both databases. What's the easiest way to inspect the database, and what should the full-node and peer-node databases look like when the genesis block hasn't yet been mined?

Can anyone reproduce this?
To reproduce:
mv ~/.ethereum ~/.ethereum-previous
./eth -m off -u 192.168.1.10 -x 256 # start single instance

# create mining peer
./eth -o peer -l 30301 -u 192.168.1.10 -p 30303 -d /tmp/eth 192.168.1.10