G-Golf - Callback segmentation fault

G-Golf - Callback segmentation fault

[Matija Obid]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

Hello,

I'm facing the problem mentioned in [1]. Problematic are all examples
with virtual methods.

I have tried simpler example (attached) with same result. There is no
problem, when try same thing with guile-gi library. Somehow, callbacks
are not callable back from C code. Any clue?

I'm using Nix.


[1] https://lists.gnu.org/archive/html/guile-user/2024-05/msg00013.html

[-- Attachment #2: golf-drawing.scm --]
[-- Type: application/octet-stream, Size: 1162 bytes --]

#! /bin/sh
# -*- mode: scheme; coding: utf-8 -*-
exec guile -e main -s "$0" "$@"
!#

(gc-disable)

(eval-when (expand load eval)
  (use-modules (oop goops))

  (default-duplicate-binding-handler
    '(merge-generics replace warn-override-core warn last))

  (use-modules (g-golf))

  (g-irepository-require "Gtk" #:version "4.0")
  (for-each (lambda (name)
              (gi-import-by-name "Gtk" name))
			'("ApplicationWindow"
			  "Application"
			  "DrawingArea")))

(define (activate app)
  (let* ((window (make <gtk-application-window>
                   #:application app
                   #:default-width 960
                   #:default-height 540
                   #:title "Title"))
		 (drawing-area (make <gtk-drawing-area>)))
	(set-child window drawing-area)
	(set-draw-func drawing-area
				   (lambda (area cr w h d)
					 (display "I'm in!")
					 (force-output))
				   #f
				   (lambda _ #f))
    (show window)))

(define (main args)
  (let ((app (make <gtk-application>
               #:application-id "local.example.DrawingArea")))
    (connect app 'activate activate)
    (let ((status (g-application-run app args)))
      (exit status))))

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


-- 
Regards,
Matija

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

Hello,  Yes, the same issue still plagues me.  Never tried guile-gi and
I do not know the difference regarding vfuncs.  Is it like pygobject
that guile-gi does not use Guile as much and more C?

My only progress:

> I'm using Nix.

Interesting.  Guix and Nix have their own settings to load libraries
according to a sideline comment in [1], but I have no clue otherwise.

Intermittently I once saw a different error:

florian@florianhp ~/src/tcgocr [env]$ ~/src/g-golf/examples/gtk-4/drawing-widget.scm 
Backtrace:
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
           7 (apply-smob/0 #<thunk 7f95bfcbe300>)
In ice-9/boot-9.scm:
    724:2  6 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
    619:8  5 (_ #(#(#<directory (guile-user) 7f95bfcc1c80>)))
In ice-9/boot-9.scm:
   2836:4  4 (save-module-excursion _)
  4388:12  3 (_)
In g-golf/hl-api/vfunc.scm:
    93:12  2 (_)
   188:23  1 (vfunc-checks snapshot-vfunc _)
    236:4  0 (specializers-vfunc-lookup _ _)

But this different error disappeared after recompiling g-golf, is
probably unrelated and I could not reproduce it again.

Regards,
Florian

[1] https://guix.gnu.org/en/blog/2021/taming-the-stat-storm-with-a-loader-cache/

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

Hi Florian,

	is your debian host g-golf experience ok? i know it is a
	temporary solution, till we find a solution for nix/guix, but
	i am curious - also, is the app you are working on free s/w,
	any public repo we could look at?

> Hello,  Yes, the same issue still plagues me.  Never tried guile-gi
> and I do not know the difference regarding vfuncs.  Is it like
> pygobject that guile-gi does not use Guile as much and more C?

I just made a comment about guile-gi because Matija did mention it ...
and wanted to make sure they understand guile-gi does not support
virtual function ... but yes, guile-gi is nearly entirely written in C,
and as a matter of fact, largely inspired by pygobject.

> My only progress:
> 
> > I'm using Nix.  
> 
> Interesting.  Guix and Nix have their own settings to load libraries
> according to a sideline comment in [1], but I have no clue otherwise.

As i did suggest already, you should ask for some guix highly
knowledgeable designer/developer (and who deeply knows the other
involved domains, C, guile's ffi implementation, dynamic libs linking
...) - I'd happily stand corrected, and happily patch g-golf if ... but
till proved wrong, i don't think it is a g-golf problem.

> Intermittently I once saw a different error:
> ...

I can't make sense of this error, but so you know, vfunc-checks checks
that the (upstream lib) virtual function you are trying to define in
g-golf exists in the class you are 'altering', and also checks that the
scheme virtual function name is correct [1]

So it disappeared and you can't reproduce it, let's concentrate on
the (g-golf) virtual function definition bug in Nix/Guix ...

Thanks,
David

[1] https://www.gnu.org/software/g-golf/manual/g-golf.html#define_002dvfunc

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

Hello David.  Thank you for this important groundwork that g-golf is.

Sorry to say, I have not developed any GUI and had no time as planned.
It will not happen with me.  But Debian is not the problem; all is fine
there (unlike G-Golf on Guix on Debian).

I also failed to put a libg-golf-tests library to actually test gobject
libraries in g-golf’s tests and link it with libtool, but it never
worked, because autotools does not support linking for tests and all
libtool executing would have to be done manually.

The feedback I can give: guile-zlib in its build system autodetects the
location of its needed libz library in configure.ac as LIBZ_LIBDIR,
substitutes that in a config.scm.in module and calls (dynamic-link
%libz) on that path.  If you made g-golf/init.scm do this, it would be
easy on Guix/Nix to build from source.

David Pirotte <david@altosw.be> writes:
> As i did suggest already, you should ask for some guix highly
> knowledgeable designer/developer (and who deeply knows the other
> involved domains, C, guile's ffi implementation, dynamic libs linking
> ...) - I'd happily stand corrected, and happily patch g-golf if ... but
> till proved wrong, i don't think it is a g-golf problem.

I’m missing an entry point to debug if the problem is
<https://gitlab.gnome.org/GNOME/gobject-introspection/-/blob/main/girepository/gitypelib.c>
and do not understand typelibs, except I see the giscanner part of
gobject-introspection needed Nix-/Guix-specific patches:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/gobject-introspection-absolute-shlib-path.patch

https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/development/libraries/gobject-introspection/absolute_shlib_path.patch

which I cannot understand at the moment.  I suspect you’d need similar
work.

Then, I see on docs.gtk.org there is a girepository 3.0 (likely a typo
and meant to say 2.0) migration which will make it hard to try the
latest girepository version with g-golf, but also, no version of
girepository 2.0 is packaged for guix anyway.  It seems much movement is
being done there under gobject-introspection’s hood.


>> Intermittently I once saw a different error:
>> ...
>
> I can't make sense of this error, but so you know, vfunc-checks checks
> that the (upstream lib) virtual function you are trying to define in
> g-golf exists in the class you are 'altering', and also checks that the
> scheme virtual function name is correct [1]

So indeed you regard it as unrelated, too.  I tried but wasn’t able to
make any reproducer, because the issue happened no longer; it did not
happen in container isolation.  But the problematic build, that I did
not keep, was isolated.

Could you document this purpose of vfunc-checks in
g-golf/hl-api/vfunc.scm?  Clearly you have put a lot of glib
introspection knowledge in the g-golf implementation that an outsider
would understand only with IRC help.  But it’s the same for
gobject-introspection itself.


> So it disappeared and you can't reproduce it, let's concentrate on
> the (g-golf) virtual function definition bug in Nix/Guix ...

Yes, this is the only real annoyance.

Regards,
Florian

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]

Hi Florian,

> Hello David.  Thank you for this important groundwork that g-golf is.

Thanks for the nice words - I hope that some day, with the help of
Guix/Nix maintainer(s), we can identify and solve the problem.

> Sorry to say, I have not developed any GUI and had no time as planned.
> It will not happen with me.  But Debian is not the problem; all is
> fine there (unlike G-Golf on Guix on Debian).

It's ok, i just wanted to know if you had given it a try, and see
for yourself that using debian, everything works fine.

> I also failed to put a libg-golf-tests library to actually test
> gobject libraries in g-golf’s tests and link it with libtool ...

I don't follow you here, in order to run the g-golf test-suite, all
you need to do, in a build tree, is to run 'make check'

> The feedback I can give: guile-zlib in its build system autodetects
> ...

Not sure i want to do this.

> I’m missing an entry point to debug if the problem is ...
> ...
> which I cannot understand at the moment.  I suspect you’d need similar
> work.

I have no idea what guix/nix 'need' so g-golf works there as well, this
is a question you have to raise with guix/nix maintainers ...

> Then, I see on docs.gtk.org there is a girepository 3.0 (likely a typo
> and meant to say 2.0)

Nope, this is explained in the migration doc

> migration which will make it hard to try the latest girepository
> version with g-golf ...

Don't worry, i'll deal with the migration, in due time ...

> So indeed you regard it as unrelated, too.

Yes.

> Could you document this purpose of vfunc-checks in
> g-golf/hl-api/vfunc.scm?

Not in any foreseen future.

Thanks,
David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

Hello David.

David Pirotte <david@altosw.be> writes:
> Thanks for the nice words - I hope that some day, with the help of
> Guix/Nix maintainer(s), we can identify and solve the problem.

The other Nix patches for giscanner had been written by Luca Bruno who
did work on gobject-introspection itself, although Guix maintainers do
know more about Guile, ELF, runpaths and loaders and analyzing memory
ranges in /proc/4423/maps.


>> I also failed to put a libg-golf-tests library to actually test
>> gobject libraries in g-golf’s tests and link it with libtool ...
>
> I don't follow you here, in order to run the g-golf test-suite, all
> you need to do, in a build tree, is to run 'make check'

'make check' relies on external libraries like GTK for its tests.  I had
been thinking that testing vfuncs would be easier to understand with a
small custom test library instead of GTK.  But building such a library
is not that easy and I failed to write one.  Probably unnecessary if
everything were working fine.


>> The feedback I can give: guile-zlib in its build system autodetects
>> ...
> Not sure i want to do this.

Yeah, normally there is no need, when using the package.

I do not know what Matija did on Nix, because I cannot find any g-golf
in Nixpkgs.  Currently, on Guix, when building from source disregarding
the guix package, one needs to manually rewrite init.scm similar to what
the guix package does here [1].  Because /usr/lib is from the host
distro, if there even is a host distro, we do rewrite init.scm’s
dynamic-link code with a:

(define (get lib)
  ;; Search the library’s /gnu/store/.../lib/....so file-name.
  (search-input-file inputs (string-append "lib/" lib ".so")))
(let* ((libgi      (get "libgirepository-1.0"))
       (libglib    (get "libglib-2.0"))
       (libgobject (get "libgobject-2.0"))
       (libg-golf (string-append #$output "/lib/libg-golf")))
  (substitute* "g-golf/init.scm"
    (("libgirepository-1.0") libgi)
    (("libglib-2.0") libglib)
    (("libgobject-2.0") libgobject)


>> Could you document this purpose of vfunc-checks in
>> g-golf/hl-api/vfunc.scm?
>
> Not in any foreseen future.

Okay.  But thank you for teaching here that vfunc-checks doesn’t check
our Scheme vfuncs.

Regards,
Florian

[1] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile-xyz.scm#n2480

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:
>>> The feedback I can give: guile-zlib in its build system autodetects
>>> ...
>> Not sure i want to do this.
>
> Yeah, normally there is no need, when using the package.
>
> I do not know what Matija did on Nix, because I cannot find any g-golf
> in Nixpkgs.  Currently, on Guix, when building from source disregarding
> the guix package, one needs to manually rewrite init.scm similar to what
> the guix package does here [1].  Because /usr/lib is from the host
> distro, if there even is a host distro, we do rewrite init.scm’s
> dynamic-link code with [absolute paths.]

I understand now with more though:

It is not /usr/lib, it is $LD_LIBRARY_PATH and such environment
variables.  And although such has no place in Guix, $LD_LIBRARY_PATH is
an easy way to use custom-written libraries instead, by which non-free
g-golf users could comply with the LGPL license.

Regards,
Florian

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1.1: Type: text/plain, Size: 3221 bytes --]

Hello Matija,

> I'm facing the problem mentioned in [1]. Problematic are all examples
> with virtual methods.

Ok, so you are facing the same problem as Guix and HomeBrew, all other
distro (that tried g-golf) work fine, i use Debian.

> I have tried simpler example (attached) with same result. There is no
> problem, when try same thing with guile-gi library. Somehow, callbacks
> are not callable back from C code. Any clue?

	afaict, guile-gi does not support the definition of virtual
	functions - you can try this example using guile-gi
	(which afaict is unmaintained) because you are calling a
	'regular' method, set-draw-func

	no problem, just saying that a mechanism to define vfunc in
	the GI lang binding of your choice is absolutely crucial for any
	'real serious' gnome stack (type)libs use

	one big diffference in between guile-gi and g-golf is that in
	g-golf, the callback closure marshal code is written in scheme,
	the one in guile-gi is written in C - it could be that the
	pointer of the vfunc 'is fine' in guix/nix as well, but that for
	some reason, the %g-golf-callback-closure-marshal pointer
	would be the one that is damaged, i don't know

Great, never used that function. You incidentally found a small bug in
GI itself [1], and a tiny bug in G-Golf as well, though not the one
that would solve the Guix/Nix/Homebrew problem yet [2], but thanks:

	can you install from the source
	checkout the devel branch
	run the make danse and install the latest

	[ to double check, you need this commit
	[ 134b57f52bc23cea8e3e02b974c7b909bb7cf56e

So, here, after i patched g-golf to deal with this GI destroy notify
callback tiny problem, so i can pass #f as its argument, then it works
fine, as expected:

	https://imgur.com/a/tX8bn16

I slightly patched your example so it allows you to call it passing a
-d [--debug] argument on the command line, which triggers the
display of useful information while debugging ...

> I'm using Nix.

It would be interesting to try to understand the difference in between
Debian (and most other distro) and Guix/Nix: when a vfunc is defined,
it sets the upstream class structure field to a pointer, the result of
calling g-callable-info-make-closure (defined in (g-golf hl-api
callback).

For some reason, that pointer is 'damaged' in Guix/Nix/Homebrew, and
not in Debian (and most other distro), and as the gdb backtrace shows,
in the msg link you are referring to, when Gtk tries to make a snapshot,
it needs to access and 'call that pointer', which segfault ...

I hope you'll be able to help, feel free to come and join us in #guile
or #guix and try to get some help from a guix expert ...

Thanks,
David

[1]

all destroy notify callback argument ('linked' to a user-data argument)
should always allow to be NULL, which g-golf checks by calling (>=
(!destroy clb/arg) 0)  but the signature of the destroy notify callback
argument for gtk_drawing_area_set_draw_func wrongly report -1

[2]

i did report the incident upstream, and meanwhile, patched g-golf so it
treats callback argument named "destroy" as a maybe-null-exception,
which checks itself had a tiny bug, fixed, thanks!

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: nix-set-draw-func.scm --]
[-- Type: text/x-scheme, Size: 1527 bytes --]

#! /bin/sh
# -*- mode: scheme; coding: utf-8 -*-
exec guile -e main -s "$0" "$@"
!#


(eval-when (expand load eval)
  (use-modules (oop goops))

  (default-duplicate-binding-handler
    '(merge-generics replace warn-override-core warn last))

  (use-modules (g-golf))

  (g-irepository-require "Gtk" #:version "4.0")
  (for-each (lambda (name)
              (gi-import-by-name "Gtk" name))
			'("ApplicationWindow"
			  "Application"
			  "DrawingArea")))


(define (activate app)
  (let* ((window (make <gtk-application-window>
                   #:application app
                   #:default-width 960
                   #:default-height 540
                   #:title "Title"))
	 (drawing-area (make <gtk-drawing-area>)))
    (set-child window drawing-area)
    (set-draw-func drawing-area
		   (lambda (area cr w h d)
		     (display "I'm in!")
		     (force-output))
		   #f
		   #f)
    (show window)))

(define (main args)
  (letrec ((debug? (or (member "-d" args)
                       (member "--debug" args)))
           (animate
            (lambda ()
              (let ((app (make <gtk-application>
                           #:application-id "org.gnu.g-golf.set-draw-func")))
                (connect app 'activate activate)
                (let ((status (g-application-run app '())))
                  #;(exit status)
                  (dimfi 'status status))))))
    (if debug?
        (parameterize ((%debug #t))
          (animate))
        (animate))))

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[Matija Obid]

[-- Attachment #1: Type: text/plain, Size: 272 bytes --]

Hello again,

I think I found something.

There is a version check in "g-callable-info-make-closure" function, if
I disable it (check patch) all examples works just fine.

I'm not quite sure what these functions does, can you take another look?

My gi version is 1.80.1.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fixing-callbacks-segfaults.patch --]
[-- Type: text/x-patch, Size: 845 bytes --]

From 4bec7836f17dfd453b877f65d5e91aa29c082d70 Mon Sep 17 00:00:00 2001
From: Matija Obid <matija.obid@posteo.net>
Date: Tue, 27 Aug 2024 21:34:50 +0200
Subject: [PATCH] Fixing callbacks segfaults

---
 g-golf/hl-api/callback.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/g-golf/hl-api/callback.scm b/g-golf/hl-api/callback.scm
index 633635c..04b9ea2 100644
--- a/g-golf/hl-api/callback.scm
+++ b/g-golf/hl-api/callback.scm
@@ -150,7 +150,7 @@
                                       ffi-cif
                                       ffi-closure-callback
                                       user-data)
-  (if (gi-check-version 1 71 0)
+  (if (and #f (gi-check-version 1 71 0))
       (g-callable-info-create-closure
        info ffi-cif ffi-closure-callback user-data)
       (g-callable-info-prepare-closure
-- 
2.45.2


[-- Attachment #3: Type: text/plain, Size: 21 bytes --]


-- 
Regards,
Matija

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

Wow, Matija, good idea; this work-around fixes all examples on Guix, too
(using gobject-introspection version 1.78.1).

Regards,
Florian

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]

Hello Matija,

> There is a version check in "g-callable-info-make-closure" function,
> if I disable it (check patch) all examples works just fine.

Great! But ...

> I'm not quite sure what these functions does, can you take another
> look?

g-callable-info-make-closure just select in between the appropriate GI
make closure function it must use [1], depending on your GI version:

	>= 1.71.0
	use g-callable-info-create-closure

	otherwise
	use g-callable-info-prepare-closure

> My gi version is 1.80.1.

So your patch seems to point to a problem in the upstream definition of
the (most recent) g-callable-info-create-closure, which is the one
everybody who's using GI >= 1.71.0 should use ...

Your patch 'wrongly' force to still use the (deprecated in 1.72.0)
g-callable-info-prepare-closure function.

Note that, on NixOS  and Guix, it is not the call to
g-callable-info-create-closure that segfault, but the call to the
closure that was made calling g-callable-info-create-closure

Fwiw, I just posted an explanation of this problem in the matrix room
#introspection:gnome.org, asking if anyone has an idea ... but i very
much doubt they will answer.

Do you (or anyone else interested ofc) have an idea of why would
g-callable-info-create-closure perfectly create a closure pointer on
debian, and not on guix/nix? Here is the upstream code def [2]

Thanks,
David

[1]	note that this code precedes the fact that g-golf now depends
on GI >= 1.72.0, for some other reason - so technically, i could have
removed g-callable-info-make-closure and always use
g-callable-info-create-closure ... fortunately for guix/nix, till will
find a real fix, i left this 'inoffensive' code in g-golf core ... 

[2] 

g_callable_info_create_closure

	https://salsa.debian.org/gnome-team/gobject-introspection/-/blob/debian/latest/girepository/girffi.c?ref_type=heads#L355


g_callable_info_prepare_closure

	https://salsa.debian.org/gnome-team/gobject-introspection/-/blob/debian/latest/girepository/girffi.c?ref_type=heads#L447
















[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[Matija Obid]

Hello David,

> So your patch seems to point to a problem in the upstream definition of
> the (most recent) g-callable-info-create-closure, which is the one
> everybody who's using GI >= 1.71.0 should use ...

I see. The comment in deprecated function made me thinking and I found
notice in LFS [1]:
> --disable-exec-static-tramp
>     Disable static trampoline support. It's a new security feature in
>     libffi, but some BLFS packages (notably GJS and
>     gobject-introspection) have not been adapted for it. 

This flag was recently removed [2] in nixpkgs with a comment:
> The fix for gobject-introspection is in version 1.72.

Bottom line: If I compile Guile with patched libffi [3] dependency
(where flag "disable-exec-static-tramp" is present) problematic examples
are working (without patched G-Golf).


> Do you (or anyone else interested ofc) have an idea of why would
> g-callable-info-create-closure perfectly create a closure pointer on
> debian, and not on guix/nix? Here is the upstream code def [2]

Most probably has Debian present flag "disable-exec-static-tramp" when
configuring libffi. Where can we check that?

I still wonder where is the problem, in Guile, G-Golf or
gobject-introspection (which according to [2] should not be a problem).


[1] https://www.linuxfromscratch.org/~xry111/lfs-cross-la/view/systemd/chapter08/libffi.html
[2] https://github.com/NixOS/nixpkgs/pull/257742
[3] Libffi is used in a lot of packages. I patch it only for Guile.

-- 
Regards,
Matija

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

Hello Matija.  I confirm that on Guix as well static trampolines are the
issue; using

((package-input-rewriting
  `((,libffi . ,libffi-sans-static-trampolines)))
 guile-3.0)

as Guile to run g-golf demos makes every g-golf demo work without patches.

Regards,
Florian

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

Hello Matija,

> This flag was recently removed [2] in nixpkgs with a comment:
> > The fix for gobject-introspection is in version 1.72.  

Maybe the fix didn't really fixed the problem ...

> Bottom line: If I compile Guile with patched libffi [3] dependency
> (where flag "disable-exec-static-tramp" is present) problematic
> examples are working (without patched G-Golf).

Perfect, just do that then, in nix guix as well (debian does, see below)

> Most probably has Debian present flag "disable-exec-static-tramp" when
> configuring libffi. Where can we check that?

Yes, in debian testing, libffi 3.4.6-1, the flag is on by default:

	https://codesearch.debian.net/search?q=disable-exec-static-tramp+pkg%3Alibffi

> I still wonder where is the problem, in Guile, G-Golf or
> gobject-introspection (which according to [2] should not be a
> problem).

Definitely not a g-golf bug. But since the flag has been introduced
precisely to deal with the yet to be fixed gobject-introspection, iiuc,
i would just continue to compile libffi passing the flag ...

Thanks,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

Hi again,

> ...

> > I still wonder where is the problem, in Guile, G-Golf or
> > gobject-introspection (which according to [2] should not be a
> > problem).  

> Definitely not a g-golf bug.

Unless the code used by g-golf to make the ffi-cif would need to be
adapted, i don't know, but one thing is for sure though, the g-golf
made cif is checked, calling ffi_prep_cif [1], and that procedure would
raise a exception unless the returned status is 0.

Cheers,
David

Fwiw, this is in
	
	libg-golf/gg-ffi.c
		gg_ffi_prep_cif

the scheme call in

	(g-golf support ffi)
		ffi-prep-cif

which when preparing a callback is used in

	(g-golf hl-api callback)
		callback-ffi-cif

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

Hello Matija,
Florian,

> > > I still wonder where is the problem, in Guile, G-Golf or
> > > gobject-introspection (which according to [2] should not be a
> > > problem).    

> > Definitely not a g-golf bug.  

Further speaking with other GI lang binding authors, the gjs author
finally did point me to some fix they did for gjs that i could also
apply to g-golf ...

Could you both kindly grab the latest devel branch, you need this
commit bbfee04922bf2a22db397e2f429ae606df940265, and run the
make/install danse on your respective distro, then check if the
'problematic' examples work fine _even when_ run against a modern libffi
that was compiled without the --disable-exec-static-tramp

and let me know ...

Thanks,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

Thank you David, thank you Matija,
it works on Guix!

Except for small warnings like
Warning: Missing /etc/X11/rgb.txt, using a fallback.
that probably should be fixed on the Guix side.

And some issues that I have to chdir to
~/src/g-golf/examples/gtk-4/
to run
~/src/g-golf/examples/gtk-4/revealer.scm,
otherwise I get
g-golf/hl-api/function.scm:89:6: Failed to open file ???/home/florian/ui/revealer.ui???: No such file or directory

And some locale issues when running adwaita demo
only when running in a container,
ERROR: In procedure dirname:
In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f
probably because I set up the container wrongly.

Regards,
Florian

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

P.S. on Guix, I also no longer have to use --no-grafts, possibly because
Guix had major updates to core packages.  G-golf really satisfies now.

Also thank you to the GJS maintainer for their help.

Regards,
Florian

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 854 bytes --]


> P.S. on Guix, I also no longer have to use --no-grafts, possibly
> because Guix had major updates to core packages.

Excellent!

> G-golf really satisfies now.

At last! Note that the above was not a g-golf problem [1].

Regards,
David

[1]

And for that matter, nor is (a g-golf problem) the patch i just added
to adapt to a GI/libffi api change that i was unaware of [2] - up to
this upstream api change, g-golf has never failed to build and run an
ffi-closure, ever since it implements callback and vfunc, all (the
closure marshal machinery) entirely written in scheme by the way.

[2]

the gi doc tells us switch to call g-callable-info-create-closure when
using gi >= 1.71.0, but fails to tells us that, starting with gi >=
1.72.0, the ffi-closure pointer we receive is no longer a 'native
executable code pointer' ...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

Hi again,

> > P.S. on Guix, I also no longer have to use --no-grafts, possibly
> > because Guix had major updates to core packages.  
> Excellent!

> > G-golf really satisfies now.  
> At last! Note that the above was not a g-golf problem [1].

Just want to make sure we are (all) on the same wave length here:
what really satisfies now is Guix, G-Golf always has.

David

> [1]

> And for that matter, nor is (a g-golf problem) the patch i just added
> to adapt to a GI/libffi api change that i was unaware of [2] - up to
> this upstream api change, g-golf has never failed to build and run an
> ffi-closure, ever since it implements callback and vfunc, all (the
> closure marshal machinery) entirely written in scheme by the way.

> [2]

> the gi doc tells us switch to call g-callable-info-create-closure when
> using gi >= 1.71.0, but fails to tells us that, starting with gi >=
> 1.72.0, the ffi-closure pointer we receive is no longer a 'native
> executable code pointer' ...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1619 bytes --]

Hi Florian,

> Thank you David, thank you Matija,
> it works on Guix!

Excellent!

> Except for small warnings like
> Warning: Missing /etc/X11/rgb.txt, using a fallback.
> that probably should be fixed on the Guix side.

You may as well safely ignore the warning ofc - i am not sure how to
handle this, yet ... this is in the newly added (g-golf support color)
module ... [1]

> And some issues that I have to chdir to
> ~/src/g-golf/examples/gtk-4/
> to run
> ~/src/g-golf/examples/gtk-4/revealer.scm,
> otherwise I get
> g-golf/hl-api/function.scm:89:6: Failed to open file
> ???/home/florian/ui/revealer.ui???: No such file or directory

Yes, you have to, as things are, because all template files are
(currently), files :), and their path are defined, at runtime, based
on the app (script) dirname ... I could improve that, but not in the
near future ...

> And some locale issues when running adwaita demo
> only when running in a container,
> ERROR: In procedure dirname:
> In procedure scm_to_utf8_stringn: Wrong type argument in position 1
> (expecting string): #f probably because I set up the container
> wrongly.

It is not because of a locale issue, it is because you are calling
(dirname #f)

	scheme@(guile-user)> (dirname #f)
	"ice-9/boot-9.scm":1677:22: In procedure raise-exception:
	In procedure "scm_to_utf8_stringn": Wrong type argument in
	position 1 (expecting "string"): #f

	Entering a new prompt.  Type `,bt' for a backtrace or `,q' to
	continue.

Cheers,
David

[1]

https://www.gnu.org/software/g-golf/manual/html_node/Color-Hollow.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[Matija Obid]

Hello David,

> Could you both kindly grab the latest devel branch, you need this
> commit bbfee04922bf2a22db397e2f429ae606df940265, and run the
> make/install danse on your respective distro, then check if the
> 'problematic' examples work fine _even when_ run against a modern libffi
> that was compiled without the --disable-exec-static-tramp
>
> and let me know ...

Except for "peg-solitaire.scm" and "animated-paintable.scm" all examples
works fine, thank you.

animated-paintable.scm gives me:
--8<---------------cut here---------------start------------->8---
** (process:25114): CRITICAL **: 15:20:34.141: g_interface_info_find_vfunc: assertion 'GI_IS_INTERFACE_INFO (info)' failed
Backtrace:
In ice-9/boot-9.scm:
  1755:12  7 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
           6 (apply-smob/0 #<thunk 7fde3eb14300>)
In ice-9/boot-9.scm:
    724:2  5 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
    619:8  4 (_ #(#(#<directory (guile-user) 7fde3eb17c80>)))
In ice-9/boot-9.scm:
   2858:4  3 (save-module-excursion _)
  4410:12  2 (_)
In /home/matija/source/guile/g-golf/examples/gtk-4/./animated-paintable.scm:
     97:0  1 (_)
In g-golf/hl-api/vfunc.scm:
   184:12  0 (vfunc-checks snapshot-vfunc _)

g-golf/hl-api/vfunc.scm:184:12: In procedure vfunc-checks:
No such VFunc : "snapshot"
--8<---------------cut here---------------end--------------->8---

Same error is with peg-solitaire.scm for vfunc "get-intrinsic-height".

-- 
Regards,
Matija

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Hi Matija,

	Florian,
	This example should 'now' likely fail in guix as well (?)

> Except for "peg-solitaire.scm" and "animated-paintable.scm" all
> examples works fine, thank you.

I can reproduce the bug here, let me investigate, i'll get back asap ...

Thanks for the report,
David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Matija,
Florian,

> > Except for "peg-solitaire.scm" and "animated-paintable.scm" all
> > examples works fine, thank you.  

> I can reproduce the bug here, let me investigate, i'll get back asap

I think i fixed that (recently introduced) bug [1].

Could you both kindly grab the latest devel branch, you need this
commit 5d72bfcdae85bb4a5b0254dc9f22fb8c676db69d, and try
both the animated-paintable.scm and peg-solitaire.scm ex. ... let me
know.

Thanks,
David

[1]

however, it seems there is another problem, which is that when i
leave the animated-paintable.scm run ... after a certain time, which
can be short (a few seconds) or quite long (more then 10 minutes), 
all of a sudden it stops and raises an exception - could you also try
that and let me know, thanks

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

David Pirotte <david@altosw.be> writes:
> Could you both kindly grab the latest devel branch, you need this
> commit 5d72bfcdae85bb4a5b0254dc9f22fb8c676db69d, and try
> both the animated-paintable.scm and peg-solitaire.scm ex. ... let me
> know.

animated-paintable and peg-solitaire I had not tried last time and
they are the ones that crash.

Yes, they had not worked previously, and now with your long-name fix,
they work.

> all of a sudden it stops and raises an exception - could you also try
> that and let me know, thanks

Yes, after 5 minutes animated-paintable.scm crashes.  Hmm.

florian@florianhp ~/src/g-golf/examples/gtk-4 [env]$ ./animated-paintable.scm 
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /home/florian/src/g-golf/examples/gtk-4/./animated-paintable.scm
Warning: Missing /etc/X11/rgb.txt, using a fallback.
;;; compiling /home/florian/src/g-golf/examples/gtk-4/nuclear-icon.scm
;;; compiled /home/florian/.cache/guile/ccache/3.0-LE-8-4.6/home/florian/src/g-golf/examples/gtk-4/nuclear-icon.scm.go
;;; compiled /home/florian/.cache/guile/ccache/3.0-LE-8-4.6/home/florian/src/g-golf/examples/gtk-4/animated-paintable.scm.go

(animated-paintable.scm:2): Gtk-WARNING **: 09:12:26.679: Unable to acquire session bus: Could not connect: No such file or directory
Backtrace:
In ice-9/boot-9.scm:
  1752:10 13 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
          12 (apply-smob/0 #<thunk 7f836056f300>)
In ice-9/boot-9.scm:
    724:2 11 (call-with-prompt _ _ #<procedure default-prompt-handle?>)
In ice-9/eval.scm:
    619:8 10 (_ #(#(#<directory (guile-user) 7f8360572c80>)))
In /home/florian/src/g-golf/examples/gtk-4/./animated-paintable.scm:
   147:18  9 (main _)
In g-golf/hl-api/function.scm:
    90:19  8 (_ . _)
In unknown file:
Exception thrown while printing backtrace:
In procedure primitive-call-ip: Wrong type argument in position 1 (expecting PRIMITIVE_P): #<procedure 7f835a080940 (_ _ _ _ _ _ _)>

oop/goops.scm:1585:2: No applicable method for #<<accessor> !callback (2)> in call (!callback #<procedure 7f8351c53540 at system/vm/frame.scm:134:22 (target)>)

David Pirotte <david@altosw.be> writes:
>> Except for small warnings like
>> Warning: Missing /etc/X11/rgb.txt, using a fallback.
>> that probably should be fixed on the Guix side.
>
> You may as well safely ignore the warning ofc - i am not sure how to
> handle this, yet ... this is in the newly added (g-golf support color)
> module ... [1]

Probably I would just patch out the warning for Guix?

David Pirotte <david@altosw.be> writes:
>> G-golf really satisfies now.
>
> At last! Note that the above was not a g-golf problem [1].

Yes, but still it is much better that I can now soon rewrite my
trivial Kodi launcher to use g-golf instead of C.  Having to
use a virtual machine meant I could not reasonably put g-golf to use
there.

Regards,
Florian

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

Hi Florian,

> Yes, they had not worked previously, and now with your long-name fix,
> they work.

Fwiw, they actually worked fine till day one till 2024-09-04, the day i
pushed this commit a3952000ae205c27573ab0eaf2176131b51e34cf,
that 'broke' them ...

But i am glad you confirm everything is fine now, thanks.

> > all of a sudden it stops and raises an exception - could you also
> > try that and let me know, thanks  

> Yes, after 5 minutes animated-paintable.scm crashes.  Hmm.

Ok, thanks for trying - This is going to be quite a lot more complex to
debug and fix, and i may need the help of some guile/goops guru ...

> ..
> oop/goops.scm:1585:2: No applicable method for #<<accessor> !callback
> (2)> in call (!callback #<procedure 7f8351c53540 at
> system/vm/frame.scm:134:22 (target)>)

The error actually varies on to what 'corrupt' the instance upon which
the !callback accesor is being run, but it is always a !callback
accesor call that triggers the error

>...

> Yes, but still it is much better that I can now soon rewrite my
> trivial Kodi launcher to use g-golf instead of C.  Having to
> use a virtual machine meant I could not reasonably put g-golf to use
> there.

Ofc - It is a relief for all Guix users that the GNOME team finally
fixed the GLib/GObject/GI/GdkPixbuf packages so that G-Golf (and
other GI lang binding for that matter) work(s) 'out of the box':

	Could you post a mini guide with the steps a guix user would
	have to do, till guix is released, to get this 'proper GI' env
	for g-golf? then i can point to the link in #guile and #guix
	when that applies;

	And till g-golf is released and updated in guix, the steps they
	have to do to locally build and install the latest g-golf

	Many thanks!

Let me know if you need help for your Kodi project, and keep us
informed ... when you have a link to where the code is, share with
us ...

David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Hello Florian,
Matija,

> > > all of a sudden it stops and raises an exception - could you also
> > > try that and let me know, thanks    

> > Yes, after 5 minutes animated-paintable.scm crashes.  Hmm.  

> Ok, thanks for trying - This is going to be quite a lot more complex
> to debug and fix, and i may need the help of some guile/goops guru ...

Actually, not as complex as i initially thought ... and I believe I fixed
that bug too, commit 655aaf64278562fdf15d64d976ccb71c3dcee7eb

If you could kindly grab the latest, run the make/install dance on your
respective distro and try again ... Here the example now runs for hours,
as it should, consuming +/- 3% cpu and a steady 0.8% of mem (so afaict,
no memory leak either).

Thanks,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]


> ...
> Here the example now runs for hours, as it should, consuming +/- 3%
> cpu and a steady 0.8% of mem (so afaict, no memory leak either).

Actually the example memory consumption grows, very slowly but it grows.
I think I know why, I'll try to fix this as well, but I need to finish
some other work first.

David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: G-Golf - Callback segmentation fault

[pelzflorian (Florian Pelz)]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

Hello David.

David Pirotte <david@altosw.be> writes:
> If you could kindly grab the latest, run the make/install dance on your
> respective distro and try again ... Here the example now runs for
> hours,

Yes, same on Guix.  It runs for more than an hour.

> as it should, consuming +/- 3% cpu and a steady 0.8% of mem (so afaict,
> no memory leak either).

David Pirotte <david@altosw.be> writes:
> Actually the example memory consumption grows, very slowly but it grows.
> I think I know why, I'll try to fix this as well, but I need to finish
> some other work first.

Yes, in /proc/8662/maps, the [heap] region below the guile regions
slowly but steadily grows.

David Pirotte <david@altosw.be> writes:
>> Yes, they had not worked previously, and now with your long-name fix,
>> they work.
> Fwiw, they actually worked fine till day one till 2024-09-04, the day i
> pushed this commit a3952000ae205c27573ab0eaf2176131b51e34cf,
> that 'broke' them ...

Yes, by “they had not worked previously”, I meant commit
bbfee04922bf2a22db397e2f429ae606df940265, where I wrongly claimed it was
working fine but had not tried animated-paintable nor peg-solitaire.

> Ofc - It is a relief for all Guix users that the GNOME team finally
> fixed the GLib/GObject/GI/GdkPixbuf packages so that G-Golf (and
> other GI lang binding for that matter) work(s) 'out of the box':
>
> 	Could you post a mini guide with the steps a guix user would
> 	have to do, till guix is released, to get this 'proper GI' env
> 	for g-golf?

Guix notifies all users regularly to pull the latest rolling release.
This contains at the time of writing a close to current GNOME 44.10 with
gobject-introspection 1.78.  Currently, to use g-golf with vfuncs and
proper guile-cairo, one has to use Guix’ Scheme programming interface,
for example the guix.scm file created with guile-hall.  I use [1].

When guile-cairo and g-golf have a new release, developers just write
guile-cairo and guile-g-golf in there instead.  It would also be usable
from the CLI, but for app developers using Guix, guix.scm is always the
way to go even then.

For Nix it will be the same in Nix language instead of guix.scm.

This is equivalent to manual patching and a manual make install dance.

> Let me know if you need help for your Kodi project, and keep us
> informed ... when you have a link to where the code is, share with
> us ...

Gladly, but my trivial, zenity-like, personal Kodi launcher/restarter
and hard-disk mounting tool is coupled with Sway and to make the code
pretty, Guix developers first need to push some home-sway-service-type
patches [2].

Regards,
Florian

[1]

[-- Attachment #2: edited guix.scm from guile-hall --]
[-- Type: text/plain, Size: 2731 bytes --]

(use-modules (gnu packages)
             (gnu packages autotools)
             (gnu packages libffi)
             (gnu packages gettext)
             (gnu packages glib)
             (gnu packages linux)
             (gnu packages xml)
             (gnu packages gnome)
             (gnu packages texinfo)
             (gnu packages gtk)
             (gnu packages guile)
             (gnu packages guile-xyz)
             (gnu packages pkg-config)
             (guix build-system glib-or-gtk)
             (guix download)
             (guix git-download)
             (guix gexp)
             ((guix licenses)
              #:prefix license:)
             (guix packages)
             (guix transformations)
             (srfi srfi-1))

(define-public guile-cairo-next
  (package
    (inherit guile-cairo)
    (source (origin
             (method git-fetch)
             (uri (git-reference
                   (url "git://git.savannah.nongnu.org/guile-cairo.git")
                   (commit "30da459d7a4380174ff243b1560d5512a4bca86e")))
             (sha256
              (base32
               "0dslfldzgxis8g0g3xaffcqnd1njzz23fjy0v3lc0r2694ra4ny4"))
             (file-name (string-append "guile-cairo-next"))))
    (inputs
     (list guile-lib expat guile-3.0 gettext-minimal))
    (native-inputs
     (list autoconf-2.71 automake libtool pkg-config texinfo))
    ))

(package
  (name "tcgocr")
  (version "0.01")
  (source
   (local-file (dirname (current-filename))
               #:recursive? #t
               #:select? (lambda (file stat)
                           (not (any (lambda (my-string)
                                       (string-contains file my-string))
                                     (list ".git" ".dir-locals.el" "guix.scm"))))))
  (build-system glib-or-gtk-build-system)
  (arguments
   `())
  (native-inputs (list pkg-config  libtool automake autoconf-2.71 ))
  (inputs (list ;;((package-input-rewriting
                  ;;`((,libffi . ,libffi-sans-static-trampolines)))
                 guile-3.0;;)
                glib
                gtk
                libadwaita
                ((options->transformation '((without-tests . "guile-cairo")))
                  guile-cairo-next)
                ((options->transformation '((with-debug-info . "gobject-introspection")
                                            (with-commit . "guile-g-golf=ab666af394e92180c0ffb67363b2bde061b92b84");v0.8.0-rc.5")
                                            ))
                 guile-g-golf)
                (list glib "debug")
                (list libffi "debug")
                ))
  (propagated-inputs (list))
  (synopsis "")
  (description "")
  (home-page "https://none.yet")
  (license license:gpl3+))

[-- Attachment #3: Type: text/plain, Size: 39 bytes --]


[2]
https://issues.guix.gnu.org/72714

Re: G-Golf - Callback segmentation fault

[Matija Obid]

David Pirotte <david@altosw.be> writes:

> Hello Florian,
> Matija,
>
>> > > all of a sudden it stops and raises an exception - could you also
>> > > try that and let me know, thanks    
>
>> > Yes, after 5 minutes animated-paintable.scm crashes.  Hmm.  
>
>> Ok, thanks for trying - This is going to be quite a lot more complex
>> to debug and fix, and i may need the help of some guile/goops guru ...
>
> Actually, not as complex as i initially thought ... and I believe I fixed
> that bug too, commit 655aaf64278562fdf15d64d976ccb71c3dcee7eb
>
> If you could kindly grab the latest, run the make/install dance on your
> respective distro and try again ... Here the example now runs for hours,
> as it should, consuming +/- 3% cpu and a steady 0.8% of mem (so afaict,
> no memory leak either).

Example works now and random crashes seems to be fixed. Thank you.

-- 
Regards,
Matija