Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[GTK3] Do not crash in SetData event #1612

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

basilevs
Copy link
Contributor

@basilevs basilevs commented Nov 22, 2024

The crash happens when renderers are replaced during render. If replacement is postponed, the crash no longer happens. The failure only happens in Ubuntu 24 (GTK 3.24.41).

Fixes #678.
Is tested by #1611.

Copy link
Contributor

github-actions bot commented Nov 22, 2024

Test Results

   483 files  ±0     483 suites  ±0   9m 13s ⏱️ +35s
 4 095 tests ±0   4 085 ✅ ±0   7 💤 ±0  3 ❌ ±0 
16 173 runs  ±0  16 080 ✅ ±0  90 💤 ±0  3 ❌ ±0 

For more details on these failures, see this check.

Results for commit 09cfb68. ± Comparison against base commit 266cc26.

♻️ This comment has been updated with latest results.

@basilevs basilevs force-pushed the issue_678_setdata_fix branch from d8ba369 to 7e7c87c Compare November 22, 2024 15:02
@basilevs
Copy link
Contributor Author

basilevs commented Nov 22, 2024

Test failures are caused by #1564

@basilevs basilevs marked this pull request as ready for review November 22, 2024 15:23
@basilevs basilevs force-pushed the issue_678_setdata_fix branch 2 times, most recently from 7c58564 to b1bf254 Compare November 25, 2024 11:28
GTK 3.24.41 (Ubuntu 24) crashes when renderers are replaced during
render.
If replacement is postponed, the crash no longer happens.

Fixes eclipse-platform#678.
@basilevs basilevs force-pushed the issue_678_setdata_fix branch from b1bf254 to 09cfb68 Compare November 25, 2024 11:48
@eselmeister
Copy link

+1

@basilevs
Copy link
Contributor Author

basilevs commented Dec 3, 2024

Converting to draft until an alternative of renderer reconfiguration instead of recreation is investigated.

@basilevs
Copy link
Contributor Author

The alternative is quite complex in comparison and does not avoid the asyncExec().

@basilevs basilevs marked this pull request as ready for review February 13, 2025 14:17
* Otherwise check-boxes will be rendered in columns they are not
* supposed to be rendered in. See bug 513761.
*/
boolean check = modelIndex == Tree.FIRST_COLUMN && (parent.style & SWT.CHECK) != 0;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't check be computed inside getDisplay ().asyncExec (...) (similarly to modelIndexAsync and columnAsync)?.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I've failed to account for column deletion. Thanks.

if (parent.isDisposed () || Math.max (1, parent.getColumnCount ()) <= index) return;
// On multiple resize requests, perform only the last one
if (parent.pixbufHeight != iHeight || parent.pixbufWidth != iWidth) return;
int modelIndexAsync = parent.columnCount == 0 ? Tree.FIRST_COLUMN : parent.columns [index].modelIndex;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that another column gets inserted at this index after this async task is scheduled but before it's actually executed?
If that's possible, then createRenderers(...) might not be executed for the original column.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's related to the bug with resizing you are trying to fix. parent.pixbufSizeSet is set only once per Tree, so the column index is not important 🤷 AFAIK, the only requirement for the column index - the column should exist.

And column may be deleted, so that's a concern worth investigating. Thanks.
The index can't be trusted here and might need to be clamped.

} else {

GTK.gtk_tree_store_set(parent.modelHandle, handle, modelIndex + Tree.CELL_PIXBUF, pixbuf, -1);
GTK.gtk_tree_store_set(parent.modelHandle, handle, modelIndex + Tree.CELL_SURFACE, surface, -1);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is interesting.
So this line was missing before, which means that TreeItem._getImage(int) always returned null.
And somehow Tree still worked.

Copy link
Contributor Author

@basilevs basilevs Feb 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was not missing. I've moved it from below to manage try-finally scope.

@zkxvh
Copy link

zkxvh commented Feb 18, 2025

Hi @basilevs.
Just FYI, I checked this PR with this snippets and (at least on my machine) this PR has no negative effects on how images gets rendered in the Tree: in all cases except one the images are rendered identically, in one case the code with this PR rendered an image, that was erroneously not rendered by the original code.

@basilevs basilevs marked this pull request as draft February 18, 2025 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SIGSEGV in Tree.cellDataProc when calling TreeItem.setImage
3 participants