So, I have a simple project with one Program (user-writen code) and then one Add-Inn (custom task) (it is very useful System Command executor add-inn, about you can read here)
So, when I get some condition in Program step, I want to stop my Project. I could stop Program, for example, using
ENDSAS
or
Abort abend
but, even if Program immediately stops (with error message in log), Add-Inn is execute! How disable executing of Add-Inn on condition (on error or any other)?
Thanks
P.S. Project will be execute in batch mode
If you're using an EG process flow, as you presumably are, then you need to set up a condition to run the add-in task.
Right click on your one program, select 'condition', add. Let's say you have a macro variable that is set to 0 if you have no problems or (some value) if you have a problem. (Could also use any of the automatic SYSERR type macro variables.)
Then, put your add-in task under "Then, run this task". You can add an Else or Else If if you want, or just leave that as None.
Then, EG won't run your task unless the macro variable is successful.
Related
Sometimes, when I press ctrl+F10 at line A, I just want the program to resume and halt when reach line A. However, if it reaches a breakpoint before reaches line A, it will halt at that breakpoint instead.
Is there any hotkey that acts similar to ctrl+F10, but ignores all breakpoints?
Disabling all breakpoints is not a viable choice for me, because :-
I just want one-time skip. Disabling them all and enabling back in the same debug session is not so convenient.
Disable breakpoints may also disrupt some of my workflow, because I reserved them to be used in some special cases.
ctrl+shift+F10 is not useful either, because it alters the program's behavior.
I don't mind to install a new plug-in.
Appendix :-
ctrl+F10 = Starts or resumes execution of your code and then halts execution when it reaches the selected statement. (but if it reach a breakpoint, it will halt immediately)
ctrl+shift+F10 = Sets the execution point to the line of code you choose
No direct answer for it, it would hit the breakpoint during debugging mode, it can't skip the breakpoint.
Actually I also check the VS2017 RC, it has the new feature called "Run to Click", you could run your app to the specific line during debugging mode. But it also hit the breakpoint during running time, but you could ignore this action and just click "Run execution to here" again. I know that it is not the direct answer, but I think it is convenient for you to debug your app to the specific line.
Other community members also submitted a feature request which could skip over the breakpoint here:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/2221315-implement-a-new-skip-over-breakpoint-type
A extension tool:
https://marketplace.visualstudio.com/items?itemName=CodeMelee.CodeMelee-FlexPoints
Which could skip/replace the specific code line, maybe it is also a workaround for this issue.
Since no direct solution for it, I also help you submit a feature request here:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/17545741-visual-studio-hotkey-similar-to-ctrl-f10-but-als
You could also vote it:)
Is there a way to stop the process if certain criteria in any of the programs in this process is met?
I have a process consist of 5 SAS programs. This process is scheduled to run at 8am every morning. However, sometimes the database is not refreshed and this process will send out weird figures.
I need to have "exception control".. In 2nd program I check the database with some criteria. If no error, then keep running the rest of the code. Otherwise, send out an notification email and STOP running the 2nd program and all the subsequent programs.
I try %abort cancel but it only terminate the current program. The subsequent programs are not affected.. I can do checking in every single program but that make the code redundant...
I also try google "terminate SAS process" but most of them refer to abort statements which doesn't help...
If you're using Enterprise Guide, this is built into the program via logic gates.
First, in the program that determines whether the database file passed/failed ("gate program"), assign a macro variable a value based on that test. Presumably this program will do only things you're happy for it to do even if it fails.
On the process flow page, you right click on the program that determines if the database file passed/failed, and select 'Condition -> Add'.
Then add a condition based on a Macro Variable, and use 'equals' and the value you're looking for (or 'greater than' or whatever makes sense). Then select the next task after "Then run this task"; and put the other option after Else run this task.
Then, whichever of the two is forward-moving, should then have links to the rest of the programs you want run; the one that's not should end the process.
SAS gives an example of how to do that in KB Sample 39995 including a sample project you can download.
Second, you can set OBS=0 if you reach the error condition. This will let SAS continue working, but it in most cases won't be able to do anything (since OBS=0, then it can only affect 0 records of any dataset). I'm not sure that's a guarantee that it won't do anything, but in everything I've done that's been sufficient. I also have used OPTIONS ERRORABEND which works fine if you do all of your processing with external libnames which won't automatically reconnect when SAS is reconnected.
My understanding is that this is a batch process. You don't specify Operating System you are running your process on. Let's suppose you are running it on UNIX/Linux (I am hoping it is similar on Windows). Let's assume that your 5-programm process is run by the following shell script:
sas /program1.sas
sas /program2.sas
sas /program3.sas
sas /program4.sas
sas /program5.sas
If you want to stop your remaining process after program2.sas completes with ERRORs or WARNINGs you can modify your script to be
sas /program1.sas
sas /program2.sas
if [ $? -ne 0 ]
then
exit
fi
sas /program3.sas
sas /program4.sas
sas /program5.sas
In this script code a special shell script variable $? status code is passed from the previous command from SAS (0 means successful completion). If it is not 0 then the whole script stops due to the exit command.
For more information and code examples see How to conditionally terminate a SAS batch flow process in UNIX/Linux SAS blog post.
I'm currently debugging syslinux (a boot loader) through the gdb stub of qemu.
Recently, I wrote some gdb commands that (un)load the debug symbols everytime a module is dynamically (un)loaded. In order not to disrupt the execution, I ended the commands with continue.
break com32/lib/sys/module/elf_module.c:282
commands
silent
python
name = gdb.parse_and_eval("module->name").string()
addr = int(str(gdb.parse_and_eval("module->base_addr")), 0)
gdb.execute("load-syslinux-module %s 0x%08x" % (name, addr))
end
continue
end
However, when stepping through the code line by line, if the next or step command makes the execution hit the breakpoint, the breakpoints takes precedence, the commands are executed, including the continue. And the execution continue irrespectively of the line-by-line debugging I was doign. This also happen if I try to step over the function that has this breakpoint.
How can I keep (un)loading the debug symbols on the fly while not interfering with the debugging?
Is there an alternative to the continue command? Maybe using breakpoints isn't the right way? I'd take any solution.
This can't be done from the gdb CLI. However, it is easy to do from Python.
In Python the simplest way is to define one's own gdb.Breakpoint subclass, and define the stop method on it. This method can do the work you like, then return False to tell gdb to continue.
The stop facility was designed to avoid the problems with cont in commands. See the documentation for more details.
I have an application, which is running for a long time and then crash. I need to debug it several times to fix it and don't want to wait every time for an hour to reach the state, in which an error is occurred.
So, I want some tool to clone the whole process on a disk, then raise it, attach to it and debug.
I use Visual Studio 2012/2013 on (surprise) Windows.
For example:
for (int i = 0; i < 10000; ++i)
{
if (i == 9999)
throw MyExcept();
}
And I want to have a saved state of application (process) at 9998-th iteration to start debugging from it.
UPD 1: Visual Studio dump files are not admirable, because I can't get all functionality of debugger after opening it it VS. For example: I can't set breakpoints and even old ones don't work.
UPD 2: Also I need to have a possibility of duplicating this saves session of the app.
If I understood correctly, you want to accomplish two tasks:
1) Break the execution on a specific condition
You need to set a watchpoint with a condition to achieve this, or Data Breakpoint in Visual Studio terms. Have a look at this question: Can I set a breakpoint when variable is getting a specific value in .NET?
2) Dump a core file
Once you have set the watchpoint and your program reached that point, you can dump a core file. From that you can continue with the execution later on. There is an official FAQ entry entry on how to dump and load cores.
You need procdump from here
Register as the Just-in-Time (AeDebug) debugger.
Perhaps you should enable full local dumps.
Crash you program
Launch a process with procdump from full dump
But I think it is better to use DebugBreak API in your example without a crash.
Usually crash will not allow you to start further - only postmortem analysis.
I know the answer to this, I'm putting it up here for others to see it
If you use eclipse CDT, you probably understand that eclipse isn't a debugger, it's just an application front-end, specifically to GDB. So when debugging C++ programs, you're actually just using GDB in a more comfortable manner. If you ever have to debug a multithreaded program in eclipse CDT, you'll realize that things quickly get hectic because when you hit a breakpoint, all threads stop, and when one tries to execute a single line in a specific thread, it also runs the other threads. In order for it to work properly, the threads have to be able to be run arbitrarily and exlusively-so that when the programmer executes a single line, it only executes the specific thread.
So, by default, gdb's settings by default leave the "scheduler-locking" turned off. If you debug multithreaded applications you'll understand that this must be on in GDB in order for the desired behavior to be achieved. How does one run this command:
set scheduler-locking on
in GDB within eclipse CDT?
At least one way to do it that certainly solves the problem is knowing how to navigate the immense set of features that eclipse offers. Typically, when a program starts, eclipse CDT switches the console window (if you have it open, typically it's on the bottom) to show the input/output of the program.
But you can change this if you didn't know-see this image. That button on the second to last right-the blue one that looks like a monitor-you can select the GDB input console. It was discussed also in this thread.
From there merely type the command.
SOLVED, BUT NEED A BETTER SOLUTION
But now that this has been solved, to solve it in a better way as a matter of convience; having to type set scheduler-locking on every time a program starts is silly. But the problem with loading a gdbinit file is that the gdbinit file gets sourced before eclipse has set the program for gdb to solve. This is a problem, as it causes the debugger view to hang within eclipse, as gdb complains. To understand what is happening, try and fire up gdb, then give the command without loading a binary to execute. It fails-so how does one set this as an option that is sticky?
Maybe if you add the following gdb script which could set the variable when the program stops and turns it off if you continue:
define hook-step
set scheduler-locking on
end
define hookpost-step
set scheduler-locking off
end
define hook-run
set scheduler-locking off
end
define hook-continue
set scheduler-locking off
end
My answer is derived from the one by #user1448557 . Unfortunately, I don't currently have enough reputation to comment on it (or to upvote it by the way). The strategy seems great, but the answer might be a bit outdated because it doesn't involve "set scheduler-locking step". I have put the following in my gdb initialization file (within my Eclipse project) and it does what I want.
#inspired from [link to this thread][1]
define hookpost-run
set scheduler-locking step
end
With regards to the comment by #rbaleksandar, Eclipse CDT launch configurations allow one to specify a "GDB Command File" and the default is usually .gdbinit