Truffle: Not able to debug a contract created by another contract that subsequently causes the transaction to revert

[gilesbradshaw]

• [x] I've asked for help in the Truffle Gitter before filing this issue.

---

Issue

I'm trying to debug a transaction - I've got all the contracts linked to source code except one..

````
Addresses affected:
0xe78A0F7E598Cc8b0Bb87894B0F60dD2a88d6a8Ab - ProcessRegistry
0x7C728214be9A0049e6a86f2137ec61030D0AA964 - BindingAccessControl
0x4bf749ec68270027C5910220CEAB30Cc284c7BA2 - TaskRoleContract_Contract
0x3Cd8e615aF0774eE283329454962abbD4F2b427A - Order_To_Cash_Contract
0xD833215cBcc3f914bD1C9ece3EE7BF8B14f841bb - Goods_Shipement_Factory
0x5f8e26fAcC23FA4cbd87b8d9Dbbd33D5047abDE1 - Order_To_Cash_worklist
0x8C6AAd0C92a48112aAa0e6e8F98A160120f17059(UNKNOWN)

````

It turns out the one I can't link has a null binary - but it is in this one where the error is occurring.

All the others have been deployed by web3 - the one with the null binary (0x) has been created by another contract:

Goods_Shipement_Contract newContract = new Goods_Shipement_Contract(parent, worklist, processRegistry);

is there any way such contracts can be linked to their source code so they can be debugged?

For reference the null binary gets returned here:
packages/truffle-debugger/lib/session/sagas/index.js

let binaries = yield* web3.obtainBinaries(addresses, blockNumber);

Steps to Reproduce

I can provide my source files if you'd like.. + ganache-cli data

Environment

• Operating System: ubuntu
• Ethereum client: ganache-cli
• Truffle version Truffle v5.0.17 (core: 5.0.16)
• node version Node v11.14.0
• npm version 6.7.0

[gilesbradshaw]

Looking at this a little bit more I've debugged a successful transaction where a new contract is created by the transaction:

Order_To_Cash_Contract newContract = new Order_To_Cash_Contract(parent, worklist, processRegistry);

so in this instance I DO get the binary for the created contract and I can debug it

````
Addresses affected::
0xeea2Fc1D255Fd28aA15c6c2324Ad40B03267f9c5 - Order_To_Cash_Factory
0x7E15EC1Be05556db16007E4d6178fD03dbAd7F5A - Order_To_Cash_Contract
0xe97DbD7116D168190F8A6E7beB1092c103c53a12 - Order_To_Cash_worklist
0x2D8BE6BF0baA74e0A907016679CaE9190e80dD0A - ProcessRegistry

````

I'm guessing that because the transaction is reverted - the blockchain doesn;t store the bytecode on the contract that was created? And that's why I get a 0x?

So it's not possible to debug a created contract which causes the transaction in which it was created?

Is there any way round this?

[haltman-at]

So, I'm a little confused what the situation is here, exactly. Let me try to get this straight.

So, you ran a transaction that attempted to create a contract, but the creation was reverted. Yes? And then you tried to debug... some transaction. I'm a little unclear here -- was the transaction that you were trying to debug the same transaction that attempted to create the contract? Or was it a different transaction that attempted to call into that contract?

I also don't know what you mean when you say you "can't debug". What precisely is happening that you don't think should be happening? You've displayed the "UNKNOWN" message, but what actually goes wrong during debugging? Do you encounter an error message? Is that part of the transaction simply skipped over? I'm not very clear on just what the undesired behavior is here.

Thanks!

[haltman-at]

Oh, wait -- I have a guess as to what's going on. Is it the case that:

1. This transaction creates a contract, then
2. Calls into that contract, but then
3. This transaction (or at least a part of it containing (1) and (2)) reverts?

Is that's what's going on? Because that would explain what you're seeing.

And even if that's not what's going on, well, now that I've thought of it I realize that would cause a problem whether it's what's going on here or not! So, thanks for bringing that up. If that is the issue, I have an idea how I could fix it...

[gilesbradshaw]

@haltman-at yes - apologies for the confusing posts - it only dawned on me what was happening half way through.

I'm trying to debug a reverted transaction during which pre existing contract A created contract B and which contract B caused to revert due to some unknown bug (which I am trying to discover).

The problem is that because the transaction reverted the debugger sees contract B's binary as null (0x) therefore although I have provided the source code for contract B the debugger can't tie up the source code to it's binary - therefore I can't step into contract B to find out why it reverted the transaction.

I hope that makes sense! I know it's a bit convoluted but these things are :P

[haltman-at]

Yes, I think I see. But to be clear, the transaction then calls into contract B after creating it, and it's not the creation itself that caused the revert? That step is important. :)

Like, if that is what's going on -- as I suspect -- then, OK, I'm going to have to write some more code to keep track of contract code, because I don't have code to handle that case. (I guess I'll have to do that regardless, anyway, now that I've realized the issue!) In that case the issue is due to us just failing to keep track of certain information.

Whereas if it's the creation that's causing the reversion, then I can't think of any reason you'd get the above message, and I have to go bug-hunting.

I'm assuming probably though it's the first case and I have my work cut out for me...

Thanks again!

[gilesbradshaw]

Hi yes that's right - contract A successfully creates contract B but calls into it in the same transaction and contract B then causes the transaction to revert.

[haltman-at]

OK, great! In that case I'm pretty sure I know what I need to do to fix this.

[haltman-at]

OK, I've just put up PR #2052 which should fix this. Note that you'll still get that (UNKNOWN) display on startup, but you can ignore that; once this is merged the call itself should work fine.

[gilesbradshaw]

star player!

[haltman-at]

Fix has been released, closing this.