Gulden: key.cpp:308: void ECC_Start(): Assertion `secp256k1_context_sign == NULL' failed.

[GeertJohan]

Steps to reproduce

1. Run the Gulden wallet, enter recovery phrase, let it sync the blockchain. After sync it shows balance in the recovery phrase imported wallet.
2. Close the Gulden wallet and wait until it is cleanly shut down. No errors occur here (at least not visible in stdout/stderr or debug.log.
3. Start the Gulden wallet again. See it crash after a few seconds of the loading screen. (Crashes just a few milliseconds after the loading screen says "Done loading").

Expected behaviour

A working wallet

Actual behaviour

$ ./Gulden-2.4.5-x64.AppImage                                  ⏎
Gulden: key.cpp:308: void ECC_Start(): Assertion `secp256k1_context_sign == NULL' failed.
[1]    2970248 abort (core dumped)  ./Gulden-2.4.5-x64.AppImage

What version of Gulden are you using?

I've only used the latest release (2.4.5), which created the ~/.Gulden data directory.

Machine specs:

• OS: Ubuntu 20.04.2 LTS, Linux 5.4.0-80-generic
• CPU: x64
• RAM: 32G
• Disk size: 1TB, enough space free.
• Disk Type (HD/SDD): NVMe SSD

Any extra information that might be useful in the debugging process.

https://pastebin.com/kez3mkJg

I suspect maybe this has to do with a missing library in the AppImage for linux users? I did install libsecp256k1-0 on my system but I'm not sure if that is the correct library and I don't know if the binary from an AppImage even picks up system-installed libs.

[GeertJohan]

I have built the Gulden binary from source and it behaves the same way. So it doesn't seem to be caused by AppImage behavior.

[GeertJohan]

When I start Gulden with the -disableui flag, it works sortoff ok. I have to wait a long time before doing any interaction with the console UI (otherwise it crashes without an error). During that time it has high CPU usage so it's probably still loading data. When CPU usage goes down, I can interact with my wallet through console commands.

[mjmacleod]

How sure are you that the program is actually 100% closed at the point of restarting it? This specific error message usually occurs when two copies of the program are run at the same time.

Assuming its not that and you are able to reliably reproduce this please grab a stack trace then we can see what is going on from that.

Instructions to grab a stack trace here: https://github.com/Gulden/gulden-official/wiki/Stack-trace

[GeertJohan]

It happens after a complete reboot, I'm sure it's not running already.

Is the proper debug info already available in build/src/qt after building? This is what I got: https://gist.github.com/GeertJohan/6ffe3ed9d6849f800a3dc9717bc4aa84

Note that I have the same error when using the AppImage. But I don't know how to gdb the AppImage.

[mjmacleod]

Any settings in your Gulden.conf file or is this a vanilla install?

[GeertJohan]

Vanilla install but the problem only starts the second time the app is started. So the first time the application is ran and it creates the .Gulden folder, it works fine. I can reproduce this by mv .Gulden .Gulden.bak and running the application, walking through the startup wizard and closing the application. Wait until it's stopped, then start again and it crashes. There is no difference in behaviour between creating a new wallet or importing an existing one with recovery phrase.

~
$ mv .Gulden .Gulden.baktoprove
     ✔

~
$ cd src/github.com/Gulden/gulden-official/build/src/qt
     ✔

~/s/g/G/g/b/s/qt :master ◼
$ ./Gulden
     ✔  35s

~/s/g/G/g/b/s/qt :master ◼
$ ps -e | grep Gulden
     ✘  1

~/s/g/G/g/b/s/qt :master ◼
$ ./Gulden
Gulden: ../../src/key.cpp:308: void ECC_Start(): Assertion `secp256k1_context_sign == NULL' failed.
[1]    95962 abort (core dumped)  ./Gulden
     ✘  134

[GeertJohan]

I just noticed that Gulden.conf is in ~/.config/Gulden so I removed that as well together with ~/.Gulden. Same result.

[mjmacleod]

Does the debug.log have any content at that point? It might be useful to see.

[GeertJohan]

debug.log after running twice from fresh start (no .config/Gulden and no .Gulden), second time crashes (crash is not visible in log?): https://gist.github.com/GeertJohan/cd3f0861f56002112ac1ba4bc9dd5fda

[mjmacleod]

Assertion should only occur if ECC_Start is called a second time without ECC_Stop being called first.

ECC_Start is only called from 3 places in the code:

• The first of these is only called if running in regtest or testnet mode, so can be ruled out
• The second is only called if -genkeypair is passed (and terminates the app immediately as well); so this too can be ruled out
• The third is inside AppInitSanityChecks() which is only called once by the app on init, and where the stacktrace shows the assert as being triggered

There are only a handful of possible explanations I can think of:

• secp256k1_context_sign is somehow not set to NULL on creation, even though the code does assign it a NULL value when globally creating it (compiler bug?)
• AppInitSanityChecks is being called twice somehow this would cause it, however there is no indication in the logs that this is the case, and theres no clear code path by which this would happen, so if it were it would probably indicate memory corruption,
• The value of secp256k1_context_sign is somehow being corrupted; so again memory corruption

The first of these is incredibly unlikely so I don't want to consider that yet. The other two both basically boil down to memory corruption, in this case its then somewhat hard to track down as the actual error/assertion you are seeing likely have nothing really to do with the cause but are rather just a side effect. The actual corruption could be triggered by any code that runs prior to this part of the code (or of course hardware issues, potentially external libraries that are bad etc.)

So a few things: Can you try this on a different machine possibly so we can ascertain whether this is machine specific or not? I don't currently have an Ubuntu 20.04.2 VM/Machine ready but I can't reproduce this on other linux boxes... Can you run with -debug flag and paste log again in case that yields any additional hints

[mjmacleod]

Okay, curiously I did manage to trigger this just once this side now on my dev box, have a slight hunch what I might have done differently so will dig into it a bit more this side as well.

[mjmacleod]

Unfortunately only managed to get this to happen just the once, my hunch as to what triggered it ended up being a dead end. When I get a chance I'll set up some VMs and see if any of them reproduce it reliably, until then if any other info you think is helpful comes up please do let me know.

[mjmacleod]

Having now tried on several fresh ubuntu VMs, including one on 20.04.2, I have unfortunately been completely unable to reproduce this behaviour so far.

[GeertJohan]

Hmm, if no-one else is encountering this issue then probably best to let it rest. I'll run the app on a different machine / OS.

[mjmacleod]

Okay, if it does occur as well on a different machine please let me know. Will revisit this if/when we get more reports.