[Gtk3] Fix crash in TreeItem.setImage#3262
Conversation
Test Results (linux) 94 files 94 suites 14m 23s ⏱️ Results for commit 558b268. ♻️ This comment has been updated with latest results. |
|
@basilevs Can you still reproduce this problem and test the PR? |
I would need Linux SWT JARs built from this to reproduce. |
|
You can see them at https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-3262/1/ |
And where to get matching org.eclipse.swt_*.jar (cross-platform part)? |
I've used https://github.com/basilevs/bug_678/tree/main to reproduce SIGSEGV on:
from https://download.eclipse.org/staging/2026-06/plugins/ I've then replaced org.eclipse.swt.gtk.linux.x86_64_3.134.0.v20260402-1432.jar with https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-3262/1/artifact/eclipse.platform.swt/binaries/org.eclipse.swt.gtk.linux.x86_64/target/org.eclipse.swt.gtk.linux.x86_64-3.134.0-SNAPSHOT.jar and the test passed. I think this check is invalid, as there is a version mismatch between the two JARS. |
|
Using https://bugzillaattachments.eclipsecontent.org/bugs/attachment.cgi?id=260547 I can see no slowdown measured. |
|
#3263 will allow getting swt host jar too. |
Calling createRenderers() (which invokes gtk_tree_view_column_clear()) is unsafe when setImage() call originates from a SWT.SetData listener, because GTK is currently iterating the column's cell renderer list inside gtk_tree_view_column_cell_set_cell_data(). This frees that list while GTK still holds a pointer into it, causing a use-after-free SIGSEGV on GTK3 (eclipse-platform#678 ). Instead, toggle the fixed-height-mode GObject property off and back on. This resets GTK's cached row height (fixed_height = -1) and schedules an async widget resize, so GTK will re-measure on the next layout pass and pick up the updated renderer size. Unlike gtk_tree_view_column_clear(), this does not modify the renderer list and is therefore safe to call from within a cell_data_func callback. Tested that Debug and variable views don't have icons without the fixed_height_mode off/on setting and icons are fine with it.
|
So it fixes the problem for you? If you confirm that I'll merge it and it can be tested in next I-build. |
Yes, it fixes my reproduction scenario. No objections to merge from my side. |
|
Nice teamwork guys! |
|
I tried this fix too: the crash doesn't happen anymore, but images in a virtual tree as described in #1739 aren't displayed anymore at all. @akurtakov is this OK? From this removed comment chunk: * any cells, including renderers. In order to prevent
* images from disappearing/being cropped, we re-create
* the renderers when the first image is set. Fix forI get an impression that Also if I recall correctly setting |
6 participants
Calling createRenderers() (which invokes
gtk_tree_view_column_clear()) is unsafe when setImage() call originates from a SWT.SetData listener, because GTK is currently iterating the column's cell renderer list inside
gtk_tree_view_column_cell_set_cell_data().
This frees that list while GTK still holds a pointer into it, causing a use-after-free SIGSEGV on GTK3
(#678 ). Instead, toggle the fixed-height-mode GObject property off and back on. This resets GTK's cached row height (fixed_height = -1) and schedules an async widget resize, so GTK will re-measure on the next layout pass and pick up the updated renderer size. Unlike gtk_tree_view_column_clear(), this does not modify the renderer list and is therefore safe to call from within a cell_data_func callback.
Tested that Debug and variable views don't have icons without the fixed_height_mode off/on setting and icons are fine with it.