I develop an java swt app thats using gtk3 bindings. I’ve switched the OS release and its a mess. I get SIGSEGV opening basic dialogs. It looks like someone has fixed the function to prevent the fault. But i can not find any package to test it. Looks like there is no tag for it. So the mess is rolled out but no one has a chance to get a fix soon. The damaged version will spread all distros.
I guess the problem is caused by other changes and the fix just prevents obvious crash. Id like to test it anyway but did not find any source package.
Are you sure that commit is actually related to your crash? That’s a GTK 4 commit, not a GTK 3 commit, so it’s not going to help you? (And that commit has not even been backported to GTK 4.16, so unless somebody requests a backport, it won’t be fixed until 4.18.)
That crash looks like a Java object wrapper holding on to a C object that was garbage collected on the C side. It’s unlikely to be a regression on the C side.
If you’re confident that it’s a GTK regression, then I would try bisecting GTK. That will lead to straight to the cause and then we don’t have to guess.
If you don’t want to bisect, then you could try creating a reproducer that doesn’t depend on Java, but probably a bisect would be easier.
If you don’t know how things work, I suggest to ask, instead of being snarky, and thus losing any and all chances of getting an answer from the very same people you’re asking for help.
When I say “garbage collected on the C side” I mean the C side, not Java’s GC. GObject (and thus GTK) uses reference counting for its instances, which is a form of garbage collection. If an object instance on the C side loses its last reference, the memory associated to it gets released to the OS. The fact that you see a failure here:
means that something is trying to check the type of a GObject instance and getting garbage memory instead. When dealing with language bindings around a GObject-based library, this is usually an indication of a native wrapper object holding on to memory that has been freed, mainly because the wrapper object assumed that the lifetime of the underlying C object would be longer than the lifetime of the wrapper.
okay you know your arena better.
Then it has to be a very fluent resource as it happens straight on opening the first dialog on a fresh started application.
Does bisecting mean to build check out the desired version, build that and setting the LD_LIBRARY_PATH to that specific build?
It doesn’t matter when it happens: it just need to happen once.
No.
I recommend asking the Eclipse developers, since they are the ones maintaining the SWT bindings on top of GTK, and they understand the lifetime of objects involved.
