8263136: C4530 was reported from VS 2019 at access bridge #2859

YaSuenag · 2021-03-07T03:18:53Z

I saw C4530 with VS 2019 (16.9.0) as following (on Japanese locale):

AccessBridgeDebug.cpp
メモ: インクルード ファイル: d:\github-forked\jdk\src\jdk.accessibility\windows\native\common\AccessBridgeDebug.h

    :

c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): error C2220: 次の警
告はエラーとして処理されます
c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\ostream(611): warning C4530: C++
例外処理を使っていますが、アンワインド セマンティクスは有効にはなりません。/EHsc を指定してください。
メモ: インクルード ファイル: c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\string

/EHsc has been already passed in other makefiles, and also AccessBridgeDebug.cpp uses some STL classes (e.g. chrono namespace). So /EHsc is a solution for this problem.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8263136: C4530 was reported from VS 2019 at access bridge

Reviewers

Thomas Stuefe (@tstuefe - Reviewer)
Sergey Bylokhov (@mrserb - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/2859/head:pull/2859
$ git checkout pull/2859

bridgekeeper · 2021-03-07T03:19:38Z

👋 Welcome back ysuenaga! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-03-07T03:20:43Z

@YaSuenag The following label will be automatically applied to this pull request:

build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-03-07T06:39:16Z

Webrevs

01: Full - Incremental (4a357eb)
00: Full (f68a128)

prrace · 2021-03-07T16:15:29Z

/label add swing

openjdk · 2021-03-07T16:15:43Z

@prrace
The swing label was successfully added.

prrace · 2021-03-07T16:19:15Z

translate.google.com says the error in (almost) English is :
c: \ program ~ 2 \ micros ~ 2 \ 2019 \ commun ~ 1 \ vc \ tools \ msvc \ 1428 ~ 1.299 \ include \ ostream (611): warning C4530: C ++
I'm using exception handling, but unwind semantics aren't enabled. Please specify / EHsc.

tstuefe · 2021-03-07T19:34:36Z

Yes, including c++ standard library headers like means you need to deal with C++ exceptions thrown from library functions, and the code needs to be compiled with unwind capabilities. If its not switched on, and a C++ exception happens, the behavior is undefined. In my experience it results in the process being terminated.

I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.

Adding /Ehsc is fine of course, but I think thats not enough. Now C++ exceptions can pass through the code, but if they do, then what? E.g. this function getTimeStamp() added with 8196681:

jdk/src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp

Line 85 in 113b518

auto getTimeStamp() -> long long {

calls into the C++ standard library to get a time stamp. Can't these function not throw C++ exceptions? Is that not what the compiler is warning about? If they throw, exceptions propagate through the code unbounded, until they either end the process or cause havoc at the next upper C-only-interface.

Or, maybe, rewrite this coding to use standard C- and Windows-APIs. I think 8196681 could had been done with traditional windows- or standard C APIs. In particular, getTimeStamp() could probably be done simply with GetTickCount or GetSystemTime or functions from time.h.

Cheers, Thomas

mrserb · 2021-03-07T22:00:41Z

I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.

After that discussion the usage of "string.h"/etc was dropped and "C string manipulation API" was used instead, and that suppressed the warning. I do not know why it was not complaining about "getTimeStamp". I think the fix should refactor the code again.

YaSuenag · 2021-03-08T00:58:41Z

Thank you for comments! I refactored getTimeStamp() not to use STL functions in new commit. The error messages have gone without /EHsc.
I use 11644473600000ULL to rebase Epoch from 1601 to 1970, it comes from ProcessHandleImpl_win.c:

jdk/src/java.base/windows/native/libjava/ProcessHandleImpl_win.c

Line 342 in 22a3117

start -= 11644473600000L; // Rebase Epoch from 1601 to 1970

tstuefe · 2021-03-08T06:25:30Z

I wondered why C++ std headers are even used. The source code looks C-ish; but "8196681: Java Access Bridge logging and debug flags dynamically controlled" added some coding, adding a bunch of C++11x semantics and included C++ std headers. Using "/Ehsc" had even been discussed: https://mail.openjdk.java.net/pipermail/awt-dev/2018-December/014847.html but not done.

After that discussion the usage of "string.h"/etc was dropped and "C string manipulation API" was used instead, and that suppressed the warning. I do not know why it was not complaining about "getTimeStamp". I think the fix should refactor the code again.

Ah, I missed that part. Thanks for clarifying the history :)

tstuefe

Hi Yasumasa,

small nits below. But this looks fine to me as it is already so I leave it up to you and the others whether to change anything. Thank you for taking my suggestion.

Cheers, Thomas

tstuefe · 2021-03-08T06:34:26Z

src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp

+    GetSystemTimeAsFileTime(&ft);
+    uli.LowPart = ft.dwLowDateTime;
+    uli.HighPart = ft.dwHighDateTime;
+    return (uli.QuadPart / 10000ULL) - 11644473600000ULL; // Rebase Epoch from 1601 to 1970


This is good and true to the original change;

I am not even sure the epoch rebase is needed. All 8196681 did was to print out the timestamps verbatim. I do not know enough about how that debug trace is used, and if the timestamps really have to be 1970 based.

It seems to be fine not to use UNIX epoch at first glance as long as we can know the timing of events, but I'm not sure (Thus I rewrote to comply with the original code). So I want to hear from the others.

Did you check via some a11y tool that the new code actually works?

No, can you help?

I'll check.

This change looks fine, I was able to see the proper logs in the java_access_bridge.log, but I cannot find the logs from the windows_access_bridge.log. It seems unrelated to this fix. @pankaj-bansal please take a look at why the windows log might be missed if "JAVA_ACCESSBRIDGE_LOGDIR" is set.

For the record: the jaws J2021.2102.34.400 was used for testing.

Thanks @mrserb for the test!

@mrserb Did you close the JAWS after running the program. I have seen that the logs for windows_access_bridge are flushed only after the JAWS is closed.

Nope! thank you for confirmation that win logs it works as well.

tstuefe · 2021-03-08T06:37:07Z

src/jdk.accessibility/windows/native/common/AccessBridgeDebug.cpp

@@ -32,7 +32,6 @@
 #include <stdio.h>
 #include <windows.h>
 #include <cstdlib>
-#include <chrono>
 #include <cstring>


Matter of taste, but I would prefer stdlib.h and string.h instead of cxxx. Just to keep in line with the rest of the coding. Weird mix of styles otherwise (I mean this code still uses 16bit era Windows APIs).

AccessBridgeDebug has .cpp in its extension, so the compiler can handle it as C++ code, and also "cstring" seems to be prefer to "string.h" in @mrserb 's comment. It's nature to use "cstring" in C++ source code IMHO. Let's see comments from the others.

openjdk · 2021-03-08T06:39:04Z

@YaSuenag This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8263136: C4530 was reported from VS 2019 at access bridge

Reviewed-by: stuefe, serb

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 93 new commits pushed to the master branch:

0b68ced: 8263548: runtime/cds/appcds/SharedRegionAlignmentTest.java fails to compile after JDK-8263412
43524cc: 8243455: Many SA tests can fail due to trying to get the stack trace of an active method
e834f99: 8263412: ClassFileInstaller can't be used by classes outside of default package
bf9b5fa: 8263501: compiler/oracle/TestInvalidCompileCommand.java fails with release VMs
0c8350e: 8263460: DynamicArchiveRelocationTest.java fails in product VM
b2f7c58: 8263055: hsdb Command Line Debugger does not properly direct output for some commands
ecfa712: 8263326: Remove ReceiverTypeData check from serviceability/sa/TestPrintMdo.java
b932a62: 8263470: Consolidate copies of getClassBytes in various tests
0ea48d9: 8194129: Regression automated Test '/open/test/jdk/java/awt/Window/ShapedAndTranslucentWindows/TranslucentChoice.java' fails
4b5c664: 8178348: left_n_bits(0) invokes undefined behavior
... and 83 more: https://git.openjdk.java.net/jdk/compare/e1cad97049642ab201d53ff608937f7e7ef3ff3e...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

YaSuenag · 2021-03-09T01:00:51Z

/label remove build

openjdk · 2021-03-09T01:01:01Z

@YaSuenag
The build label was successfully removed.

YaSuenag · 2021-03-13T09:41:23Z

/integrate

openjdk · 2021-03-13T09:42:12Z

@YaSuenag Since your change was applied there have been 95 commits pushed to the master branch:

a528771: 8262491: AArch64: CPU description should contain compatible board list
86e4c75: 8256156: JFR: Allow 'jfr' tool to show metadata without a recording
0b68ced: 8263548: runtime/cds/appcds/SharedRegionAlignmentTest.java fails to compile after JDK-8263412
43524cc: 8243455: Many SA tests can fail due to trying to get the stack trace of an active method
e834f99: 8263412: ClassFileInstaller can't be used by classes outside of default package
bf9b5fa: 8263501: compiler/oracle/TestInvalidCompileCommand.java fails with release VMs
0c8350e: 8263460: DynamicArchiveRelocationTest.java fails in product VM
b2f7c58: 8263055: hsdb Command Line Debugger does not properly direct output for some commands
ecfa712: 8263326: Remove ReceiverTypeData check from serviceability/sa/TestPrintMdo.java
b932a62: 8263470: Consolidate copies of getClassBytes in various tests
... and 85 more: https://git.openjdk.java.net/jdk/compare/e1cad97049642ab201d53ff608937f7e7ef3ff3e...master

Your commit was automatically rebased without conflicts.

Pushed as commit d339320.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8263136: C4530 was reported from VS 2019 at access bridge

f68a128

openjdk bot added the build build-dev@openjdk.org label Mar 7, 2021

YaSuenag marked this pull request as ready for review March 7, 2021 06:36

openjdk bot added the rfr Pull request is ready for review label Mar 7, 2021

openjdk bot added the swing client-libs-dev@openjdk.org label Mar 7, 2021

Refactoring

4a357eb

tstuefe approved these changes Mar 8, 2021

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Mar 8, 2021

openjdk bot removed the build build-dev@openjdk.org label Mar 9, 2021

mrserb approved these changes Mar 13, 2021

View reviewed changes

openjdk bot closed this Mar 13, 2021

openjdk bot added integrated Pull request has been integrated and removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Mar 13, 2021

YaSuenag deleted the JDK-8263136 branch March 13, 2021 09:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8263136: C4530 was reported from VS 2019 at access bridge #2859

8263136: C4530 was reported from VS 2019 at access bridge #2859

YaSuenag commented Mar 7, 2021 •

edited by openjdk bot

Loading

bridgekeeper bot commented Mar 7, 2021

openjdk bot commented Mar 7, 2021

mlbridge bot commented Mar 7, 2021 •

edited

Loading

prrace commented Mar 7, 2021

openjdk bot commented Mar 7, 2021

prrace commented Mar 7, 2021

tstuefe commented Mar 7, 2021

mrserb commented Mar 7, 2021

YaSuenag commented Mar 8, 2021

tstuefe commented Mar 8, 2021

tstuefe left a comment

tstuefe Mar 8, 2021

YaSuenag Mar 8, 2021

mrserb Mar 8, 2021

YaSuenag Mar 9, 2021

mrserb Mar 10, 2021

mrserb Mar 13, 2021

mrserb Mar 13, 2021

YaSuenag Mar 13, 2021

pankaj-bansal Mar 14, 2021

mrserb Mar 14, 2021

tstuefe Mar 8, 2021

YaSuenag Mar 8, 2021

openjdk bot commented Mar 8, 2021 •

edited

Loading

YaSuenag commented Mar 9, 2021

openjdk bot commented Mar 9, 2021

YaSuenag commented Mar 13, 2021

openjdk bot commented Mar 13, 2021

8263136: C4530 was reported from VS 2019 at access bridge #2859

8263136: C4530 was reported from VS 2019 at access bridge #2859

Conversation

YaSuenag commented Mar 7, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Download

bridgekeeper bot commented Mar 7, 2021

openjdk bot commented Mar 7, 2021

mlbridge bot commented Mar 7, 2021 • edited Loading

Webrevs

prrace commented Mar 7, 2021

openjdk bot commented Mar 7, 2021

prrace commented Mar 7, 2021

tstuefe commented Mar 7, 2021

mrserb commented Mar 7, 2021

YaSuenag commented Mar 8, 2021

tstuefe commented Mar 8, 2021

tstuefe left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

openjdk bot commented Mar 8, 2021 • edited Loading

YaSuenag commented Mar 9, 2021

openjdk bot commented Mar 9, 2021

YaSuenag commented Mar 13, 2021

openjdk bot commented Mar 13, 2021

YaSuenag commented Mar 7, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Mar 7, 2021 •

edited

Loading

openjdk bot commented Mar 8, 2021 •

edited

Loading