graphprotocol
[Bug] String corruption bug in with specific patterns
Bug report
Summary
Address.fromString() fails for certain valid Ethereum addresses, corrupting the input string to an empty string before processing.
Environment
@graphprotocol/graph-cli: 0.97.1@graphprotocol/graph-ts: 0.37.0- Local graph-node for debugging
Bug Description
Working Address
Address.fromString("0xfff9976782d46cc05630d1f6ebab18b2324d6b14"); // ✅ Works
Failing Address
Address.fromString("0x3b44b2a187a7b3824131f8db5a74194d0a42fc15");
// ❌ Error: Failed to convert string to Address/H160: '': Invalid input length
Key observation: The error message shows an empty string '', indicating the input is being corrupted to an empty string before Address parsing.
Debugging Evidence
1. String Corruption
When logging the problematic strings, they show memory corruption:
log.info("Address: {}", ["0x3b44b2a187a7b3824131f8db5a74194d0a42fc15"]);
log.info("Length: {}", ["0x3b44b2a187a7b3824131f8db5a74194d0a42fc15".length.toString()]);
Output:
Address:
Length: \u{000c}௴\u{001c}\u{0001}\u{000c}
The string content becomes empty and the length shows garbage characters with control bytes.
2. Position Independence
The bug persists regardless of:
- Variable vs constant declaration
- Function position
- Direct literal usage
Additional Failing Addresses
0xe44fd7fcb2b1581822d0c862b68222998a0c299a(shows same corruption pattern)
Reproduction
- Create a subgraph mapping
- Use
Address.fromString()with the failing address - Observe the error and string corruption in logs
Relevant log output
Jun 27 16:22:13.036 ERRO Handler skipped due to execution failure, transaction: 0x7d83…1a26, address: 0x3b44…fc15, signature: PairCreated(indexed address,indexed address,address,uint256), error: transaction 7d832bc58b962a72c8fa365696c7e461196d104abae6d62684aa27b7d5191a26: error while executing at wasm backtrace: 0: 0x236b - <unknown>!src/factory/handlePairCreated: Failed to convert string to Address/H160: '': Invalid input length, handler: handlePairCreated, runner_index: 9, sgd: 24, subgraph_id: QmXagmQPr9e1VVyVMkcYpHNcXYXorwSrBXwQueHLhWc9cn, component: SubgraphInstanceManager
IPFS hash
No response
Subgraph name or link to explorer
No response
Some information to help us out
- [x] Tick this box if this bug is caused by a regression found in the latest release.
- [x] Tick this box if this bug is specific to the hosted service.
- [x] I have searched the issue tracker to make sure this issue is not a duplicate.
OS information
macOS
Hi @logan272. I tried to reproduce this bug in https://github.com/graphprotocol/graph-node/pull/6140 but with no success. Can you review the reproduction test case or even adjust it so that it shows the failure in action?
