Summary: | [GTK] compiling SWT with gcc -std=c99 leads to crash in native file dialog | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Andrey Loskutov <loskutov> | ||||
Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | alexandr.miloslavskiy, sravankumarl | ||||
Version: | 4.18 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=569872 https://bugs.eclipse.org/bugs/show_bug.cgi?id=570178 |
||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Andrey Loskutov
2020-12-22 08:16:10 EST
Detailed steps to reproduce. Open /org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh Apply this patch: ################################################### diff --git a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh index 0490465..61f0144 100755 --- a/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh +++ b/bundles/org.eclipse.swt/Eclipse SWT PI/gtk/library/build.sh @@ -118,3 +118,3 @@ if [ "${CC}" = "" ]; then - export CC=gcc + export CC="gcc -std=c99" fi ################################################### Open org.eclipse.swt.gtk.linux.x86_64 project in workspace. cd org.eclipse.swt/bin/library make clean ; ./build.sh -gtk3 install Refresh org.eclipse.swt.gtk.linux.x86_64 project in Eclipse. Start Eclipse SDK from debugger. Go to "File -> Open File" Observe JVM crash. I'm using GTK gtk3-3.22.30-3.el7.x86_64 on RHEL 7.4. (In reply to Andrey Loskutov from comment #1) > > Open org.eclipse.swt.gtk.linux.x86_64 project in workspace. > cd org.eclipse.swt/bin/library > make clean ; ./build.sh -gtk3 install > Refresh org.eclipse.swt.gtk.linux.x86_64 project in Eclipse. these steps can be replaced with this Open org.eclipse.swt.gtk.linux.x86_64 project in workspace perform an ant build on org.eclipse.swt.gtk.linux.x86_64/build.xml with target "build_libraries" This will build swt libraries and refreshes the workspace. The first thing I encountered was a large swarm of compiler warnings, I made Bug Bug 570178 to fix that. Among these warnings, there was also a warning relevant to the new '-std=c99': ---- c.c: In function ‘Java_org_eclipse_swt_internal_C_setenv’: c.c:338:13: warning: implicit declaration of function ‘setenv’; did you mean ‘getenv’? [-Wimplicit-function-declaration] 338 | rc = (jint)setenv((const char *)lparg0, (const char *)lparg1, arg2); | ^~~~~~ | getenv ---- I'm still investigating. Turns out that 'setenv()' problem is boring because it's not currently used in SWT. Unfortunately I'm not able to reproduce the problem on my Ubuntu 20.04. My steps: 1) Reverted commit de804534 to restore '-std=c99' 2) Built native libraries and made sure that '-std=c99' is present in compiler console output 3) Tried 'File | Open file' 4) Tried 'File | Open Projects from filesystem | Directory...' I managed to reproduce a very similar crash when I mistakenly built/replaced native libraries while Eclipse was already running with DirectoryDialog open. Andrey, is it possible that you did the same thing? Replacing binaries from under a running process is not fair, of course. Can anyone confirm that the problem is reproducible? (In reply to Alexandr Miloslavskiy from comment #4) > Can anyone confirm that the problem is reproducible? Please try this build: https://download.eclipse.org/eclipse/downloads/drops4/I20201221-1800/ Start SDK and try to use File -> Open. I can reproduce the crash on RHEL 7.4 / GTK 3.22. May be this RHEL has too old standard C library or something like this. Interesting, with this build I also get the crash on my Ubuntu 20.04. I'll continue investigating, thanks! This happens because the binaries are compiled in a weird way. The culprit in faulty build is this part of compiled 'Java_org_eclipse_swt_internal_gtk_OS_realpath' in native library: ---- call 0x7f7d4e535400 <realpath@plt> movsxd r14,eax ---- When translated to human language, it means that compiler believes that realpath() returns (4-byte signed int) instead of (8-byte unsigned pointer). When I build on my Ubuntu 20.04, I get the expected result: ---- call 0x7fffcc6f9570 <realpath@plt> mov r14,rax ---- And the crashes are not reproducible. Going to try on CentOS 7. Alrighty, on CentOS 7 building the native libraries spits another warning: ---- os.c: In function 'Java_org_eclipse_swt_internal_gtk_OS_realpath': os.c:20127:2: warning: implicit declaration of function 'realpath' [-Wimplicit-function-declaration] rc = (jlong)realpath((const char *)lparg0, (char *)lparg1); ---- To my understanding: 1) gcc defaults to '-std=gnu90', which also defines '_POSIX_C_SOURCE', which makes POSIX apis like 'realpath' visible. 2) with '-std=c99' specified, POSIX apis are no longer visible. 3) When C compiler encounters unknown function, it implicitly-declares it as a function returning int. I never understood this behavior, but oh well, compatibility... 4) Function actually returns a pointer, which now gets halved into a 4-byte signed int, discarding the other 4 bytes. It seems that I did the right move in Bug 570178 where the final patch forces all warnings to be errors. Go vote for it ;) |