Last active 7 hours ago


Last active 4 months ago

#123 smooth window resizing a day ago

Comment by ~eliasnaur on ~eliasnaur/gio

Fixed by gioui.org/commit/4cb96ccad91.


#144 502 error on patch a day ago

Ticket created by ~eliasnaur on ~sircmpwn/lists.sr.ht

#124 Multi-touch and grab 2 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Mon Jun 1, 2020 at 5:25 PM CEST, ~gordonklaus wrote:

It is currently possible to do multi-touch pointer handling within a single widget. However, across multiple widgets it can be problematic.

Consider two slider widgets. If we want the user to be able to operate them simultaneously with different fingers, all is well... until one of the them decides to grab the pointer. Grabbing might be necessary if e.g. they are contained in a layout.List that itself wants to grab the pointer.

I can think of two solutions: 1. When Grab: true is specified, only grab events for the pointer IDs for which a Press event was already received.

1 sounds good to me. FWIW, that's the behaviour I aimed for in the

recent router refactor (but obviously failed to achieve/test).

#122 Extra pointer.Press events delivered when multi-touching. 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio


#121 X11 crash on start 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Sun May 31, 2020 at 3:01 PM CEST, ~whereswaldon wrote:

Does gio support running with GOARCH=386? I'm seeing it fail to compile:

$ env GOARCH=386 GODEBUG="cgocheck=2" go run .

../gio/app/internal/egl/egl.go:13:2: build constraints exclude all Go 
files in /home/chris/Code/arbor/gio/app/internal/glimpl

You need CGO_ENABLED=1 (it is 0 by default for cross-compiling). You also need the 386 development dependencies (GLES, X11 libs etc.).

However, by introspecting the value of cfg _EGLConfig, I think I've found evidence that you're right. Its value is constant, regardless of which compiler I use or whether or not I allocate HUGE arrays at the beginning of main. It is always 0xcaf32c. This is true in go 1.14.3, on the master branch, and in your CL. Given that it is a pretty low value (in terms of the overall address space) and that it does not vary in value across permutations of the source that allocate different amounts of memory, it seems like it isn't a pointer.

I agree. Thanks for digging into the values.

Regardless, thank you such much for digging so deep into this! I know that this kind of bug is time consuming (and easily dismissed since it's only happening on my hardware), and I really appreciate the time and effort that you've put into it!

No worries. That it happens on your hardware makes it very likely that it may happen on somebody else's. So thank you for persevering and for your clear reports.

#121 X11 crash on start 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio


#121 X11 crash on start 3 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

On Sun May 31, 2020 at 01:43, ~whereswaldon wrote:

Indeed, I didn't have the same version of go installed in both places. Laptop with intel GPU had 1.14, desktop with NVIDIA had 1.14.2. I've updated both to 1.14.3 and I still see the same behavior (laptop works, desktop crashes).

I've built go from source with this version:

go version devel +8da78625b1 Sun May 31 00:55:05 2020 +0000 

This version does not trigger the panic on a the exact same source code that previously did panic.

I have also tried using the modified version of go from your CL:

go version devel 
+e43ccd84d1 Sun May 31 00:02:32 2020 +0200 linux/amd64

This version also succeeds in building and running without a panic (once I updated gio to compile after your CL; thanks for already patching that!).

Based on these tests, I really don't know what to think. Since the original problem didn't occur all the time (sometimes commenting out a line of code would make it go away, even thought that line was application logic completely irrelevant to gio), I don't think that its absence on the master branch of go is really proof that the problem is fixed. It feels as though the compiler is making some kind of fairly arbitrary low-level decision that sometimes triggers the bug and sometimes doesn't. Since the compiler itself has changed from 1.14.3 => 1.15(ish), it's hard to say whether the underlying problem is handled or whether I just need a different permutation of the source code to trigger it.

I'll definitely keep an eye out for it, and I'll try using the master branch of go to do my builds for sprig on this machine. If I can get the panic to recur, I'll then see whether the version containing your patch resolves it. That would be much more definitive than the evidence that I can offer today.

I'm going to submit CL 235817 because I can't see what else could cause the cgo pointer check failure. The EGLDisplay is already mapped to uintptr by a previous special case, and the EGLint can't contain a Go pointer. Furthermore, from inspecting go build -x -work gioui.org/app/internal/egl the only call to _cgoCheckPointer is checking the cfg EGLConfig parameter.

If you can think of any other way to introspect the problem, I'm happy to try it!

If you're still interested, you could print out the actual values of cfg _EGLConfig parameter and see whether they look like pointers but aren't (dereferencing them results in faults).

Another way to increase the likelyhood of failures is to test with GOARCH=386 which has a much smaller address space. You may even combine it with allocating (and holding on to) a bunch of Go memory before initializing Gio to increase the number of values that look like pointers to Go memory.

-- elias

#121 X11 crash on start 4 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

I didn't look close enough: EGLConfig is also a pointer-type and it's very likely the NVIDIA driver construct non-pointer EGLConfigs. Can you test https://go-review.googlesource.com/c/go/+/235817?

#121 X11 crash on start 4 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

The offending code is:

func eglGetConfigAttrib(disp _EGLDisplay, cfg _EGLConfig, attr _EGLint) (_EGLint, bool) {
    var val _EGLint 
    ret := C.eglGetConfigAttrib(disp, cfg, attr, &val)
    return val, ret == C.EGL_TRUE

The only pointer passed into C is &val, which is a pointer to an integer:

type _EGLint           = C.EGLint

I can't reproduce the crash running spriglocally, and I haven't seen complaints from -race, so I'm stumped.

I suggest you raise the issue on the Go issue tracker where Ian or another expert may help. Feel free to CC me.

#121 X11 crash on start 4 days ago

Comment by ~eliasnaur on ~eliasnaur/gio

Have you tried -race?