From Using trace and dbg in Erlang, I'm aware that one can trace calls to specified functions from all functions using
1>dbg:p(all, c).
However, how does one trace calls to all functions from all functions? e.g:
1>dbg:foo().
*ALL Erlang function calls will be traced from here on out. Prepare yourself.*
2>lists:append("abc", "def").
*trace*
Tracing all calls to all functions is not something you want to do, as that would easily swamp your output and make your shell unusable. After all, the shell calls functions to perform its duties too, as does dbg, so you'd end up seeing endless traces of calls to io functions involved in generating and displaying the trace.
Instead, take a look at the various dbg:tp and dbg:tpl functions. Apply them after your call to dbg:p(all, c). They allow you to trace specific modules and specific functions. Start by tracing a particular function or module, and then based on the trace you see, widen your trace to callers of that function. You can also use dbg:ctp and dbg:ctpl to turn off tracing for specific functions or modules once they're no longer relevant to your debugging efforts. With this approach, you can use dbg to iteratively zero in on whatever it is you're looking for.
Related
I am using C in Objective C and I want to capture stdout to UIView from Console.
Here is the line I'm talking about:
print(stdout, v=toplevel_eval(v));
Other than you are writing in C I have no idea how much you know about C, "Unix" and Cocoa I/O - so some of this you may already know.
Here is one possible solution, it looks more complicated than it is.
Reading:
You need to understand the system calls pipe, dup2 and read.
You need to understand the GCD function dispatch_async and how to obtain a GCD queue.
pipe and dup2 are often used in conjunction with fork and exec to launch a process and write/read to/from that process standard input/output. What you will be doing uses some of the same basic ideas so looking up examples of this common pattern will help you understand how these calls work. Here are some notes from a University: Pipe, Fork, Exec and Related Topics.
Outline:
Using dispatch_async schedule a block to handle the reading and writing of the data. The block will:
Use pipe To create a pipe and dup2 To connect stdout - file descriptor 1 - it.
Enter a loop which uses read to obtain the available data from the pipe. Data read will be in a byte array.
Within the loop convert the read bytes into an NSString
Within the loop append that string to your view - you must do this on the main thread as it involves the UI, and you can do that using another dispatch_async specifying the main queue.
That is it. Your block will now execute concurrently in the background reading whatever your C code writes to the standard output and adding it to your view.
If you get stuck you can ask a new question showing the code you have written and describing what doesn't work.
HTH
I am having trouble using pthreads in my MPI program. My program runs fine without involving pthreads. But I then decided to execute a time-consuming operation in parallel and hence I create a pthread that does the following (MPI_Probe, MPI_Get_count, and MPI_Recv). My program fails at MPI_Probe and no error code is returned. This is how I initialize the MPI environment
MPI_Init_thread(&argc, &argv, MPI_THREAD_MULTIPLE, &provided_threading_support);
The provided threading support is '3' which I assume is MPI_THREAD_SERIALIZED. Any ideas on how I can solve this problem?
The provided threading support is '3' which I assume is MPI_THREAD_SERIALIZED.
The MPI standard defines thread support levels as named constants and only requires that their values are monotonic, i.e. MPI_THREAD_SINGLE < MPI_THREAD_FUNNELED < MPI_THREAD_SERIALIZED < MPI_THREAD_MULTIPLE. The actual numeric values are implementation-specific and should never be used or compared against.
MPI communication calls by default never return error codes other than MPI_SUCCESS. The reason for that is, MPI calls the communicator's error handler before an MPI call returns and all communicators are initially created with MPI_ERRORS_ARE_FATAL installed as their error handler. That error handler terminates the program and usually prints some debugging information, e.g. the reason for the failure. Both MPICH (and its countless variants) and Open MPI produce quite elaborate reports on what led to the termination.
To enable user error handling on communicator comm, you should make the following call:
MPI_Comm_set_errhandler(comm, MPI_ERRORS_RETURN);
Watch out for the error codes returned - their numerical values are also implementation-specific.
If your MPI implementation isn't willing to give you MPI_THREAD_MULTIPLE, there's three things you can do:
Get a new MPI implementation.
Protect MPI calls with a critical section.
Cut it out with the threading thing.
I would suggest #3. The whole point of MPI is parallelism -- if you find yourself creating multiple threads for a single MPI subprocess, you should consider whether those threads should have been independent subprocesses to begin with.
Particularly with MPI_THREAD_MULTIPLE. I could maybe see a use for MPI_THREAD_SERIALIZED, if your threads are sub-subprocess workers for the main subprocess thread... but MULTIPLE implies that you're tossing data around all over the place. That loses you the primary convenience offered by MPI, namely synchronization. You'll find yourself essentially reimplementing MPI on top of MPI.
Okay, now that you've read all that, the punchline: 3 is MPI_THREAD_MULTIPLE. But seriously. Reconsider your architecture.
While tracing my modules using dbg, I encountered with the problem how to collect messages such as spawn, exit, register, unregister, link, unlink, getting_linked, getting_unlinked, which are allowed by erlang:trace, but only for those processes which were spawned from my modules directly?
As an examle I don't need to know which processes io module create, when i call io:format in some module function. Does anybody know how to solve this problem?
Short answer:
one way is to look at call messages followed by spawn messages.
Long answer:
I'm not an expert on dbg. The reason is that I've been using an (imho much better, safer and even handier) alternative: pan , from https://gist.github.com/gebi/jungerl/tree/master/lib/pan
The API is summarized in the html doc.
With pan:start you can trace specifying a callback module that receives all the trace messages. Then your callback module can process them, e.g. keep track of processes in ETS or a state data that is passed into every call.
The format of the trace messages is specified under pan:scan.
For examples of callback modules, you may look at src/cb_*.erl.
Now to your question:
With pan you can trace on process handling and calls in your favourit module like this:
pan:start({ip, CallbackModule}, Node, all, [procs,call], {Module}).
where Module is the name of your module (in this case: sptest)
Then the callback module (in this case: cb_write) can look at the spawn messages that follow a call message within the same process, e.g.:
32 - {call,{<6761.194.0>,{'fun',{shell,<node>}}},{sptest,run,[[97,97,97]]},{1332,247999,200771}}
33 - {spawn,{<6761.194.0>,{'fun',{shell,<node>}}},{{<6761.197.0>,{io,fwrite,2}},{io,fwrite,[[77,101,115,115,97,103,101,58,32,126,115,126,110],[[97,97,97]]]}},{1332,247999,200805}}
As pan is also using the same tracing back end as dbg, the trace messages (and the information) can be collected using the Erlang trace BIF-s as well, but pan is much more secure.
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.
Are there any good code profilers/analyzers for Erlang? I need something that can build a call graph (eg gprof) for my code.
For static code analysis you have Xref and Dialyzer, for profiling you can use cprof, fprof or eprof, reference here.
The 'fprof' module includes profiling features. From the fprof module documentation:
fprof:apply(foo, create_file_slow, [junk, 1024]).
fprof:profile().
fprof:analyse().
fprof:apply (or trace) runs the function, profile converts the trace file into something useful, and analyse prints out the summary. This will give you a list of function calls observed, what called them, and what they called, as well as wall-clock timing info.
Try this one: https://github.com/virtan/eep
You could get something like this https://raw.github.com/virtan/eep/master/doc/sshot1.png