- Jul 16, 2016
-
-
Péter Szilágyi authored
-
- Jul 15, 2016
-
-
Péter Szilágyi authored
-
Péter Szilágyi authored
-
Péter Szilágyi authored
-
Péter Szilágyi authored
-
- Jul 11, 2016
-
-
Péter Szilágyi authored
-
Zsolt Felföldi authored
-
- Jul 04, 2016
-
-
Péter Szilágyi authored
-
- Jun 30, 2016
-
-
Péter Szilágyi authored
-
- Jun 16, 2016
-
-
Zsolt Felföldi authored
-
- Jun 13, 2016
-
-
Péter Szilágyi authored
-
Jeffrey Wilcke authored
Consensus rules dictate that objects can only be removed during the finalisation of the transaction (i.e. after all calls have finished). Thus calling a suicided contract twice from the same transaction: A->B(S)->ret(A)->B(S) results in 2 suicides. Calling the suicided object twice from two transactions: A->B(S), A->B, results in only one suicide and a call to an empty object. Our current debug tracing functionality replays all transaction that were executed prior to the targetted transaction in order to provide the user with an accurate trace. As a side effect to calling StateDB.IntermediateRoot it also deletes any suicides objects. Our tracing code never calls this function because it isn't interested in the intermediate root. Becasue of this it caused a bug in the tracing code where transactions that were send to priviously deleted objects resulted in two suicides rather than one suicide and a call to an empty object. Fixes #2542
-
- Jun 07, 2016
-
-
Zsolt Felföldi authored
-
- Jun 06, 2016
-
-
Péter Szilágyi authored
-
Péter Szilágyi authored
-
- Jun 02, 2016
-
-
Péter Szilágyi authored
-
- May 30, 2016
-
-
Péter Szilágyi authored
-
- May 27, 2016
-
-
Péter Szilágyi authored
-
- May 25, 2016
-
-
Felix Lange authored
We used to have reporting of bad blocks, but it was disabled before the Frontier release. We need it back because users are usually unable to provide the full RLP data of a bad block when it occurs. A shortcoming of this particular implementation is that the origin peer is not tracked for blocks received during eth/63 sync. No origin peer info is still better than no report at all though.
-
- May 24, 2016
-
-
Rémy Roy authored
-
- May 20, 2016
-
-
Bas van Kervel authored
-
Péter Szilágyi authored
-
Péter Szilágyi authored
-
- May 18, 2016
-
-
Jeffrey Wilcke authored
Sign transaction returned the unsigned transaction rather than the signed one.
-
- May 17, 2016
-
-
Bas van Kervel authored
-
Péter Szilágyi authored
-
Péter Szilágyi authored
-
Péter Szilágyi authored
-
- May 13, 2016
-
-
Péter Szilágyi authored
-
- May 09, 2016
-
-
Felix Lange authored
Shutting down geth prints hundreds of annoying error messages in some cases. The errors appear because the Stop method of eth.ProtocolManager, miner.Miner and core.TxPool is asynchronous. Left over peer sessions generate events which are processed after Stop even though the database has already been closed. The fix is to make Stop synchronous using sync.WaitGroup. For eth.ProtocolManager, in order to make use of WaitGroup safe, we need a way to stop new peer sessions from being added while waiting on the WaitGroup. The eth protocol Run function now selects on a signaling channel and adds to the WaitGroup only if ProtocolManager is not shutting down. For miner.worker and core.TxPool the number of goroutines is static, WaitGroup can be used in the usual way without additional synchronisation.
-
Jeffrey Wilcke authored
Fixes #2525
-
- May 02, 2016
-
-
Péter Szilágyi authored
-
- Apr 28, 2016
-
-
Ales Katona authored
-
Bas van Kervel authored
-
- Apr 27, 2016
-
-
Péter Szilágyi authored
-
- Apr 15, 2016
-
-
Felix Lange authored
Context keys must have a unique type in order to prevent any unintented clashes. The code used int(1) as key. Fix it by implementing the pattern recommended by package context.
-
Felix Lange authored
-
Felix Lange authored
This fixes a few uses of unkeyed Body literals which go vet was complaining about.
-
Felix Lange authored
-
- Apr 14, 2016
-
-
Péter Szilágyi authored
-