While I'm learning a new language, I'll typically put lots of silly println's to see what values are where at specific times. It usually suffices because the languages typically have available a tostring equivalent. In trying that same approach with erlang, my webapp just "hangs" when there's a value attempted to be printed that's not a list. This happens when variable being printed is a tuple instead of a list. There's no error, exception, nothing... just doesn't respond. Now, I'm muddling through by being careful about what I'm writing out and as I learn more, things are getting better. But I wonder, is there a way to more reliably to [blindly] print a value to stdout?
Thanks,
--tim
In Erlang, as in other languages, you can print your variables, no matter if they are a list, a tuple or anything else.
My feeling is that, for printing, you're doing something like (just a guess):
io:format("The value is: ~p.", A).
This is wrong, because you're supposed to pass a list of arguments:
io:format("The value is: ~p.", [A]).
Where A can be anything.
I usually find comfortable to use:
erlang:display/1
to print variables.
Also, tracing functions is usually a better way to debug an application, rather than using printouts. Please see:
http://aloiroberto.wordpress.com/2009/02/23/tracing-erlang-functions/
When developing webapps I use the error_logger module
I usually define some macros like this
-ifdef(debug).
-define(idbg(FmtStr, Err),
error_logger:info_msg("~p (line ~p): " FmtStr "~n",
[?MODULE, ?LINE | Err])).
-define(rdbg(Term), error_logger:info_report(Term)).
-else.
-define(idbg(_FmtStr, _Err), void).
-define(rdbg(_Term), void).
-endif.
You call the macros with something like:
code...
?rdbg(ErlangTerm),
other code...
During development you compile your modules with:
erlc -Ddebug *.erl
and so you get info messages in your erlang console.
Also make sure that there is no terminating process without link which could then cause other process to wait on something and not timeout-ing - hence strange hanging part.
Related
I obfuscated this script using some site
But i'm wondering how to deobfuscate it? can someone help me?
i tried using most decompilers and a lot of ways but none has worked
local howtoDEOBFUSCATEthis_Illll='2d2d341be85c64062f4287f90df25edffd08ec003b5d9491e1db542a356f64a488a1015c2a6b6d4596f2fa74fd602d30b0ecb05f4d768cd9b54d8463b39729eb1fe84630c0f8983f1a0087681fe4f2b322450ce07b
something like that for an example.
the whole script: https://pastebin.com/raw/fDGKYrH7
First reformat into a sane layout. a newline before every local and end will do a lot. Then indenting the functions that become visible is pretty easy.
After that use search replace to inline constants. For example: local howtoDEOBFUSCATEthis_IlIlIIlIlIlI=8480; means you can replace every howtoDEOBFUSCATEthis_IlIlIIlIlIlI with 8480. Though be careful about assignments to it. If there are any then it's better to rename the variable something sensible.
If an identifier has no match you can delete the statement.
Eventually you get to functions that are actually used.
Looking at the code it seems to be an interpreter implementation. I believe it's a lua interpreter
Which means that you'll need to verify that and decompile what the interpreter executes.
I'm reading some source codes of a project, which is a combination of c++ and lua, they are interwined through luabind.
There is a la.lua file, in which there is a function exec(arg). The lua file also uses functions/variables from other lua file, so it has statements as below in the beginning
module(..., package.seeall);
print("Loading "..debug.getinfo(1).source.."...")
require "client_config"
now I want to run la.exec() from interactive terminal(on linux), but I get errors like
attempt to index global 'lg' (a nil value)
if I want to import la.lua, I get
require "la"
Loading #./la.lua...
./la.lua:68: attempt to index global 'ld' (a nil value)
stack traceback:
./lg.lua:68: in main chunk
[C]: in function 'require'
stdin:1: in main chunk
[C]: ?
what can I do?
Well, what could be going wrong?
(Really general guesswork following, there's not much information in what you provided…)
One option is that you're missing dependencies because the files don't properly require all the things they depend on. (If A depends on & requires B and then C, and C depends on B but doesn't require it because it's implicitly loaded by A, directly loading C will fail.) So if you throw some hours at tracking down & fixing dependencies, things might suddenly work.
(However, depending on how the modules are written this may be impossible without a lot of restructuring. As an example, unless you set package.loaded["foo"] to foo's module table in foo before loading submdules, those submodules cannot require"foo". (Luckily, module does that, in newer code without module that's often forgotten – and then you'll get an endless loop (until the stack overflows) of foo loading other modules which load foo which loads other modules which …) Further, while "fixing" things so they load in the interpreter you might accidentally break the load order used by the program/library under normal operation which you won't notice until you try to run that one normally again. So it may simply cost too much time to fix dependencies. You might still be able to track down enough to construct a long lua -lfoo-lbar… one-off dependency list which might get things to run, but don't depend on it.)
Another option is that there are missing parts provided by C(++) modules. If these are written in the style of a Lua library (i.e. they have luaopen_FOO), they might load in the interpreter. (IIRC that's unlikely for C++ because it expects the main program to be C++-aware but lua is (usually? always?) plain C.) It's also possible that these modules don't work that way and need to be loaded in some other way. Yet another possibility might be that the main program pre-defines things in the Lua state(s) that it creates, which means that there is no module that you could load to get those things.
While there are some more variations on the above, these should be all of the general categories. If you suspect that your problem is the first one (merely missing dependency information), maybe throw some more time at this as you have a pretty good chance of getting it to work. If you suspect it's one of the latter two, there's a very high chance that you won't get it to work (at least not directly).
You might be able to side-step that problem by patching the program to open up a REPL and then do whatever it is you want to do from there. (The simplest way to do that is to call debug.debug(). It's really limited (no multiline, no implicit return, crappy error information), but if you need/want something better, something that behaves very much like the normal Lua REPL can be written in ~30 lines or so of Lua.)
Why do some examples (and templates in text editor) of gen_server have:
-define(SERVER, ?MODULE).
Is there any good reason for it?
This question brought about by Inaka's guildelines, where they state the opposite:
Don't use macros for module or function names
Here is the code example they provide:
-module(macro_mod_names).
-define(SERVER, ?MODULE). % Oh, god! Why??
-define(TM, another_module).
-export([bad/1, good/1]).
bad(Arg) ->
Parsed = gen_server:call(?SERVER, {parse, Arg}),
?TM:handle(Parsed).
good(Arg) ->
Parsed = gen_server:call(?MODULE, {parse, Arg}),
another_module:handle(Parsed).
Why does every example (and templates in text editor) of gen_server always have
Searching for "erlang gen_server example", no hits on the first page for me define this macro (and in fact I haven't seen it before). In particular, this includes Erlang documentation's own http://erlang.org/doc/design_principles/gen_server_concepts.html, "Learn you some Erlang", and the Erlang wikibook.
Is there any good reason for it?
The reason is clearly to use a more "descriptive" name; whether this is a good reason is a question of taste.
I think it is a good practice to use -define to define and document relevant variables for the module. This is especially true for variables that get used at different places in the module and you want to make it configurable.
Actually, I think your question tackles this at the wrong side: the gen_server name is a module-wide configurable variable (and hence it is best practice to define it), and for the sake of simplicity it became common practice to choose the server name equal to the module name: gen_servers name is normally registered so you can send messages to it. Since the name is a critical variable here (and there might even be cases when you would like to change it), it is normally -defineded.
I also think that the guidelines you quotes are speaking about a different use-case for macros.
I'm writing tests with EUnit and some of the Units Under Test need to read a data file via file:consult/1. My tests make assumptions about the data that will be available in /priv, but the data will be different in production. What's the best way to accomplish this?
I'm a total newbie in Erlang and I have thought of a few solutions that feel a bit ugly to me. For example,
Put both files in /priv and use a macro (e.g., "-ifdef(EUNIT)") to determine which one to pass to file:consult/1. This seems too fragile/error-prone to me.
Get Rebar to copy the right file to /priv.
Also please feel free to point out if I'm trying to do something that is fundamentally wrong. That may well be the case.
Is there a better way to do this?
I think both of your solutions would work. It is rather question of maintaining such tests, and both of those rely on some external setup (file existing, and having wright data).
For me easiest way to keep contents of such file local to given test is mocking, and making file:consult/1 return value you want.
7> meck:new(file, [unstick, passthrough]).
ok
8> meck:expect(file, consult, fun( _File ) -> {some, data} end).
ok
9> file:consult(any_file_at_all).
{some,data}
It will work, but there are two more things you could do.
First of all, you should not be testing file:consult/1 at all. It is part of standard library, and can assume it works all wright. Rather than doing that you should test functions that use data you read from this file; and of course pass to them some "in-test-created" data. It will give you some nice separation between data source, and parsing (acting on) it. And later it might be simpler to replace file:consult with call to external service, or something like that.
Other thing is that problem with testing something should be sign of bad smell for you. You might think a little about redesigning your system. I'm not saying that you have to, but such problems are good indicator to justify on . If you testing some functionality x, and you would like it to behave one way in production and other in tests (read one file or another), than maybe this behaviour should be injected to it. Or in other words, maybe file your function should read should be a parameter in this function. If you would like to still have some "default file to read" functionality in your production code, you could use something like this
function_with_file_consult(A, B, C) ->
function_with_file_consult(A, B, C, "default_file.dat").
function_with_file_consult(A, B, C, File) ->
[ ... actual function logic ... ]
It will allow you to use shorter version in production, and longer just for your tests.
Is it possible to check if a lua script contains errors without executing it? I have fallowing code:
if(luaL_loadbuffer(L, data, size, name))
{
fprintf (stderr, "%s", lua_tostring (L, -1));
lua_pop (L, 1);
}
if(lua_pcall(L, 0, 0, 0))
{
fprintf (stderr, "%s", lua_tostring (L, -1));
lua_pop (L, 1);
}
But if the script contains errors it passes first if and it is executed. I want to know if it contains errors when I load it, not when I execute it. Is this possible?
You can use the LUA Compiler. It will only compile your file to bytecode without executing it.
Your program will also have the advantage the run faster if it is compiled.
You can even use the -p option to only perform a syntax checking, according to the linked man page :
-p load files but do not generate any output file. Used mainly for syntax checking or testing precompiled chunks: corrupted files will probably generate errors when loaded. For a thourough integrity test, use -t.
(This was originally meant as a reply to the first comment to Krtek's question, but I ran out of space there and to be honest it works as an answer just fine.)
Functions are essentially values, and thus a named function is actually a variable of that name. Variables, by their very definition, can change as a script is executed. Hell, someone might accidentally redefine one of those functions. Is that bad? To sum my thoughts up: depending on the script, parameters passed and/or actual implementations of those pre-defined functions you speak of (one might unset itself or others, for example), it is not possible to guarantee things work unless you are willing to narrow down some of your demands. Lua is too dynamic for what you are looking for. :)
If you want a flawless test: create a dummy environment with all bells and whistles in place, and see if it crashes anywhere along the way (loading, executing, etc). This is basically a sort of unit test, and as such would be pretty heavy.
If you want a basic check to see if a script has a valid syntax: Krtek gave an answer for that already. I am quite sure (but not 100%) that the lua equivalent is to loadfile or loadstring, and the respective C equivalent is to try and lua_load() the code, each of which convert readable script to bytecode which you would already need to do before you could actually execute the code in your normal all-is-well usecase. (And if that contained function definitions, those would need to be executed later on for the code inside those to execute.)
However, these are the extent of your options with regards to pre-empting errors before they actually happen. Lua is a very dynamic language, and what is a great strength also makes for a weakness when you want to prove correctness. There are simply too many variables involved for a perfect solution.
In general it is not possible, as Lua is a dynamic language, and most of errors happen in runtime.
If you want to check for syntax errors, use luac -p option. I use it as a part of my pre-commit hook, for example.
Other common errors are triggering by misusing the global variables. You may analyze output of luac -l to catch these cases. See here: http://lua-users.org/wiki/DetectingUndefinedVariables.
If you want something more advanced, there are several more-or-less functional static analysis tools for Lua code. Start with LuaInspect.
In any case, you are advised to write unit tests instead of just relying on static code checks. Less pain, more gain.