I have some very simple code, but I cannot figure this out. I'm calling a procedure that will (hopefully) exit the process. But it doesn't exactly do that:
procedure quit;
begin
exit;
end;
And here's where i'm calling it:
If (Ch2 = #13) and (Bar2 = 5) and (Five) Then Quit;
Bar2 is basically a byte variable that holds an array with different elements, like "display", "help", "next" and "prev", and of course, quit, Which all have their own code based on what they do.
Ch2 is a variable for ReadKey that takes in various key presses, and then allows it to do whatever is defined for that specfic command. In this case, it requires that the return key is used.
Five is a boolean operator, and is there as a prerequisite to run the quit command. I guess it isn't really necessary.
BTW, if it helps, this is a unit, not a standalone program.
Anyone know why this exit command isn't working? Hopefully this post is verbose enough.
Thank you.
The exit statement exits from the function or procedure in which it is found. It then returns execution to the calling function or procedure.
To terminate the process use halt.
Related
I 'm wondering if it 's possible to create a script that will continue the program 's execution (after a break) step by step based on the memory address value.
So, if I 'm tracing a function and it goes into a high memory value, I 'd call the gdb script until the memory value is below a set value - then it would break again.
I 'm very new to gdb and still reading the manual/tutorials, but I 'd like to know if my goal is possible :) - and if you could bump me to the proper direction, even better ;)
Thanks!
Edit, updated with pseudocode:
while (1) {
cma = getMemoryAddressForCurrentInstruction();
if (cma > 0xdeadbeef) {
stepi;
} else {
break;
}
}
You're talking about the Program Counter (sometimes called the instruction pointer). It's available in gdb as $pc. Your pseudocode can be translated into this actual gdb command:
while $pc <= 0xdeadbeef
stepi
It'll be slow, since it's starting and stopping the program for every instruction, but as far as I know there's no fast way to do it if you don't know exactly what address you're looking for. If you do, then you can just set a breakpoint there:
break *0xf0abcdef
cont
will run until the program counter hits 0xf0abcdef
An usual read statement in Fortran interrupts the execution of the program until the RETURN key was pressed. I am looking for a statement that reads any pressed key without waiting for the RETURN key. The program should not stop even if no key was pressed.
Thank you for your answer.
Edit:
Here is some source code that should clarify the question.
Program test1
n=2
do while (n==2)
read (*,*) n
write (*,*) 'Output'
end do
end program test1
Program test2
n=2
do while (n==2)
UnknownReadStatement (*,*) n
write (*,*) 'Output'
end do
end program test2
The program test1 will never write the word "Output" on the screen if no key is pressed.
Using the read statement I am looking for the program test2 should fill the screen with "Output" until a key different from "2" is pressed.
There is an example code for reading a single key from the terminal from Fortran without requiring that the input be terminated by a return key at http://home.comcast.net/~urbanjost/CLONE/GETKEY/getkey.html. I haven't tried this code, so can't vouch for it. His (John Ubran) solution mixes Fortran and C, using the C getkey. Assuming that your compiler supports it (most do), I suggest trying the ISO_C_BINDING method to combine the Fortran and C. This doesn't answer the part about the program proceeding even if no key is pressed -- for that you will have to add some sort of timeout, to give the person a chance to type something, but to timeout and proceed if they don't type by a deadline. Maybe you can modify the solution I linked to...
Long story short I am trying to replicate the Sleeping barber problem in Erlang.
In my solution I decided that for all the processes that are waiting I would put them into a list. Then, once it was that processes turn, I would take that PID off of the list.
Unfortunately when I call
length(myListOfPids).
it fails, as an example:
length([<0.46.0>]).
* 2: syntax error before: '<'
is there a way to store PID's so that I can recall them and use them normally? i.e.
PID ! message
... just in case it matters here is the actual error I recieve when running my program:
=ERROR REPORT==== 1-Jul-2010::05:50:40 ===
Error in process <0.44.0> with exit value:
{badarg,[{erlang,length,[<0.46.0>]},{barber1,waitingRoom,2}]}
barber1 is my module, waitingRoom is the function that keeps track of which processes are waiting
You can also construct a Pid from it's three components using pid/3.
1> length([pid(0,35,0)]).
Be aware that using any of these techniques for constructing Pid goes wrong if you construct a pid on a different node than the one it was created on.
The problem your program is having is different.
{badarg,[{erlang,length,[<0.46.0>]},{barber1,waitingRoom,2}]}
A call to erlang:length/1 created a badarg. The third element of {erlang,length,[<0.46.0>]} is the list of arguments passed to erlang:length. So that's equivalent to:
1> erlang:length(pid(0,46,0)).
where you intended:
1> erlang:length([pid(0,46,0)]).
(Annoyingly, the erlang shell now hides erlang's internal representation of errors from you. Replacing the above error with:
** exception error: bad argument in function length/1 called as length(<0.35.0>)
which is much easier to understand but less useful because it gets in the way of learning the essential skill of interpreting erlang errors yourself.)
Entering Pids by typing them does not work for me either.
Is that the only problem?
With code:
-module(test).
-export([loop/0]).
loop() ->
receive
{hello} ->
io:format("Hello world!~n"),
loop()
end.
I get:
Eshell V5.7.5 (abort with ^G)
1> Pid = spawn(fun test:loop/0).
<0.35.0>
2> L = [Pid].
[<0.35.0>]
3> length(L).
1
This error message:
=ERROR REPORT==== 1-Jul-2010::05:50:40 ===
Error in process <0.44.0> with exit value:
{badarg,[{erlang,length,[<0.46.0>]},{barber1,waitingRoom,2}]}
means that you were calling length(<0.46.0>), not length([<0.46.0>]) (ignoring for the moment that PIDs can only be written, not read). In the stack trace the topmost function will have the list of arguments. Since length takes one argument, this list has a single argument: you are taking the length of a PID, which obviously fails, since only lists have lengths.
The problem is that while <0.46.0> is the way that a PID gets printed, it can't be entered this way. You can use list_to_pid("<0.46.0>") instead. Of course, once you do have a PID (created in this way, returned from spawn, etc.), it can be stored in a list and retrieved like any other Erlang term.
The standard way to get a pid is to take the return value of a spawn function, either spawn/1, spawn/3, spawn_link/1, spawn_link/3, and the proc_lib equivalents.
A simple way to write down a pid is with the function c:pid/3, called like c:pid(0,25,0), which will return <0.25.0>. That's a shortcut function for the shell. Otherwise, you can use list_to_pid/1 as mentioned by Alexey Romanov.
However, you should be aware of the role of pids before trying to build them by hand. The pid acts as the personal identifier of a process and is meant to be used only by those who know about it. If you don't have the pid in your hand already, then you likely shouldn't be in its possession already. Indirectly, this is meant to lead to insulation of different parts of a program — only care about those bits that you spawned and have each part of your program mind its own business.
The cleanest way to do it is thus to use the return value of a spawn function. Generating a pid by hand should be left as a debugging solution only.
If I set a watchpoint for a variable local to the current scope, it will be auto deleted when going out of the scope. Is there any way to set it once and keep it auto alive whenever entering the same scope?
Is there anyway to set conditional watchpoint, like watch var1 if var1==0? In my case, the condition does't work. gdb stops whenever var1's value is changed, instead of untill var1 == 0 is true. My gdb is GNU gdb 6.8-debian.
I agree with Dave that a conditional breakpoint is the way to go.
However, to do what you asked, you can use GDB's commands command to set a list of GDB commands to execute whenever a breakpoint is hit. I find this incredibly useful.
I suggest writing your GDB commands into a file so that they are easy to edit and easy to reload with the source command. Or you can specify command files to load on the GDB command line or use .gdbinit to make them load automatically.
An example of a good use of commands:
Suppose that I have a function format that is called by a lot of other functions. I want to break on it, but only after function do_step_3 has been called.
break do_step_3
commands
break format
continue
end
You could use this for your problem with something like:
break func
commands
watch var
continue
end
You can set conditions on watchpoints in the same way that you do with breakpoints. This is in the documentation but admittedly it hardly calls attention to itself.
So watch my_var if my_var > 3 works just fine, as does the condition command.
To recreate the watchpoint if the variable it is watching goes out of scope, have gdb do this automatically using a breakpoint at the start of the function as Zan has described.
You can set a watchpoint that does not go out of scope by setting it to the memory address.
(gdb) p &var1
$1 = (int *) 0x41523c0
(gdb) watch *(int *)0x41523c0
Hardware watchpoint 1: *(int *)0x41523c0
This also works for other data types and pointers.
I'm not sure which language us are using, so the exact answer will vary, but could you change the variable to either be static, global, or dynamically allocated (and don't free it when the function returns?). This way it's raw address won't change, and gdb will be able breakpoint on it.
Instead of watching the value whe it equals a specific value; you should set a conditional break point on the line where you want to check the value of var1. This should effectively have the same effect
e.g.
(gdb) break main.c:123 if (var1 == 0)
linux gcc 4.4.1 C99
I am just wondering is there any advantage using the following techniques. I noticed with some code I was reading the exit number went up in value, as displayed in this code snippet.
/* This would happen in 1 function */
if(test condition 1)
{
/* something went wrong */
exit(1);
}
if(test condition 2)
{
/* something went wrong with another condition*/
exit(2);
}
or doing the following and just returning:
/* This would happen in 1 function */
if(test condition 1)
{
/* something went wrong */
return;
}
if(test condition 2)
{
/* something went wrong with another condition*/
return;
}
exit() exits your entire program, and reports back the argument you pass it. This allows any programs that are running your program to figure out why it exited incorrectly. (1 could mean failure to connect to a database, 2 could mean unexpected arguments, etc).
Return only returns out of the current function you're in, not the entire program.
return will basically return from the function and adjust the stack pointers appropriately to execute the next instructions, where as exit will cause the program itself to terminate.
using exit() in a function indicates the fatal error and program cannot recover and continue and hence, it has to be terminated.
exit will not return from a function. It will exit from the entire program
I don't think you want to exit the entire program, right?
So just returning from the function would be fine.
/* This would happen in 1 function */
if(test condition 1)
{
/* something went wrong */
return; /*return type must be void in this case */
}
if(test condition 2)
{
/* something went wrong with another condition*/
return; /*return type must be void in this case */
}
You can also explicitly specify the return type of the function and use the return value to judge whether everything went fine or not.
You're asking us whether you should return error codes from your functions?
Well that depends upon how informative you want to be to your users. If you want to act like software usually acts and pop up a modal dialog that says
Something bad happened!
Then there's no need for return codes.
If, however, you want to your software to be useful to your users and let them know what happened, then you better provide some kind of diagnostic information (error codes in the least). Then you can pop up a message that says:
I can't open "foo.bar".
Does this file exist? Do you have read access to it? Is it on a network share? Maybe I should try again?
Usually this is so that the program running your program can take some intelligent decisions.
For example if there is a wrapper script around your program foo, then it could check the
exit argument using variable $$ and change the execution path:
exec foo
if $$ eq '0':
echo "Success"
elif $$ eq '2':
exec error-recovery-script
Alternatively, you yourself can execute echo $$ to see what was the exit code from the program.
If the idea is to return the value based on the test condition, prefer using return instead of exit.
To return 1, instead of exit(1), use return 1.
Not posting the reasons, as there was a detailed discussion for the same in this link.