Illegal reflective access by org.apache.flink.api.java.ClosureCleaner - flink-streaming

When I run a SocketWindowWordCount Program in Apache flink, it shows a
WARNING: Illegal reflective access by org.apache.flink.api.java.ClosureCleaner
WARNING: An illegal reflective access operation has occurred WARNING:
Illegal reflective access by org.apache.flink.api.java.ClosureCleaner
(file:/home/aman.srivastava/Downloads/flink-1.10.0/lib/flink-dist_2.11-1.10.0.jar) to field java.lang.String.value WARNING: Please consider reporting
this to the maintainers of org.apache.flink.api.java.ClosureCleaner WARNING: Use --illegal-access=warn to enable
warnings of further illegal reflective access operations WARNING: All illegal access operations will be
denied in a future release Job has been submitted with JobID
a4badaa76080e47e82a322a4e2060e45

This warning is because you probably use Java 11. Flink docs says:
These warnings are considered harmless and will be addressed in future Flink releases.
You can find more here: https://ci.apache.org/projects/flink/flink-docs-stable/release-notes/flink-1.10.html#java-11-support-flink-10725

Related

How to actually see if the compiler error is Lexical Error or Syntax Error?

Is there a way using some tool to see if some program that gave compiler error is Lexical Error or Syntax Error in C. I know mostly which errors are produced by Lexer and which by Parser, but I still have some doubts about some of the unusual cases where I'm confused which is which. So to be kind of sure I want to know that in the compilation error message, but the one I'm using (DEV C) doesn't provide much.

GCC warnings not detected in cmake debug builds, but detected in release ones

I have a cmake/gcc project in which I have enabled several warnings and the flag -Werror.
I have noticed that some warnings are detected when I use the cmake flag -DCMAKE_BUILD_TYPE=Release, but they are not when I don't apply the above cmake flag. For example, one of these warnings is:
error: ‘var_name’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
I have read here: Set CFLAGS and CXXFLAGS options using CMake that there are several CMAKE_C_FLAGS variables for different build types, for instance, CMAKE_C_FLAGS_RELEASE.
I have tried to apply those variables for release and debug builds, but this time none of the above detect the warnings I'm expecting.
What I'm missing?
CMake's default/"debug" build profile entirely disables optimization, which prevents the compiler passes that perform transformations and static analysis needed to determine that a variable is used uninitialized from ever happening. While to some extent this improves debugging experience with single-step of source lines, as you've found it hides warnings and also tends to hide consequences of undefined behavior in your code.
Traditionally "disable optimizations entirely for non-release builds" has not been a thing among unix-oriented developers. It's a carry-over from common practice in the MSVC world that's reflective of CMake's origins and user base.

Eiffel: a way to display assertion violation on runtime of executable

As I have the choice on finalizing a project to keep assertions, I'd think that assertion violation would be shown or displayed on console (hopefully on stderr on linux). What would be the proper way to do such, like seems that I have to add it or enable something to get it...
You don't have to do anything additional (at least, I've never had to). The assertion violation will result in a stack trace to stderr.

How to compile a program in C with IAR for msp430x5438A when i get the following error?

i am using IAR for msp430xf5438A and when i am trying to compile my program i get an the following error: Internal Error: [TaInstr::Validate]: Instruction does not match requirement. what can i do to solve the this error? thanx!
This is an internal error in the compiler, it is issued when one part of the compiler emits an instruction that it shouldn't have.
If you have the latest version of the compiler, make sure you report this to IAR so that they can fix it. If not, I suggest that you upgrade the compiler.
If you need to continue with the compiler you have, you could try to change the optimization levels or other settings. Alternatively, try to figure out which code triggers the problem and rewrite it.
If you can reduce the problem to a small sample, add it to your question and I'll try to suggest ways to rewrite the code.

sample rc file for splint

I am using splint for code checking, and it is throwing out a huge number of warnings. Some of them, I guess can be ignored. I am in the process of creating the .splintrc by trial and error.
My question,
Is there some sample .splintrc file that can be used?
I am using splint for C code, written for a multi-tasking embedded system.
This may not be the greatest of help but I think that you need to provide a bit more information about the type of error messages that you are getting and the target processor/compiler that you are using. The different compilers for embedded target processors all have their own syntax to provide their specific functionality (interrupt processing, transferring to supervisor modes and hardware interfacing are examples)
I have tried to use splint on the MSP430 under IAR and gave up because of the number of warnings and errors that it was throwing when it tried to process the compiler supplied hardware interface definition files. I bit the bullet and purchased Gimpel LINT which came with some configuration files that I could modify to support the precise flavour of compiler and processor I was using.
I have never worked with Splint, but have worked with PC-Lint, and this was my experience as well. Without the compiler configuration files, the lint tool will throw a ton of errors.
You will need to find or create compiler-specific configurations files for your compiler informing the linting tool of the special (non-standard) C constructs and macros that it uses which should be ignored by the linting tool, or you will continue to throw tons of errors.
It is worth the effort, however. Linting your code will help you find errors now instead of during testing when they are harder to find and much more expensive to fix.

Resources