Inheriting from custom type inheriting from Widget causes JVM crash #348
Labels
No labels
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
java
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
java-gi/java-gi#348
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Firstly, thank you so much for this project. This is amazing.
When inheriting from a custom type that inherits from Widget crashes the JVM. The following snippets can be used to test this.
Java-GI: 0.14.1
OS: Ubuntu 25.10
Gnome: 49
JVM output:
I originally got an error in a project where I tried to make a custom
GtkListBoxRowas a base for more rows. In that case I constructed them using GtkBuilder and UI template files (I have a MemorySegment constructor). There I got:I also tried to add
getMemoryLayoutmethods to the classes. This changed the error message.Thanks for reporting the issue!
I'll look into it.
Alright, I found the cause. Gtk isn't initialized.
Call
Gtk.init()before creating the widget, and it should all work perfectly.That actually fixes the reproduction I provided, however, this does not fix my original problem. I am currently trying to make a minimal reproduction of my problem. I'll get back when I got it.
I have a more complex reproduction here: https://codeberg.org/Til7701/java-gi-inheritance-bug
Basically, I have two classes (
AandB) that have a template and an instance is constructed from the window template. IfAandBdo not have a memory layout method, there is an error that A does not have a memory layout. So I copied and modified the method fromGtkListBoxRow, but now it says that the layout for B is smaller than the one for A. This issue also only occurs, if B has aGtkChildtaken from the template. In the new reproduction, it can be fixed by appending aValueLayout.ADDRESSto the memory layout, but this does not work in my actual application. I do not know the difference to the reproduction yet.Thanks for clarifying, that's indeed a bug. The memory layout for template classes is generated at runtime, but the derived class doesn't know about it and generates a wrong layout.