Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mist.exe crashes on Windows 10 Technical Preview #135

Closed
erezwanderman opened this issue Oct 7, 2014 · 13 comments
Closed

mist.exe crashes on Windows 10 Technical Preview #135

erezwanderman opened this issue Oct 7, 2014 · 13 comments
Labels

Comments

@erezwanderman
Copy link
Contributor

(Copied from here ethereum/go-build#5)
I managed to get it built.
When I run ethereum.exe it starts fine:

C:\Ethereum\go\src\github.com\ethereum\go-ethereum\ethereum>ethereum
Qt: Untested Windows version 6.4 detected!
2014/10/07 02:10:17 [CLI] identity created
2014/10/07 02:10:17 [CHAIN] Last block (#0) 08436a4d33c77e6acf013e586a3333ad152f25d31df8b68749d85046810e1f4b
2014/10/07 02:10:17 [CLI] Starting Ethereum(G)/v0.6.7/windows/go1.3.3
2014/10/07 02:10:17 [REACTOR] started
2014/10/07 02:10:17 [SERV] Ready and accepting connections
2014/10/07 02:10:19 [SERV] Server started

But when I run mist.exe it pops a message "mist.exe has stopped working. Windows is checking for a solution to the problem".

The machine is running in VirtualBox and I'm connecting to it through Remote Desktop. Could be a graphics/driver/qt problem. I'll try to run it when connected to the terminal tomorrow.

@erezwanderman
Copy link
Contributor Author

Crashes the same way when connected directly to the VM.

@erezwanderman
Copy link
Contributor Author

Found it crashes on main.go line 74: qml.Run(run)
Might be related to go-qml/qml#109

@obscuren
Copy link
Contributor

obscuren commented Oct 8, 2014

Thanks. We're looking in to windows issues. Unfortunately Windows has quite a few problems :-(

@geraldstanje
Copy link

@obscuren can you help to debug this?

@erezwanderman
Copy link
Contributor Author

After adding C:\Qt\Qt5.3.2\5.3\mingw482_32\bin to the PATH (something I should have done in the first place) it still crashes, but takes more time. Now output is:

2014/10/12 01:08:44 [CLI] identity created
2014/10/12 01:08:54 [CHAIN] Last block (#0) 08436a4d33c77e6acf013e586a3333ad152f25d31df8b68749d85046810e1f4b
2014/10/12 01:08:54 [CLI] Starting Mist/v0.6.7/windows/go1.3.3
2014/10/12 01:08:54 [REACTOR] started
2014/10/12 01:08:54 [SERV] Ready and accepting connections
2014/10/12 01:08:54 [SERV] Server started
2014/10/12 01:08:54 [JSRE] started
2014/10/12 01:08:55 [SERV] Added peer (207.12.89.101:30303) 1 / 10 ([])
2014/10/12 01:08:56 plugin.cpp:52:
WARNING: This project is using the experimental QML API extensions for QtWebKit and is therefore tied to a specific QtWebKit release.
WARNING: The experimental API will change from version to version, or even be removed. You have been warned!

ASSERTION FAILED: uncommittedMemory.State == MEM_RESERVE
wtf\StackBounds.cpp(194) : void WTF::StackBounds::initialize()
1   5d002ddf
2   5ce1d7ed
2014/10/12 01:08:57 [SERV] Added peer (65.34.194.20:30303) 2 / 10 ([eth])

@obscuren
Copy link
Contributor

That's indeed the issue. Somehow WTF (Web Template Framework) is bonkers on Windows.

@erezwanderman
Copy link
Contributor Author

So WTF is the real WTF?

@obscuren
Copy link
Contributor

Good question :-)

@erezwanderman
Copy link
Contributor Author

Further investigation: On Windows 7, 32 bit:
Qt 5.2.1 works well!
Qt 5.1 is too old for Mist
Qt 5.3.2 (and probably 5.4.0) fail because of WTF bug.

On Windows 10 Technical Preview x64:
It dosen't work with any Qt version. Probably a bug in the OS or Qt.

So maybe this need to be split into two issues.

@fjl
Copy link
Contributor

fjl commented Oct 29, 2014

That looks like a good resolution. Let's simply document Qt 5.2.1 as the only compatible version and ship that QT version with mist for 1.0.

@erezwanderman
Copy link
Contributor Author

Yes, but also make sure go-qml or Qt know about the issues so they will solve them, and newer versions will work in the future.

@erezwanderman
Copy link
Contributor Author

Opened issue: QtWebKit WebView crashes on Qt 5.3.2
go-qml/qml#116

@obscuren
Copy link
Contributor

Mist is now using Qt5.4 which removes the dependency on WebKit (and adds Chromium).

Any volunteers for Qt5.4 on windows? :)

@zelig zelig added the mist label Apr 14, 2015
@fjl fjl closed this as completed Jun 23, 2015
nonsense added a commit to nonsense/go-ethereum that referenced this issue Nov 15, 2017
…cket

p2p/sim: configurable unix socket read/write buffer size
maoueh pushed a commit to streamingfast/go-ethereum that referenced this issue Aug 13, 2021
* syncservice: log error on unknown topic

* typo: fix
tony-ricciardi pushed a commit to tony-ricciardi/go-ethereum that referenced this issue Jan 20, 2022
* cmd, consensus, eth, ethstats: add protocol interface into consensus to support custom messages

* params: add Istanbul consensus engine config to ChainConfig

* cmd/*: add Istanbul command line flags

* consensus/istanbul, eth: add Istanbul configuration

* node: add an interface to retrieve node key from config

* core/types: add Istanbul specific block hash calculation

* internal/web3ext: add Istanbul JS RPC API

* consensus: add Istanbul consensus engine interface

* consensus/istanbul: Istanbul core implementation

* consensus/istanbul: add tests for Istanbul core

* consensus/istanbul: common Istanbul interfaces and types

* consensus/istanbul: Istanbul validator set implementation

* consensus/istanbul: Istanbul consensus backend implementation

* core, les, eth, miner: Istanbul consensus integration

* cmd/*, core, params: add ottoman testnet

* Address comments

* Fix Istanbul lint (ethereum#137)

* Remove unused vars for lint

* Remove unnecessary conversion

* Don't propose empty blocks with Istanbul (ethereum#134)

* Make istanbul.Backend a public type

* Don't mine empty block with Istanbul engine unless necessary

* PR comments

* Revert to original order

* Add test fixes

* PR comments

* Update the expected hash given that celo headers have a different payload with BlockSignature

* Make Istanbul's Seal asynchronous

Originally, when Istanbul was written, the Seal method was synchronous,
i.e. it would return when the sealing process was done (or cancelled).
Now that is no longer the case, in fact the miner expects the Seal to
return to be able to respond/intiate other Seal's. This commit allows
Istanbul to do so.

* Notify the Istanbul engine of new ChainHeads

During the merge, we removed this crucial line, where the worker will
notify the Istanbul engine of new chain heads that crucially allow its
peers to increse the sequence number for the next Seal.

* Apply celolatest syncmode mods to Istanbul

* [Istanbul] Seal/NewHeadChain fixes (ethereum#147)

* Make Istanbul's Seal asynchronous

Originally, when Istanbul was written, the Seal method was synchronous,
i.e. it would return when the sealing process was done (or cancelled).
Now that is no longer the case, in fact the miner expects the Seal to
return to be able to respond/intiate other Seal's. This commit allows
Istanbul to do so.

* Notify the Istanbul engine of new ChainHeads

During the merge, we removed this crucial line, where the worker will
notify the Istanbul engine of new chain heads that crucially allow its
peers to increse the sequence number for the next Seal.

* Fix test

* Fix test
joshuacolvin0 pushed a commit to joshuacolvin0/go-ethereum that referenced this issue Jan 4, 2023
sbellem pushed a commit to sbellem/go-ethereum that referenced this issue Jul 25, 2023
Overall strategy is:
 * we assume operations on well-formed ciphertexts don't fail
 * for operations we assume shouldn't fail, we use asserts
 * for operations that we assume can fail, we use return codes

Essentially, allowing malformed ciphertexts from txns means these ops
could fail at some point in the lifetime of a cihpertext and/or on
ciphertexts that are produced from the original one:
 * deserialization or ciphertexts
 * decrypt
 * any FHE operation
 * serialization

We assume the following ops don't fail if all inputs are well-formed:
 * deser of FHE keys
 * encryption

We also assume that tfhe-rs failures are always deterministic. That
allows us to not stop the node on such a failure and assume that all
nodes have the same behaviour, leaving nodes in sync.

Also, do not use Go finalizers anymore. Instead, ser/deser ciphertexts
across the C/Go boundary. That avoids complications with finalizers and
memory management. However, it has a performance overhead and we need to
be extra careful that we free all C memory manually.
atenjin pushed a commit to alt-research/go-ethereum that referenced this issue Apr 4, 2024
come-maiz pushed a commit to come-maiz/go-ethereum that referenced this issue Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants