Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Disarm fails when instrumented code fails to compile

See original GitHub issue

If you have a contract that compiles before being instrumented but fails to compile after being instrumented, scribble will successfully arm the contract but fail to disarm it. This can leave a bit of a mess of armed files to clean up before you can fix or diagnose the issue.



// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IShadower {
    function shadowed(uint256 a) external;
    function shadowed(uint256 a, uint256 b) external;

/// #invariant {:msg "I0"} 0 == 0;
contract Scribbled {
    function entry() external {
solc Shadowed.sol


scribble Shadowed.sol --output-mode files --arm

Succeeds, but leaves an instrumented Shadowed.sol that fails to compile.

In this case, it is because the function pointer passed to the _callsite_ method cannot discern between the two versions of IShadower.shadowed(). As far as I know, this is a limitation of solidity rather than a scribble bug, but used here as an example.

scribble Shadowed.sol --output-mode files --disarm

Because the newly instrumented Shadowed.sol won’t compile, this fails and leaves armed files that must be sorted out manually or reverted to a previous commit.

Feature Request

  • If it’s not necessary to compile the armed contracts before disarming, that seems like an easy fix. Maybe this could be behind a --disarm --force flag.
  • Attempt to compile the armed contracts and revert instrumenting if they fail to compile.

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:8

github_iconTop GitHub Comments

blitz-1306commented, Dec 1, 2021


What is the reason for compiling the armed contracts before disarming?

I would say major reason is (and always been a big pain) an import resolution. We can resolve imports by relying on Solc callbacks while compiling files (unless breadcrumbs idea, suggested by @cd1m0). There are a lot of effort done to make that work:

JoranHonigcommented, Nov 18, 2021

@cd1m0 maybe we can include a series of comments on top of instrumented files indicating that they’re auto generated and that they shouldn’t be edited directly (only after it has been disarmed).

Read more comments on GitHub >

github_iconTop Results From Across the Web

Java 8 code instrumented by Clover fails to compile
Compilation of Java 8 code instrumented by Clover fails when a lambda expression is passed as an argument of a generic method.
Read more >
Receiving "Warning: unable to instrument ..." during compilation
This message means that this source file will not be instrumented. The cause could be any of: A construct in your code which...
Read more >
Intellij - 15 NotNull Instrumentation errors for code that has ...
I ran into the same issue after upgrading from 14 to 15. For me the fix was to go into settings -> compiler...
Read more >
Resolving App Rejections for GCC and LLVM Instrumentation
QA1964: describes how to resolve an App Store rejection for an app containing instrumentation.
Read more >
AFLplusplus/ at stable - instrumentation - GitHub
Compiling programs still fail. afl-clang-lto is still work in progress. Known issues: Anything that llvm 11+ cannot compile, afl-clang ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found