segfault when broadcasting a transaction about steem

[theoreticalbts]

Reopening because this issue may exist if other API's provide callbacks, we'll need to review each one. Also there should be a way in the framework, so creating an API which provides a callback involves a minimum amount of boilerplate.

[bytemaster]

Can we get confirmation that those other issues #10 #11, and #26 occurred after broadcasting a transaction and then disconnecting before confirmation?

The OP was close to understanding the root cause. The network_broadcast_api is always created via make_shared() so shared_from_this() should always be valid. The problem is the constructor of registered a callback with the chain database that contained a raw pointer. When a new block was applied, this raw pointer was dereferenced to call on_applied_block(). shared_from_this() returned null at this point because the raw pointer was invalid.

The fix is to pass a weak pointer into the callback, but this means the callback cannot be registered in the constructor because shared_from_this() is not valid in the constructor.

[theoreticalbts]

I think it may be a race, the signal handler should be deregistered when the _applied_block_connection object is deleted in the API object's destructor. So usually you'd avoid calling with invalid this, because the thing which causes the calls (existing as a signal handler) stops happening around the time this becomes invalid (which happens because this was destroyed, which would have caused the signal handler to be deregistered when the connection member object was destroyed).

But if the signal handler execution's already started, it can't be cancelled in flight, leading to problems if it expects this to be valid for the duration of the call. So @bytemaster's patch looks like the correct solution -- using a weak_ptr which you lock() and then test the result instead of using this as a raw pointer.

[wackou]

it still crashes... However, it looks like some progress has been made. When entering on_applied_block, capture_this is now valid, but it crashes a bit later while instantiating the async task and copying (?) the lambda. I have to admit that at this point, what is actually happening eludes me, so here are some screenshots of the debugger (sorry for the small size, I'm travelling and only have my laptop)

frame 5, up till here all good

frame 4, 3, 2: creating the async task

frame 1: for some reason here inside the lambda, capture_this is null again... btw, if we have capture_this, is it necessary to also capture this in the declaration of the lambda?

let me know if I can do anything else to help

[bytemaster]

I think it might have something to do with the iterator containing the lambda being erased. I opted for a slow memory leak rather than a crash. See if the latest commits fix it. If so then we can dig deeper.

[theoreticalbts]

In refactoring the original patch I found that database_api suffers from the same bug. Just pushed 9936892 to develop which should fix database_api at least.

[wackou]

still crashes in the same place...

[roadscape]

Can we get confirmation that those other issues #10 #11, and #26 occurred after broadcasting a transaction and then disconnecting before confirmation?

None of those issues are related to broadcasting a transaction --- the node on which those occur only serves as an RPC API, and the only calls I make are reading the state.

[wackou]

I was wondering whether it was a problem with the OS or the compiler/libc++, so I tried compiling on linux using clang as compiler to see whether it would crash (debian jessie, clang-3.5, boost 1.58.0). It turns out that it works perfectly there. So it would seem that the issue is either OSX-specific or comes from a difference between clang/libc++ 3.5.0 on linux and clang/libc++ (Apple LLVM version 7.3.0) on OSX.

[svk31]

Bumping since this is still an issue for me, and a quite annoying one since it makes it impossible to use either the cli_wallet or a local websocket connection when developing for steemit.com. As soon as I make a transaction of any kind, steemd segfaults and I then need to do a full replay.

Boost version: 1.60.0
OPENSSL_VERSION = 1.0.2h

[wackou]

I put a bounty of 400 STEEM on this bug, if anyone is interested... (I can also pay 800 SD, which is what 400 STEEM was worth at the time the bounty was set). See https://steemit.com/steem/@wackou/btstools-development-bounties

[theoreticalbts]

This is likely duplicate of #281. I've identified the root cause and a patch will be pushed soon.

[sneak]

@theoreticalbts could you please verify that #281 fixes this and close if so?

[wackou]

v0.14.2 still exhibits this issue...

[svk31]

I just compiled and synced from the develop branch and it also still exhibits this issue. Definitely not fixed.

[theoreticalbts]

@sneak I cannot verify that this is fixed because I cannot reproduce it. It only seems to happen on some machines, and it has never happened on any machine I have used.

[theoreticalbts]

The network_broadcast API will be deprecated and replaced by a stateless network_broadcast2 API, as discussed in #490. Closing this ticket as wontfix.

[bytemaster]

For backward compatibility and to facilitate smooth transition to new stateless API we still need to fix this.