Boxed types and lifetime ...

[passenger94]

First, Thank you very much for your awesome work !

Unless i miss something, i believe there is something missing in Boxed type : if you take ownership of the C object, like all D Boxed types do, than as it isn't a Gobject it as no ref so it can disappear at any time (?).
I discovered this in a loop where several Boxed types (graphene Rect and Gdk RGBA) are created, the program randomly crashes but always while trying to "g_boxed_free" one of those objects. If, in the loop,i build the C structures on the stack on the D side, and use them to build the D objects than everything is fine.

The code is on my github : https://github.com/passenger94/ListView_Clocks
the function do_snapshot() is the loop.

forgot to mention !
it's an adaptation of the gtk-demo : https://github.com/GNOME/gtk/blob/main/demos/gtk-demo/listview_clocks.c

it's the working code, if you replace for example

        GdkRGBA redc = GdkRGBA(1,0,0,1);
        auto red = new RGBA(&redc);
        snap.appendColor(red, outline.bounds());

by

snap.appendColor(new RGBA(1,0,0,1), outline.bounds());

it crashes after a while.

[dejlek]

I never used GdkRGBA in my D apps. If you use it like that, the RGBA constructor actually makes sure ownership is NOT taken by default.

this(void* ptr, Flag!"Take" take = No.Take)

Did you try the following:

auto red = new RGBA(&redc, Yes.Take);

Also, if you do not mind asking - why are you using GdkRGBA? Why not simply something like: auto red = new RGBA(1, 0, 0, 1); ?

Update: I forked your repo and I can't reproduce the crash... Do you have latest code pushed to the main branch? It is really hard to navigate that strange mix of C and D code. :)

[passenger94]

Hello, thanks for answering.

yes like i wrote the code in the repo is the one working, because i used C code in lieu of D code while attempting to understand why the code is crashing and find where it happens. It's always when a Boxed type is garbage collected, that's what i understood and using C code is the workaround (anyway it's what the D code is doing under the hood).
Yes i tried the No.take (that's what timezone = new TimeZone(tz.copy_()) for example is doing)
i started with regular D code and while attempting to understand what's going on i went in lower level of abstraction until i somewhat "fixed" the problem.

did you try to run the code with the replacement i proposed ?

here the same loop with D only code it crashes pretty hard

private void do_snapshot()
{
   double width = 100;
   double height = 100;
   auto BLACK = new RGBA(0,0,0,1);

   if (time)
      time.destroy();
   if (timezone)
      time = DateTime.newNow(timezone);
   else
      time = DateTime.newNowLocal();

   snap.save();

   snap.translate(new Point(width / 2, height / 2));  

   import gsk.c.types: GskRoundedRect;
   auto initRect = new Rect();
   initRect = new Rect(initRect.init_(-50, -50, 100, 100).copy_());
   GskRoundedRect rr;
   RoundedRect outline = new RoundedRect(&rr);
   outline = outline.initFromRect(initRect, 50);
   snap.appendBorder(outline, [4, 4, 4, 4], [BLACK, BLACK, BLACK, BLACK]);

   snap.save();
   snap.rotate(30 * time.getHour() + 0.5 * time.getMinute());
   initRect = new Rect(initRect.init_(-2, -23, 4, 25).copy_());
   outline = outline.initFromRect(initRect, 2);
   snap.pushRoundedClip(outline);
   snap.appendColor(BLACK, outline.bounds());
   snap.pop();
   snap.restore();

   snap.save();
   snap.rotate(6 * time.getMinute());
   initRect = new Rect(initRect.init_(-2, -43, 4, 45).copy_());
   outline = outline.initFromRect(initRect, 2);
   snap.pushRoundedClip(outline);
   snap.appendColor(BLACK, outline.bounds());
   snap.pop();
   snap.restore();
        
   snap.save();
   snap.rotate(6 * time.getSecond());
   initRect = new Rect(initRect.init_(-1, -44, 2, 45).copy_());
   outline = outline.initFromRect(initRect, 1);
   snap.pushRoundedClip(outline);
   snap.appendColor(new RGBA(1,0,0,1), outline.bounds());
   snap.pop();
   snap.restore();

   snap.restore();
}

To my understanding the Boxed type when it takes the ownership in the super() of every descendant is not doing what's expected...
again to my understanding :)

[elementgreen]

I was also not able to get this to crash, even when using D RGBA objects. However, it doesn't look like the clocks are updating either, so that likely has something to do with it. I usually just use DrawingArea when doing custom widgets, so I haven't really done much with the Paintable interface and snapshots. The C code looks like it is using the Paintable interface and Picture widgets to render it in the list. I don't see this in your port though. The C demo code doesn't look like the easiest thing to port and I would probably have done things differently to begin with. It could be a good example to try to get working with giD though with respects to the Paintable interface and Snapshot drawing.

The RGBA D wrapper Boxed object normally allocates the C boxed type using g_malloc (C allocation), if it is called as new RGBA(r, g, b, a). It takes ownership of the allocation in this case using Yes.Take. That should be correct. What could be happening is that something else is taking ownership of the underlying C boxed structure and then D is crashing when it attempts to free it after something else already has done so. This could happen if there is an issue with an API function with respect to the argument ownership information. The Snapshot methods appendBorder and appendColor seem to be the only places I see in your code that takes an RGBA though. Both methods don't take ownership of the colors (I looked at the GTK C code to make sure).

Maybe something else is causing the crash? Have you been able to get a backtrace with gdb? What compiler are you using?

[passenger94]

Hi and thanks again,
i'm using dmd v2.109v1

The only Message i get from the crash :
MEMORY-ERROR: listview_clocks[226169]: GSlice: assertion failed: sinfo->n_allocated > 0

in a debug session it always end in gobject.boxed.Boxed class here:

~this()
  {
    if (cInstancePtr) 
      g_boxed_free(gType, cInstancePtr);     // <== stops there in debug session with the above message
  }

Yes that was the goal, i wanted to experiment with the snapshot and paintable objects, at first i was also hoping to play with Expression but ClosureExpression is missing in D bindings (anyway i should have created a new Gobject Type, the Gtk way of subclassing, which is a bit too much ... for the PropertyExpression to work with my object - it works fine with Gtk objects by the way).

Strange it crashes very fast on my side(4-5s) and Clocks are updating fine ... and the tweaked version is rock stable with clocks updating fine...

What i noticed is that the crashes disappears when i create the C struct on the D stack, meaning D is managing the memory if i'm correct.
This is happening with all boxed types and not only in the loop (i think the loop is making things more obvious by stressing the app) TimeZone, DateTime .... but very hard to track because it's random and not in systematic outside the loop.

Boxed types are not Gobjects so they must be managed by their own, shouldn't they be managed by D the same way Gobjects are (a root in GC, etc...) ?

EDIT : same situation with dmd 2.111.0 (using gid 0.9.6)

[dejlek]

Could you push your latest code to your Git repo please? Also, are you on Windows by any chance? I can't reproduce this crash on my Fedora box. If you are on Linux, are you on X11 or Wayland? I am asking these questions because it could be that the code behaves differently on particular platform...

[passenger94]

linux ubuntu 22.04 (stuck with gtk4 v4.6 (above version are not supported) ... could be of importance) and on X11

update with the crashing code ?
EDIT : updated with the crashing code

[elementgreen]

I created a Dockerfile which reproduces the environment you are using. I was then able to run the application in the Docker container by connecting it to my host Wayland desktop. This can be done with Xorg as well, but would require different settings to connect the Docker container to X.

The clocks do indeed update and it crashes rather quickly as you say. I'll see if I can troubleshoot the issue now that I can reproduce it.

The Dockerfile I used and commands to build/run it are below for reference.

FROM ubuntu:22.04

# Install build tools and dependencies
RUN apt-get update && apt-get install -y \
    gcc \
    libgtk-4-1 \
    libharfbuzz-gobject0 \
    wayland-protocols \
    libwayland-client0 \
    libwayland-egl1 \
    && rm -rf /var/lib/apt/lists/*

COPY dmd_2.109.1-0_amd64.deb /tmp/dmd_2.109.1-0_amd64.deb
RUN dpkg -i /tmp/dmd_2.109.1-0_amd64.deb || apt-get install -f -y
RUN rm /tmp/dmd_2.109.1-0_amd64.deb

# Set Wayland environment
ENV WAYLAND_DISPLAY=wayland-0
ENV XDG_RUNTIME_DIR=/tmp

CMD ["/bin/bash"]

Download dmd_2.109.1-0_amd64.deb and put it in the same directory as the Dockerfile (assume its in a subdirectory named docker/ for the following commands).

Build the docker image:

docker build --build-arg UID=$(id -u) --build-arg GID=$(id -g) -t ubuntu2204-dmd docker

Run the docker container and connect it to Wayland. This assumes that the current directory is the ListView_Clocks project, which can then be found at /workdir in the docker container.

docker run --rm -it \
  -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY -e XDG_RUNTIME_DIR=/tmp \
  -v $(pwd):/workdir \
  -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY \
  --user $(id -u):$(id -g) ubuntu2204-dmd /bin/bash

[dejlek]

EG, I think he is on X11, not Wayland. Same like me. Fedora 41, running X11 here. GTK4 4.16.13.
In my case I do not get the crash, however, the clocks are not updating. @passenger94 , I've checked your repository and there are no updates there, so I assume that code is the latest one. Is that the code that crashes, or not?

Also, this dub.json will make it build:

{
    "name": "listview_clocks",
    "targetType": "executable",
    "dependencies": {
        "gid:gtk4": "==0.9.6",
        "gid:graphene1": "==0.9.6"
    },
    "sourceFiles": ["listview_clocks.d"]
}

On my machine it does not build without sourceFiles line.

[passenger94]

? updates there is ! with the crashing code like i said above.
you do not see it ? the crashing code is annotated and the working code is commented out ...
(you are right i forgot the "src" directory, my bad).

@elementgreen was able to reproduce the problem with a similar setup so it seems that there is probably something with the gt4 version ...
well, If it's only a question of an older gtk version, i suggest not wasting time on the issue...
strange, nonetheless

[elementgreen]

Yes, I know @passenger94 is using X. That is what I used to test things on my Wayland system, which shouldn't be too hard to change to work with X instead. Was just providing it for reference.

Having delved a bit more into Snapshot and Paintable, I see a lot of potential issues with the crashing code. It seems like the usual way to use Snapshot and Paintable is to create a new GObject type, which implements Paintable. Something which giD doesn't really do at the moment, though I have often thought about adding such support. It probably is possible to do using the wrapped C API, but that kind of defeats the purpose right? 😉 Such support in giD would make it possible to create native GObjects using D classes and virtual methods, which are available in C. Not only could that be used in this case, but also to create D libraries which could themselves have GObject Introspection bindings that would be usable in other languages, which would be quite cool!

I have not been able to find examples that use Snapshot and Paintable that doesn't rely on native GObjects. The usual way to create custom widgets in this case is to use GtkDrawingArea, which is Cairo based.

I see a number of hacky things going on in the failing code:

• Using GtkSnapshot and GdkPaintable without creating a native GObject class
• Using ListStore.itemsChanged to update the drawing (I suspect this is why we are seeing differences between Gtk versions with respect to the clocks updating)
• A new GtkSnapshot and snap.toPaintable() are created on each refresh, but not assigned to the Picture object that is used in the item factory, which makes me wonder how it even works with Gtk 4.6

I don't really want to spend much more time on troubleshooting Snapshot/Paintable, since I consider it something that isn't supported at the moment and this seems to be misusing that as it is.

I am curious why it crashes with the older Gtk 4.6 version though. It might be worth creating an example which just uses Boxed types like RGBA, to see if it causes the same issues. I definitely would like to have a better understanding of what is happening there. It just so happens the port I'm doing from C to D of the MarkdownBrowser I created, uses Paintable to display images in TextView and also makes use of RGBA. So it would be interesting to test that between the Gtk versions.

[elementgreen]

@elementgreen was able to reproduce the problem with a similar setup so it seems that there is probably something with the gt4 version ... well, If it's only a question of an older gtk version, i suggest not wasting time on the issue... strange, nonetheless

Agree. Seems you replied while I was writing my previous rather long winded post. 😄

[passenger94]

Totally agree on me bypassing the creation of a GtkClass, you can definitively do it but it's awfully verbose, which like you said defeat the purpose.. i didn't want to go that route just for the sake of experiment with Paintable and Snapshot
what I'm doing is collecting a snapshot than creating a Paintable from it, which "freezes" the Snapshot, so i had to create one every time, then save that paintable into Clock Object, by telling ListStore that the items changed it actually recreate the ListModel - this is the expected way of doing it from my understanding, otherwise like you said Picture is not filled with a new paintable.

EDIT: not really updating the whole ListModel but the parts that are displayed, for a TreeListModel for example the lower levels are not existent as long as the parent is collapsed, the list dynamically updates itself when the expanded event happens. you most probably know it but that's the parallel i established with the itemsChanged event fired ... i might totally off the road of course :)

i was expecting some possible problems due to the hackish way of experimenting, but not in Boxed types in general ...
Stumbling into that unexpected crash into Boxed types, i thought it would be better to ask here.

It would be awesome to be able to do the Gtk sub-classing in a D fashion, like you said the normal way is to create a new type and override the snapshot() virtual function, for properties also and be able to use PropertyExpressions probably some more, they encourage to subclass ListModel too ... well lot of opportunities indeed.

i will see if i can come up with something simple (and less dirty ...) which crashes with a Boxed type.

[dejlek]

@passenger94 apologies, I thought there were some updates to that code. :) I never used Graphene and GSK before, this made me look at it little bit and I actually like how it all works, so thanks for bringing this up.

[passenger94]

No problem :) i was wondering if i messed up something.

Never used them before as well, a bit cumbersome at first but i guess there is good reasons for that (the init_ dance) Btw i was wondering if there is room for static versions of the init_ functions in gsk RnoundedRect or graphene.Rect, a factory. Don't know if it is an easy thing to automate...

[elementgreen]

RoundedRect and Rect are just opaque structure types with methods. I recently added support for default constructors and am surprised not to see them generated for these. I consider this a bug. I've also at times considered just making these structs rather than classes which wrap a structure, as it is now. Might make more sense that way. I'll look into what is wrong with these particular types. So yes, they should have a way to construct them in the next version without resorting to the hacks you used.