-
Notifications
You must be signed in to change notification settings - Fork 1.7k
eth_calls to some addresses seem to never return, they just hang indefinitely #8311
Comments
can you make sure you are on the latest parity version? |
latest nightly, stable? i tried with 1.8.7, 1.10 beta(v1.10.0-beta-0a9d41e-20180320), and a nightly from a few days ago thanks for looking into this |
I've experienced the same problem. It's not actually any particular address, but it can seem to be because, if you are executing a sequence of When this happens, parity spins at 100% CPU load. Tracing the process reveals many threads awaiting a semaphore lock (I'm not sure if that's just normal for parity's architecture, but I figured I'd mention it.) I think what's actually happening is that the backend handler for |
I haven't looked into this, but the contract at |
figured it might be related as it was really close to the start of the attack (didn't think to search for it though :P ) interestingly, geth returns in a timely fashion, i wonder if they are doing something specific about it... |
i have also have it happen consistently for the following addresses
Tried to look into what @tsutsu mentioned and my findings are:
/edit
|
a brand new synced light |
does not seem related to docker, ran on one of the server parity installed through snaps
|
same parity installation as above but started with |
@tzapu Interesting, since light clients are just querying remote nodes for information. If the remote node returned quickly then it might be something in the RPC server itself. |
@tzapu Can you pass |
oh man, somehow i missed this.
summary: |
Possibly related to #6840 |
actual
making and
eth_call
forname()
orsymbol()
on address0x6a0a0fc761c612c340a0e98d33b37a75e5268472
just hangs forever.one test ran for 8 hours not returning anything. trying the same curl in geth seems instant.
expected behavior
to return something, be it the result or an error... anything
steps to reproduce
thank you very much
/edit: tested various configurations: default, archive+tracing, no-ancient-blocks
The text was updated successfully, but these errors were encountered: