Crashing problems (on windows, msys2)

[Ben Campbell]

Has anyone else had any problems using go-qml under msys2?

I was using mingw with the standard Qt/mingw binary install downloaded from http://www.qt.io
My program was all working fine, although I could only produce a 32bit version under mingw.

So I've been switching to msys2, installing the Qt5 binaries and gcc toolchain via pacman. I can compile everything just fine in both the 32bit and 64bit environments, but my program no longer seems to run properly.
The 32 bit version just panics soon after qml.Run(), while the 64bit version seems to work, although the list view which is the main component of my application doesn't refresh properly (the bulk of it remains blank while random lines seem to flicker on and off).

I realise that's not exactly a helpful or comprehensive bug report ;-)

But I've already spent a few days banging my head against a brick wall here, so I just want to see if anyone else was experiencing similar problems.

I'm using go1.6 and Qt5.7
I experience these problems with both the original go-qml repo and also the limetext fork.

Any ideas?


Thanks,
Ben.

[Matt Peterson]

I had a production-ready app written in go-qml running on windows building from msys2, but I haven't worked on it for a while. I'm surprised it is crashing for you. I also used MXE from linux to cross compile, but if you aren't using Linux I wouldn't recommend that.

I never tried running in 64-bit. Can you send the panic you are getting in 32-bit?

[Ben Campbell]

On Thursday, August 25, 2016 at 5:43:41 AM UTC+12, Matt Peterson wrote:

I had a production-ready app written in go-qml running on windows building from msys2, but I haven't worked on it for a while. I'm surprised it is crashing for you. I also used MXE from linux to cross compile, but if you aren't using Linux I wouldn't recommend that.

I never tried running in 64-bit. Can you send the panic you are getting in 32-bit?

I went back to try some of the examples supplied with go-qml. Some of them work, but some crash. eg:

$ cd ~/mygo/src/gopkg.in/qml.v1/examples/controls/tableview
$ go build
$ ./tableview.exe
Exception 0xc0000005 0x0 0x1 0x1
PC=0x1
signal arrived during external code execution


gopkg.in/qml%2ev1._Cfunc_componentCreateWindow(0x3a8bb80, 0x0, 0x0)
        ??:0 +0x33
gopkg.in/qml%2ev1.(*Common).CreateWindow.func1()
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/qml.go:750 +0x3e
gopkg.in/qml%2ev1.hookIdleTimer()
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/bridge.go:190 +0x53
gopkg.in/qml%2ev1._Cfunc_applicationExec()
        ??:0 +0x2f
gopkg.in/qml%2ev1.Run(0x54e5bc, 0x0, 0x0)
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/bridge.go:63 +0x142
main.main()
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/examples/controls/tableview/tableview.go:10 +0x26


goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        c:/go/src/runtime/asm_386.s:1662 +0x1


goroutine 5 [chan receive]:
gopkg.in/qml%2ev1.RunMain(0x13ca0020)
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/bridge.go:88 +0xb3
gopkg.in/qml%2ev1.(*Common).CreateWindow(0x13c7c010, 0x0, 0x8)
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/qml.go:751 +0xfd
main.run(0x0, 0x0)
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/examples/controls/tableview/tableview.go:24 +0x85
gopkg.in/qml%2ev1.Run.func1(0x13c283c0, 0x54e5bc)
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/bridge.go:60 +0x2a
created by gopkg.in/qml%2ev1.Run
        c:/msys64/home/ben/mygo/src/gopkg.in/qml.v1/bridge.go:62 +0x13d
eax     0x1
ebx     0x3a43130
ecx     0x34a2fbb0
edx     0x34a415b0
edi     0x1fc
esi     0x38270000
ebp     0x34ea2e78
esp     0xa99cec
eip     0x1
eflags  0x210206
cs      0x23
fs      0x53
gs      0x2b

The 64 bit version seems to work fine.

(My app also uses table view heavily, and mostly works in 64bit - I see lots of flickering and improperly-updating rows when I have a lot of rows. I could imagine that the example tableview.exe might have some problems too if there were more rows...)

This is using:

- the msys2 shell

- the stock gcc toolchain packages from msys2, installed via pacman

- the stock qt5.7 packages from msys2, installed via pacman

- go1.5.4 binaries from golang.org (I've installed both the 32bit and 64bit versions, and switch between them depending on if I'm using a 32 or 64 bit msys2 shell)

I've found a few online references to "signal arrived during external code execution" in relation to cgo not liking certain types of exception handling (eg setjmp/longjmp vs SEH). Which is kind of suggestive - 32bit and 64bit mingw use different exception-handling methods I think...

 

[Ben Campbell]

On Thursday, August 25, 2016 at 5:43:41 AM UTC+12, Matt Peterson wrote:

I had a production-ready app written in go-qml running on windows building from msys2, but I haven't worked on it for a while. I'm surprised it is crashing for you. I also used MXE from linux to cross compile, but if you aren't using Linux I wouldn't recommend that.

Actually, I _am_ using linux for the bulk of the development, and mostly just pop out to windows (and OSX) for builds, so MXE looks very interesting - they've got quite a comprehensive list of libraries they support.

But. There's always some extra fiddling needed on each platform, so it makes sense to try and have a native builld setup working smoothly. Not to mention it being worthwhile to figure out for people using windows as their primary platform!

[Ben Campbell]

OK, so I'm now pretty sure it's actually a problem in the msys2 mingw-w32 packages.

I've filed an issue:

https://github.com/Alexpux/MSYS2-packages/issues/672

Any progress, and I'll post an update here too for future reference.

(also, I got my Qt version wrong - I'm actually using Qt5.6.1, not Qt5.7)

Anyway, it appears that Qt is segfaulting, and that's causing the Go panic I'm seeing.

Here's my pared-down .qml file. I can get it to crash without any Go or C++

crashy.qml:

import QtQuick 2.2
import QtQuick.Layouts 1.1
import QtQuick.Controls 1.2

ApplicationWindow {
 id: window
 visible: true
 title: "Table View Example"

 ListModel {
 id: largeModel
 Component.onCompleted: {
 // 5 items works OK... but 5000 does not :-(
 for (var i=0 ; i< 5000; ++i)
 largeModel.append({"name":"Person "+i})
 }
 }

 TableView {
 id: tabView
 anchors.fill: parent
 TableViewColumn {
 id: nameColumn
 title: "Name"
 role: "name"
 movable: false
 resizable: false
 }
 model: largeModel
 }
}

Running it via qmlscene:

$ qmlscene.exe crashy.qml
Segmentation fault

[Matt Peterson]

Yeah, give MXE a try. I was able to get Msys2 to work eventually, but I had to rebuild Qt which took f-o-r-e-v-e-r. Builds on Windows are slower for some reason. MXE is a very well done project, I had a much easier time getting it to work than Msys2. The makefile just worked for me. The build still took a while, but you could get the binary distributions instead.

[Ben Campbell]

OK, so it looks like the msys2 Qt packages are currently borked (definitely and catastrophically for 32bit, but I'm also pretty suspicious of the 64bit packages). Not just for go-qml, but in general.
I think that it's an issue that'll resolve over time - I think a newer gcc helps. However, I'm not inclined to spend a lot more time experimenting - it took my computer nearly 3 days solid to recompile the Qt packages (the  toolchain seems a little slower under windows!). So I'm just going to wait it out and keep an eye on it.

In the meantime, my workaround is to use the mingw toolchain that Qt ships with it. Seems like an ugly workaround to have your compiler dictated by your GUI toolkit, but hey. 32bit only too :-(

Ben.

[Ignazio Di Napoli]

I have no problem with 64 bit msys2 packages. What kind of problem you are suspicious of?

Ignazio

[Ben Campbell]

On Wednesday, August 31, 2016 at 11:22:36 PM UTC+12, Ignazio Di Napoli wrote:

I have no problem with 64 bit msys2 packages. What kind of problem you are suspicious of?

I've got a tableview widget, backed by a model that has lots of rows (up to hundreds of thousands, say). This seems to screw up completely - mostly blank, except for a couple of rows continuously flashing (trying to refresh, I guess). I've not investigated too deeply - building a 32bit windows version is more critical than 64bit for me right now. So it might well be something I'm doing, or some quirk in qml-go... but the exact same code works fine on 32bit windows (using the Qt and mingw that Qt supply), and on 64bit linux and OSX.

[Ignazio Di Napoli]

I also have some problem of this kind. Setting the environment variable QT_OPENGL=angle solves them for me (that is, if I understand correctly, using Direct3D instead of OpenGL with a compatibility layer). 

[Ben Campbell]

On Friday, September 2, 2016 at 3:07:10 AM UTC+12, Ignazio Di Napoli wrote:

I also have some problem of this kind. Setting the environment variable QT_OPENGL=angle solves them for me (that is, if I understand correctly, using Direct3D instead of OpenGL with a compatibility layer). 

Ahh, thanks for that! I'll have another go at the 64bit build.
Will try the 32bit Msys2 Qt packages again when they next update.

Ben.