I googled it but i could not find the answer. How can I suppress this warning AND ONLY THIS:
Warning: Deleted feature: PAUSE statement at (1)
i know I can supress all the warning but I wanna suppress only this one. Or if not possible. suppress warning for delete features.
thanks
A.
Compile with -std=legacy or -w (lowercase). Note that -w will suppress all warnings.
Related
I've hit an assertion in code and wondering if there's a way to create a wrapper around the assert that would enable breaking out and continuing execution or some other function that would enable a way to suppress the assert through the lldb debugger.
assert(condition(), makeCriticalEvent().event.description, file: fileID, line: UInt(line))
This is the standard assertion in apples libraries here. When I hit this assertion I tried continuing execution but it stays stuck at the assertion. I'd like to silence the assertion (likely through the lldb debugger by typing some command). Anyone have an idea how to do this?
You have to do two things. First, you have to tell lldb to suppress the SIGABRT signal that the assert delivers. Do this by running:
(lldb) process handle SIGABRT -p 0
in lldb. Normally SIGABRT is not maskable, so I was a little surprised this worked. Maybe because this is a SIGABRT the process sends itself? I don't think there's any guarantee suppressing SIGABRT's has to work in the debugger so YMMV, but it seems to currently. Anyway, do this when you've hit the assert.
Then you need to forcibly unwind the assert part of the stack. You can do that using thread return, which returns to the thread above the currently selected one w/o executing the code in that frame or any of the others below it. So just select the frame that caused the assert, go down one frame on the stacks and do thread return.
Now when you continue you won't hit the abort and you'll be back in your code.
I have a Kuka arm and some objects set up in my simulation(very similar to manipulation station example), and I have been running into coredump error below whenever there is a contact between the robot and the objects.
"abort: Failure at multibody/plant/multibody_plant.cc:1640 in CalcImplicitStribeckResults(): condition 'info == ImplicitStribeckSolverResult::kSuccess' failed.
Aborted (core dumped)"
Decreasing the integration step size for the simulator did not help, so I ended up tracing back the error and commented out the condition that is causing the error( "DRAKE_DEMAND(info == ImplicitStribeckSolverResult::kSuccess);" ), which seems to coredump a lot less often.
However, I am guessing that condition is there for a reason, so would commenting the line out cause any other issues in the simulation? What is the proper way to fix the coredump problem?
In Drake PR #12503, the ImplicitStribeck code was refactored to reflect the notation in the TAMSI arXiv paper, and in #12361 it was changed to provide a more helpful exception with troubleshooting tips:
https://github.com/RobotLocomotion/drake/blob/v0.15.0/multibody/plant/multibody_plant.cc#L1866-L1878
Can you try out a later version (e.g. 0.15.0), and then try out the troubleshooting instructions there? (You've already tried changing step size in the simulator, but you may want to check on the stiffness of your overall system, etc.)
I find ASAN doesn't report memory leak for glib's GPtrArray related functions. For example:
$ cat test_asan.c
#include <glib.h>
int main()
{
GPtrArray *gparray = g_ptr_array_new_with_free_func(g_free);
g_ptr_array_add(gparray, g_strdup("--"));
}
Build and run this file:
$ clang -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -fsanitize=address -g test_asan.c -o test_asan -lglib-2.0
$ ./test_asan
$
Nothing is reported. But in fact, the above program forget to call g_ptr_array_free (gparray, TRUE); at the end of main function.
Anyone can give some explanation of this behaviour? Or I missed something?
LeakSanitizer is using a simple algorithm which scans stack frames, registers, global and thread-local variables and reachable heap allocations for data which looks like memory addresses. This happens without compiler feedback so unrelated, random or stale data may cause lost memory to be considered reachable. The algorithm is thus imprecise and is known to generate false negatives (see e.g. here or here) which in practice depend on compiler/library version and/or flags.
Usually issues like the one you describe happen when stale contents of main's frame (gparray in your case) happens to not be overwritten when LSan scan starts.
As this a design issue, there isn't much you can do about it.
I am new to XCode and Objective C. I have intentionally make a mistake to assign number to NSString*.
NSString* s = #1;
[s uppercaseString];
Though XCode gives me warning, this code will compile. But at runtime I get exception. Now I see in logs, (Sorry for image, I was not able to paste is as text properly due to formatting)
In this log, how I find exact place of error. How this log tells me which code to change.
So it looks like you are running the Release build (debug symbols stripped) and if you got that crash log in a production environment you would need to symbolicate it in order to find the line.
This Apple TN gives some details of Symbolication.
In a development environment you would simply add an exception breakpoint and run it from Xcode, as the debug symbols would not be stripped.
To understand what line causes the problem, you usually need to add exception breakpoint to your project as explained in this document;
In the bottom-left corner of the breakpoints navigator, click the
Add button.
Choose Add Exception Breakpoint.
In the Exception pop-up menu, choose the type of exception on which
you want execution to stop:
All. Stops on all exceptions.
Objective-C. Stops on Objective-C exceptions.
C++. Stops on C++ exceptions. To stop on a particular C++ exception, specify the exception name.
Choose the phase of the exception handling process at which you want program execution to stop.
Click Done.
line 5 Sam : [BIDViewController viewDidLoad] + 143 , if this is a release build , you need to resolve with symbols the memory address of the function , this is called "symbolize" the crash dump...
In the log look for your project name and you will come to know.
e.g.
line 5 Sam : [BIDViewController viewDidLoad] + 143
If you want to produce real crash without warning, try following code it will produce index out of bound exception and will crash
NSArray *array = #[#"1",#"2"];
NSLog(#"Item not accessible->%#",(NSString*)array[2]);
set Exception breaking point or enable NSZombie object
or
NSZombie
From the menu bar, choose Project > Scheme > Edit Scheme
I am maintaining a legacy application and I have the following line of code:
sb.Panels[3].Text:= ' Memory in use: ' + IntToStr(AllocMemSize);
And it gives the following warning:
[dcc32 Warning] BLOB.pas(8242): W1000 Symbol 'AllocMemSize' is deprecated
and indeed, AllocMemSize is deprecated (from System.pas):
var
AllocMemSize: Integer deprecated; {Unsupported}
My question is this: What is the replacement for AllocMemSize? Is there any point? Is there some other more meaningful measure I can put there?
(I guess I can just delete the call and output entirely, but users apparently want to see this information in the Status Bar)
Call GetMemoryManagerState instead. It returns similar information, although not necessarily distilled down to a single number like AllocMemSize. The deprecation is due to Delphi's switch around Delphi 2006 to using FastMM for the memory manager, and it tracks memory differently from the older memory manager.
See also Monitoring memory usage in the documentation.