SIGSEGV in swt_fixed_resize
#697
Comments
|
It appears that setting |
|
Could you please also attach the generated By the way, how did you manage to obtain a GDB stack trace? When I want that, I have to resort to complicated script that ignores JRE internal exceptions but not the "fatal" exceptions |
|
Tomorrow perhaps. |
Somehow this idea never crossed my mind. Thanks! |
|
Here is the stack trace from the --------------- T H R E A D ---------------Let me know if you need any other part of that file. |
|
Thanks for the Java stack. For some reason, I have checked crash database for our product (it's based on SWT without Eclipse) and it has exactly zero crash reports like this. So it seems that some special conditions are needed. I guess that some repro steps would be needed to proceed here. |
|
Alright, I wanted to spare you of it, but here is a reproduction procedure: In a basic, fresh Ubuntu 23.04 installation (in a VM for example):
sudo apt install -y pkg-config make build-essential bison flex python3-pip
python3 -m pip install --break-system-packages numpy scipy pandas matplotlib posix_ipc
tar xzf 230627-3194d1c337-omnetpp-7.0.0pre2-linux-x86_64.tgz
cd omnetpp-7.0.0pre2/
source setenv
./configure WITH_QTENV=no WITH_OSG=no WITH_OSGEARTH=no WITH_PYTHONSIM=no WITH_BACKTRACE=no
make utils
omnetpp
|
|
These steps are asking too much. It would be best to come up with simpler (ideally a pure Java/SWT snippet with main method) reproducer. Learning a whole new project details to debug an issue is not something that many will spend their time on. |
I thought so too, but this is the best I have at the moment...
Of course, and I was glad that I managed to make one for #678. |
|
While I don't yet have a minimal reproducer, I got a message just before crashing that may or may not be relevant: |
|
I have good news, and bad news. The good news is that I managed to get a reproducer snippet that is completely independent of our product, and is only about 80 lines of code (of which only 20 is really interesting). CrashyEditor.javapackage crashyeditor;
import org.eclipse.core.runtime.IProgressMonitor;
import org.eclipse.swt.SWT;
import org.eclipse.swt.events.ControlListener;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Table;
import org.eclipse.swt.widgets.TableColumn;
import org.eclipse.ui.IEditorInput;
import org.eclipse.ui.IEditorSite;
import org.eclipse.ui.PartInitException;
import org.eclipse.ui.part.EditorPart;
public class CrashyEditor extends EditorPart {
// -------- start debugging stuff --------
static int callDepth = 0;
void runWithLogging(String label, Runnable r) {
System.out.println(" ".repeat(callDepth) + "> " + label + " (" + this + ")");
callDepth += 1;
r.run();
callDepth -= 1;
System.out.println(" ".repeat(callDepth) + "< " + label + " (" + this + ")");
}
// -------- end debugging stuff --------
@Override
public void createPartControl(Composite parent) {
runWithLogging("createPartControl " + parent.getSize() + " " + parent.getLayout(), () -> {
Composite composite = new Composite(parent, SWT.NONE);
Table table = new Table(composite, SWT.NONE);
table.setHeaderVisible(true);
TableColumn column = new TableColumn(table, SWT.NONE);
column.addControlListener(ControlListener
.controlResizedAdapter((e) -> runWithLogging("column.controlResized " + column.getWidth(), () -> {
table.setSize(20, 20);
composite.setSize(composite.computeSize(SWT.DEFAULT, SWT.DEFAULT));
})));
column.setWidth(10);
});
}
// -------- start filler stuff --------
@Override
public void init(IEditorSite site, IEditorInput input) throws PartInitException {
setSite(site);
setInput(input);
}
@Override
public void doSave(IProgressMonitor monitor) {
}
@Override
public void doSaveAs() {
}
@Override
public boolean isDirty() {
return false;
}
@Override
public boolean isSaveAsAllowed() {
return false;
}
@Override
public void setFocus() {
}
// -------- end filler stuff --------
}The bad news is that this is still an Eclipse plugin, not a standalone SWT application. I tried really hard, but could not get this crash outside of Eclipse yet. So the new reproduction procedure is:
I know this is still a lot more convoluted than simply running a short Java program, but I am really having a hard time further reducing it. |
|
Note that I have edited the above comment multiple times with newer and newer (more and more minimal) versions of |
|
I will try to have a look at this when I have time. Hopefully, but no promises, next week. |
|
This is how the problem develops, SWT invalidates style at a wrong time: That is, in order to create SWT snippet, However, even armed with this knowledge, I was still not able to make a snippet to reproduce. For some reason, |
|
I'm glad you were able to reproduce the crash at least with
Do you have any ideas for a simple workaround perhaps? Can I further assist fixing this in any way? |
|
I plan to spend some more time to investigate. Hopefully this week. |
|
Spent some more time on it, still can't reproduce in a snippet. My snippet does something slightly different compared to Eclipse, and debugging mixed Java/native callstack is hard. But I think I finally found how to walk both stacks in GDB. Hopefully next time I will finally find how exactly Eclipse is triggering the style to be deallocated. |
|
I reported a GTK bug: https://gitlab.gnome.org/GNOME/gtk/-/issues/6240 |
|
Even after making a native snippet that reproduces the problem, I still can't reproduce it in a pure SWT snippet. The problem is quite elusive and depends on specific Control being contained in specific parent. GTK bug is triggered when SWT uses
SWT uses
In your specific case, the chain is |
SyntevoAlex
added a commit
to syntevo/eclipse.platform.swt
that referenced
this issue
Nov 28, 2023
GTK sources say: Deprecated: 3.12: Style contexts are invalidated automatically. https://www.eclipse.org/swt/faq.php#gtkstartup says: Eclipse/SWT 4.16.x: GTK+ 3.20.0 and its dependencies Eclipse/SWT 4.15.x: GTK+ 3.14.0 and its dependencies This means that it's been at least 3 years since SWT requires GTK 3.20. Sounds safe to stop using the deprecated function now. Hopefully fixes eclipse-platform#697 I couldn't reproduce it in SWT snippet, so I didn't test this with SWT. But when I tested in native snippet, removing `gtk_style_context_invalidate()` changed things a bit and crash no longer occurred. Signed-off-by: Alexandr Miloslavskiy <[email protected]>
SyntevoAlex
added a commit
to syntevo/eclipse.platform.swt
that referenced
this issue
Nov 28, 2023
GTK sources say: Deprecated: 3.12: Style contexts are invalidated automatically. https://www.eclipse.org/swt/faq.php#gtkstartup says: Eclipse/SWT 4.16.x: GTK+ 3.20.0 and its dependencies Eclipse/SWT 4.15.x: GTK+ 3.14.0 and its dependencies This means that it's been at least 3 years since SWT requires GTK 3.20. Sounds safe to stop using the deprecated function now. Hopefully fixes eclipse-platform#697 I couldn't reproduce it in SWT snippet, so I didn't test this with SWT. But when I tested in native snippet, removing `gtk_style_context_invalidate()` changed things a bit and crash no longer occurred. Signed-off-by: Alexandr Miloslavskiy <[email protected]>
|
Finally managed to reproduce with SWT snippet final Display display = new Display();
final Shell shell = new Shell(display);
shell.setLayout (new GridLayout(1, true));
Label hint = new Label(shell, 0);
hint.setText(
"1. Run on Linux\n" +
"2. Run with these to make crash easier to see:\n" +
" export G_SLICE=always-malloc\n" +
" export ALLOC_MMAP_THRESHOLD_=512\n" +
"3. Click button many times\n" +
"4. Issue #697: JVM will crash"
);
Button button = new Button(shell, SWT.PUSH);
button.setText("Test");
button.addListener(SWT.Selection, e -> {
Composite parent = shell;
Table table = new Table(parent, SWT.NONE);
table.setHeaderVisible(true);
TableColumn column = new TableColumn(table, SWT.NONE);
column.addListener(SWT.Resize, e2 -> {
table.setSize(20, 20);
parent.setSize(parent.computeSize(SWT.DEFAULT, SWT.DEFAULT));
});
column.setWidth(10);
});
int numColor[] = new int[1];
display.addListener(SWT.Skin, e -> {
numColor[0]++;
int color1 = (0x30 + numColor[0]) % 256;
int color2 = (0xD0 + numColor[0]) % 256;
Color backColor = new Color(color1, color1, color1);
Color foreColor = new Color(color2, color2, color2);
shell.setBackground(backColor);
shell.setForeground(foreColor);
});
shell.setSize(400, 300);
shell.open();
while (!shell.isDisposed()) {
if (!display.readAndDispatch()) {
display.sleep();
}
}
display.dispose(); |
|
GTK replied (interpretation mine) that while it's a bug, they don't find it worthy to fix it and would rather state that we shouldn't restyle or resize anything during In SWT terms it means to not resize anything during |
|
Thank you for getting to the bottom of this! |
|
Thank you too for your effort to provide a small reproducing example! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Segmentation fault.
To Reproduce
I don't have a minimal reproducer yet sadly.
Expected behavior
No crash.
Screenshots
Not really applicable.
Environment:
Ubuntu 23.04, GTK 3.24.37
JustJ Adoptium OpenJDK Hotspot JRE 17.0.7, Eclipse 4.27.0
Workaround (or) Additional context
Couldn't find a workaround yet.
The text was updated successfully, but these errors were encountered: