Warning: undefined callback function terminate/3 (behaviour 'gen_statem')** - erlang

How serious is this warning? Can I use this module with this warning? What the side-effects of this warning.
Warning: undefined callback function terminate/3 (behaviour
'gen_statem')**
Erlang/OTP: 19.0.7
git clone https://github.com/inaka/apns4erl.git
cd apns4erl/
wget https://s3.amazonaws.com/rebar3/rebar3 && chmod +x rebar3
./rebar3 compile
===> Fetching coveralls v2.2.0
===> Fetching jsx v2.10.0
===> Analyzing applications...
===> Compiling jsx
===> Compiling coveralls
===> Verifying dependencies...
===> Fetching base64url v1.0.1
===> Fetching gun v1.3.3
===> Fetching jsx v3.0.0
===> Fetching cowlib v2.7.3
===> Analyzing applications...
===> Compiling cowlib
===> Compiling base64url
===> Compiling gun
===> Compiling jsx
===> Analyzing applications...
===> Compiling apns
**src/apns_connection.erl:22: Warning: undefined callback function terminate/3 (behaviour 'gen_statem')**

How serious is this warning?
A function that is supposed to be defined is not there.
Can I use this module with this warning?
Supervisors use the terminate() function to shut down a child process when necessary. If the child process never needs shutting down, then you are good.
You could add a do nothing terminate function to the source code:
terminate(_Reason, _State, _Data) -> ok.
But, a better option might be to report the error to the github repository and hopefully they will make a quick fix to the code.
Or, you could try upgrading your erlang version. In newer erlang versions, the terminate() function is automatically defined for you.
What the side-effects of this warning.
Your program crashes at some point.

In Erlang/OTP 19.3 and later, as a result of this change, the terminate/3 callback is optional for gen_statem. As stated in the documentation:
This callback is optional, so callback modules need not export it. The gen_statem module provides a default implementation without cleanup.
So let's figure out what the consequences are of not including this function in earlier versions. According to the documentation, the terminate function would be called in three different cases:
another callback function has returned a stop tuple {stop,Reason} in Actions
the gen_statem is part of a supervision tree and is ordered by its supervisor to terminate (only if the gen_statem has been set to trap exit signals, and the shutdown strategy is not brutal_kill)
the process receives an 'EXIT' message from its parent
It's certainly imaginable that none of those situations would arise for a particular gen_statem, and thus the lack of a terminate function would have no negative consequences. In the worst case, the terminate function would be called when the process was already about to exit, thus terminating the process with a different exit reason than the original one, hiding the cause of the original problem.

Related

RcppArmadillo undefined symbol: dpotrf_ in Travis build

I have looked at many other posts related to this issue and have tried each solution. None have worked in my case, including copying over the makevars from Rcpp. Anyhow, when building on Travis I get the following error
undefined symbol: dpotrf_’
The interesting note is that the package installs fine on windows, macOS, and linux.
here is my repo R package
I can reproduce the failure on a very standard Debian testing system (which I use for the extensive reverse dependency checks on Rcpp and RcppArmadillo).
After installing packages bain and BFpack (I had the rest) I attempted to build the tar.gz from your pristine just-checked-out sources. And I get:
*** installing help indices
*** copying figures
** building package indices
** testing if installed package can be loaded from temporary location
Error: package or namespace load failed for ‘BGGM’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so':
/tmp/Rinst106c6ed5251a/00LOCK-BGGM/00new/BGGM/libs/BGGM.so: undefined symbol: dpotrf_
Error: loading failed
Execution halted
ERROR: loading failed
* removing ‘/tmp/Rinst106c6ed5251a/BGGM’
-----------------------------------
ERROR: package installation failed
This appears to be a moderately complex and large enough package so please pardon me for not diving in and debugging. I would suggest you simplify with smaller mock packages to see what may be wrong. (dpotrf is a fairly standard LAPACK routine so something somewhere calls it. Maybe you call it explicitly. Maybe you did a Fortran-to-C mapping wrong. Maybe you have something wrong in how you interface with RcppArmadillo. Hard to tell...)
Edit: You committed compiled code and a Windows library. "Don't do that." When Travis builds it also starts from a git checkout as I did. That may be the difference.
Edit 2: It wasn't, but your R code mixes .Call() with generated entry points (ie via RcppExports.cpp and RcppExports.R). I have seen that blow up for other people. That may be something to look into.
Disclaimer: I work with D_Williams, but I figured out the problem, and others may find it useful.
A functioning configure.ac was present, and a Makevars.in is present.
The problem is that the configure file was not yet generated. This is an autotools/autoconf setup. To resolve it, I ran autoconf in the package directory, which generated the configure file. That configure file is then executed when R builds the package. The configure file modifies the Makevars.in and creates Makevars. That Makevars file ultimately defines where to find libraries, includes, compilers, compiler options, etc.
If you do not generate the configure file from configure.ac using autoconf, then there is no configure file to be executed, and no Makevars to define the needed options at compile time. Therefore, the compiler is not fully configured, and it will fail.
TLDR: If you have an configure.ac, you must run autoconf on it, and commit that configure file to your repo. R needs to execute it to have a functioning Makevars.

Load/Recompile Rebar Modules after downgrading Erlang/OTP

I wish to use an erlang client library to communicate with an mqtt broker for one of my projects. So I've started an application using rebar3's built-in templates and added emqttc as a dependency. Since erlang/otp 21 does not have support for gen_logger(emqttc depends on gen_logger) and the tuple_calls compiler options do not suffice, I had to downgrade to erlang#20 according to this post.
Now the issue with downgrading erlang is that, none of rebar3's commands(clean/compile/shell/report etc) work as expected and my previous projects built with rebar3 do not compile, I get to see this error message:
=ERROR REPORT==== 21-Aug-2018::12:54:29 === Loading of /usr/local/bin/rebar3/rebar/ebin/rebar3.beam failed: badfile escript:
exception error: undefined function rebar3:main/1 in function
escript:run/2 (escript.erl, line 759) in call from escript:start/1
(escript.erl, line 277) in call from init:start_em/1 in call from
init:do_boot/3
=ERROR REPORT==== 21-Aug-2018::12:54:29 === beam/beam_load.c(1863): Error loading module rebar3: This BEAM file was compiled for a later
version of the run-time system than 20. To fix this, please
recompile this module with an 20 compiler. (Use of opcode 160; this
emulator supports only up to 159.)
I've uninstalled and reinstalled rebar3, looked up on the web for this but nothing's clear and specific to rebar. Any help on this would be appreciated.
This may not be the exact answer for your question. But it may give you and idea.
What about using Docker. Its an easy way to keep your environment clean and neat.
If you use docker, you just have to include your new erlang version in Dockerfile as an environment variable.
ENV OTP_VERSION="20.3.6"
Check your _build/prod/rel/YOURAPPNAME/ directory. Most probably it has a release which doesn't match your erlang version. You can safely delete this directory and rebuild using rebar3 compile

Jenkins & Sonarqube - Illegal Reflect

I try to analyse a .net project with jenkins & sonarqube.
When I try to analyze the project localy on my workstation without jenkins the analysis works and the results are uploaded and displayed in sonarqube.
When I use jenkins in combination with sonar msbuild and execute the very same cmd I get the error message
: WARNING: An illegal reflective access operation has occurred
WARNING: WARNING: Illegal reflective access by net.sf.cglib.core.ReflectUtils$1 (file:/C:/Users/xyz/.sonar/cache/132aaa5c3a6da2c09af83d327b1fc182/sonar-javascript-plugin-4.1.0.6085.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: WARNING: Please consider reporting this to the maintainers of net.sf.cglib.core.ReflectUtils$1
WARNING: WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: WARNING: All illegal access operations will be denied in a future release
WARNING: WARN: Analyzer working directory does not exist: 'D:\Jenkins\workspace\GLB\.sonarqube\out\2\output-cs'. Analyzer results won't be loaded from this directory.
As far as I could see this is the only difference between the local working version vs. the not working version via jenkins.
I already invested a lot of time in investigating and research but did not find a solution for that.
kind regards
It's not your fault.
Please check following reply on GitHub - https://github.com/SonarSource/SonarJS/issues/1110
Hello,
as you note, this is just a warning and it can be safely ignored. We cannot fix this warning easily, because it's a dependency of our parser which would need fixing. However we started migration to another parser in 5.0 and gradually we will migrate all rules to the new parser. This will eventually allow to drop dependency on sslr and fix the warning
this issue encountered because of space issue on the device.
check where this service running,
df -h
if there is space issue exist,
remove unused files.

How can I get eredis to compile?

I am new to the world of erlang and phoenix. Anyways, I am trying to figure out a compiling issue and I have hit wits end for now.
I will do my best to provide as much information as possible to help with this problem. If I've missed anything just let me know.
When running the command mix deps.get everything is compiled properly from my mix.exs.
However, once I run mix conform.configure
I get the error:
==> eredis (compile)
include/eredis_sub.hrl:19: type queue() undefined
** (Mix) Could not compile dependency eredis, /usr/bin/rebar command failed. If you want to recompile this dependency, please run: mix deps.compile eredis
Running mix dep.compile eredis produces the same error as above.
Oh and I am running erlang 18. Any help would be greatly appreciated.
Thanks.
Either use v17, or change to queue:queue().
Use rebar compile instead of make. Makefile of eredis is broken. They are probably using eredis exclusively as subproject and is no longer compiled using make.
And as well update to at least v1.7.0 but preferably v1.0.8.

Doing an "offline" erlang OTP release upgrade

I'm working on a project that deals heavily with OTP releases and their upgrade process.
I managed to perform hot upgrades from a release upgrade archive (tar.gz) using release_handler functions unpack_release, install_release and make_permanent. They are all invoked in the very node that is being upgraded.
Now I have to deal with a situation where the erlang node is down and I have to do an "offline" upgrade. Essentially what I want to achieve is to unpack release, and update certain files like RELEASES and start_erl.data (maybe some more?) so they are in the same state as they would be after a hot upgrade. The result would be that when the node is started, newly installed erlang release is booted. Also, an important thing is that I want to avoid running old release.
Any ideas how to do this as simple and cleanly as possible?
Start an erlang node to get a shell. There is no need for a node name just be sure you are running the same ~/bin/erl that the target node does. Then place your release package in ~/lib/erlang/releases and unpack as you would normally:
1> application:start(sasl),
1> release_handler:unpack_release("my_release-1.0").
{ok, "1.0"}.
Now quit, shutting down the shell:
2> q().
[Don't try and cheat by using another window here! You must quit.]
Now you need to edit the ~/lib/erlang/releases/RELEASES file and change the status of the new release from unpacked to current:
[{release,"My Release Package","1.0","5.9.1",
[{kernel,"2.15.1","/Users/otpuser/lib/erlang/lib/kernel-2.15.1"},
{stdlib,"1.18.1","/Users/otpuser/lib/erlang/lib/stdlib-1.18.1"},
{sasl,"2.2.1","/Users/otpuser/lib/erlang/lib/sasl-2.2.1"}, ...],
- unpacked}].
+ current}].
Start a shell again and make it permanent:
1> application:start(sasl),
1> release_handler:make_permanent("1.0").
ok
[Note: all that make_permanent/1 does is put the release version ("1.0") in ~/lib/erlang/releases/start_erl.data so you could cheat here.]
Be sure to place your system configuration in ~/lib/erlang/releases/1.0/sys.config.
Now when you run ~/bin/start the release name will be read from start_erl.data and init will use the boot script in ~/lib/erlang/releases/1.0/start.boot.

Resources