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

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

Closed
wants to merge 2 commits into from

Conversation

@YaSuenag
Copy link
Member

@YaSuenag YaSuenag commented Mar 7, 2021

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

Download

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Mar 7, 2021

👋 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
Copy link

@openjdk openjdk bot commented Mar 7, 2021

@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.

@openjdk openjdk bot added the build label Mar 7, 2021
@YaSuenag YaSuenag marked this pull request as ready for review Mar 7, 2021
@openjdk openjdk bot added the rfr label Mar 7, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Mar 7, 2021

Webrevs

@prrace
Copy link
Contributor

@prrace prrace commented Mar 7, 2021

/label add swing

@openjdk openjdk bot added the swing label Mar 7, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Mar 7, 2021

@prrace
The swing label was successfully added.

@prrace
Copy link
Contributor

@prrace prrace commented Mar 7, 2021

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
Copy link
Member

@tstuefe tstuefe commented Mar 7, 2021

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:

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
Copy link
Member

@mrserb mrserb commented Mar 7, 2021

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
Copy link
Member Author

@YaSuenag YaSuenag commented Mar 8, 2021

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:

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

@tstuefe
Copy link
Member

@tstuefe tstuefe commented Mar 8, 2021

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
tstuefe approved these changes Mar 8, 2021
Copy link
Member

@tstuefe tstuefe left a comment

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

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

This comment has been minimized.

@tstuefe

tstuefe Mar 8, 2021
Member

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.

This comment has been minimized.

@YaSuenag

YaSuenag Mar 8, 2021
Author Member

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.

This comment has been minimized.

@mrserb

mrserb Mar 8, 2021
Member

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

This comment has been minimized.

@YaSuenag

YaSuenag Mar 9, 2021
Author Member

No, can you help?

This comment has been minimized.

@mrserb

mrserb Mar 10, 2021
Member

I'll check.

This comment has been minimized.

@mrserb

mrserb Mar 13, 2021
Member

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.

This comment has been minimized.

@mrserb

mrserb Mar 13, 2021
Member

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

This comment has been minimized.

@YaSuenag

YaSuenag Mar 13, 2021
Author Member

Thanks @mrserb for the test!

This comment has been minimized.

@pankaj-bansal

pankaj-bansal Mar 14, 2021

@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.

This comment has been minimized.

@mrserb

mrserb Mar 14, 2021
Member

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

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

This comment has been minimized.

@tstuefe

tstuefe Mar 8, 2021
Member

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).

This comment has been minimized.

@YaSuenag

YaSuenag Mar 8, 2021
Author Member

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
Copy link

@openjdk openjdk bot commented Mar 8, 2021

@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.

@openjdk openjdk bot added the ready label Mar 8, 2021
@YaSuenag
Copy link
Member Author

@YaSuenag YaSuenag commented Mar 9, 2021

/label remove build

@openjdk openjdk bot removed the build label Mar 9, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Mar 9, 2021

@YaSuenag
The build label was successfully removed.

@mrserb
mrserb approved these changes Mar 13, 2021
@YaSuenag
Copy link
Member Author

@YaSuenag YaSuenag commented Mar 13, 2021

/integrate

@openjdk openjdk bot closed this Mar 13, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Mar 13, 2021
@YaSuenag YaSuenag deleted the YaSuenag:JDK-8263136 branch Mar 13, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Mar 13, 2021

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants