When running something like "make install", there is a lot of information displayed in the terminal window. Some lines start with make[1], make[2], make[3] or make[4]. What do these mean? Does this mean there is some kind of error?
When make is invoked recursively, each make distinguishes itself in output messages with a count. That is, messages beginning "make[3]" are from the third make that was invoked. It is not indicative of an error of any kind, but is intended to enable you to keep track of what is happening. In particular, you can tell in which directory make is being run to help debug the build if any errors do occur.
Related
When debugging a PHP program with Xdebug, is it possible to set a kind of "conditional breakpoint" not on a specific line, but rather when a certain output is echoed?
This output could be specified by a certain string like id="someid" or by a regexp like id="header(1|2)".
I believe this would be extremely practical when debugging - I know something is wrong with some part of my output, and I want to break the program at the point where it is produced, so I can work up the Call Stack and see what went wrong.
I am using PhpStorm and I would be satisfied by an answer explaining how to do that in this particular IDE. But since I suspect it won't be possible, I ask the question in more generic terms: would Xdebug allow for this?
I've generated an gfortran executable I call mtc08.exe that exhibits the following behavior:
1) If I run it in gdb it runs successfully to the end
2) If I run it normally, re routing the output with the windows command
mtc08.exe >out
It gives me "floating point exception - erroneous arithmetic operation" but does not say where that occurs. (The "backtrace" information is incomprehensible to me, and it seems it cannot contain much information because all is the letter "f".)
Then I'm trying to localize the problem by seeing where the program stops writing results, but having difficulties there also, because I get the impression the program may be multi tasking and proceeding with "future" arithmetic operations before completing output operations that in any case do not interfere.
Does such multi tasking occur? If so, can I turn it off with a compiler switch, so I'm really sure it is doing all operations sequentially?
The currently used compilation command in windows is:
rem debug compilation:
gfortran -static -fdefault-real-8 -fdefault-integer-8 -g -ffpe-trap=invalid,zero,overflow,underflow,denormal -Wall -fcheck=all #mtc08.fls -o mtc08.exe
where mtc08.fls is a file containing the names of all source files.
It may be that by removing some of the "-ffpe-trap" options it would run, but this rattles my confidence, and I'd like to get to the bottom of it, rather than just find a way around.
I can of course give more information, but seeing the error is not localized, that is not so practical.
I still don't know how to get better diagnostics, but still managed to find the cause of the problem by trial and error, which came from an uninitialized variable.
The problem appears to arise because gdb used zero for uninitialized variables, which should have been their values anyhow, and running the same executable without gdb did use values that lead to "floating point exception".
One way to get better diagnostics in gdb is to use -finit-real-nan in the compilation so that uninitialized variables will get more attention from the debugger.
Perhaps with better coding practice, such as intent declarations for all arguments, the debugger would also be better in picking up uninitialized variables without having to initialize them to nan.
I am trying to make my Xamarin.UITest output clearer and easier to work with. Every so often when Xamarin Forms updates the tree changes in subtle ways that break our UITests. Also, when developing a test it isn't always necessarily clear what the query should look like to get to a view element we want our test to interact with.
To address these, when a test fails with an "Unable to find element" error, I want to capture the app's view tree and output it to the test results.
Currently in these cases we have to modify the test code by adding app.Repl(); (see Working With the REPL), re-run the test, wait for the REPL window to appear, type tree, look at the output, type exit to leave the REPL, make my code changes based on what I saw in the tree command's output, and rinse-repeat until I have a working test. Instead, if the test results contains the outputs of the REPL's tree command, I can start making changes to fix the test code immediately and greatly speed up my testing feedback loop.
How could I most easily achieve this?
app.Print.Tree();
I think this is what you searched for.
Lua features hook call BEFORE every processed line. What I need is a call AFTER line is processed, so that I can check for encountered errors and so on. Is there a way to make such kind of call?
Otherwise things get a little bit confusing if error is encountered at the last line of the script. I don't get any feedback.
UPDATE #1
We want to catch both Lua errors and 'our' errors asserted via lua_error(*L) C interface, and Lua should throw correct debug info including the line number where the error occurred.
Using return hook we always get error line number -1, which is not what we want. Using any combination of pcall and any hook setup after lua_error(*L) we get either line number -1, or number of the next executed line, never a correct one.
SOLUTION#
We managed to make everything work. The thing was that Lua throws a real C exception after it detects an error, so some of our 'cleaning & finalizing' C code called from Lua operation did not execute, which messed up some flags and so on. The solution was to execute 'cleaning code' right before calling lua_error(...). This is correct and desired Lua behavior as we really want to stop executing the function once lua_error(...) is called, it was our mistake to expect any code would be executed after lua_error(...) call.
Tnx Paul Kulchenko, some of this behavior was found while trying to design a simple example script which reproduces the problem.
Try setting a return hook: it'll be called after the last line is executed.
I'm not sure debug hook is the best solution for what you are trying to do (or you need to provide more details). If you just need to check for run-time errors, why use debug hooks at all if you can run your code with pcall and get an error message that points to the line number where the error happened (or use xpcall, which also allows you to get a stack trace)? You can combine this with debug.getinfo(func, "L") to get a table whose indexes are valid line numbers for the function.
I'm pretty new to linux, and I have a few questions about kernel module programming. I'm using ubuntu and C to make my .ko files. I'm trying to make a module that will execute program /b instead of /a whenever program /a is called. any tips?
also, even with printk (KERN_EMERG...), it won't print to the terminal. is there a setting i'm missing, or does ubuntu not do that?
Thanks a lot!
You may need to fiddle with the settings in /proc/sys/kernel/printk, which controls which levels are printed to the console. From proc(5):
/proc/sys/kernel/printk
The four values in this file are console_loglevel,
default_message_loglevel, minimum_console_level, and
default_console_loglevel. These values influence
printk() behavior when printing or logging error
messages. See syslog(2) for more info on the
different loglevels. Messages with a higher priority
than console_loglevel will be printed to the console.
Messages without an explicit priority will be printed
with priority default_message_level.
minimum_console_loglevel is the minimum (highest)
value to which console_loglevel can be set.
default_console_loglevel is the default value for
console_loglevel.
Note that, like nice(2) values, the lower values have higher priorities.
The easiest way to make an execve() for path /foo/a to execute /foo/b is to bind-mount /foo/b on top of /foo/a:
mount -obind /foo/b /foo/a
No kernel module is required.
Doing this same task with a kernel module would be significantly more work; the LSM interface may provide you with some assistance in figuring out when exactly your target is being executed. If you're looking for a starting point, do_execve() in fs/exec.c is where to start reading. Be sure to have ctags installed, run, and know how to use your editor's ctags integration, to make reading the code significantly easier.
Answer about printk:
It prints to the console, not the terminal. But what's the console?
You can find its TTY in /proc/cmdline. Normally it's tty0, which means the screen connected to the computer.
If you connect via SSH/TELNET, surely you won't see this.
If you're working in a graphical environment (Gnome/KDE), you may need something like alt-F1/F2 to switch to a text mode TTY.
You can also use the dmesg command to see the messages.