my project is working fine when i not upgrade xcode to ios 6..
but after upgrading i ve this error...
collect2: ld terminated with signal 6 [Abort trap: 6]
ld(22918,0x7fff72e6f960) malloc: * error for object 0x7fe300c4d130: pointer being freed was not allocated
* set a breakpoint in malloc_error_break to debug
Command /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/llvm-gcc-4.2 failed with exit code 1
i tried much to find this on net but dont find any similer problem or any solution..
please need help soon....
All of a sudden this happens to me as well, clear and build solved my issue.
I also got a problem with exit code signal 6. In my case, the problem was, I defined the UIStoryboard at Build as: with a iOS version higher than the UIDevice I was installing the app.
Maybe you are going to check this, didn't have this problem before, so might be possible it solves yours too.
Here a screenshot where to go inside the File Inspectore:
I encountered the error. And it was caused by the wrong usage of UserDefault class. As you know, the UserDefault methods should be executed in the UI thread(main thread) and you are restricted to types to be saved. I called the UserDefault methods in not main thread and I also tried to save struct. And then I got message from debugger: terminated due to signal 6. Finally, I made the execution thread the main thread and the type dictionary. And I overcame this error.
This is related to updating the UI in a background thread.
You should change the UI in the main thread.
Disable thread sanitizer from
Edit Scheme -> Run -> Uncheck Thread Sanitizer.
Related
I'm having trouble with an research project.
What i am trying to is to use ptrace to watch the execution of a target process.
With the help of ptrace i am injecting a mprotect syscall into the targets code segment (similar to a breakpoint) and set the stack protection to PROT_NONE.
After that i restore the original instructions and let the target continue.
When i get an invalid permisson segfault i again inject the syscall to unprotect the stack again and afterwards i execute the instruction which caused the segfault and protect the stack again.
(This does indeed work for simple programs.)
My problem now is, that with this setup the target (pretty) randomly crashes in library function calls (no matter whether i use dynamic or static linking).
By crashing i mean, it either tries to access memory which for some reason is not mapped, or it just keeps hanging in the function __lll_lock_wait_private (that was following a malloc call).
Let me emphasis again, that the crashes don't always happen and don't always happen at the same positions.
It kind of sounds like an synchronisation problem but as far as i can tell (meaning i looked into /proc/pid/tasks/) there is only one thread running.
So do you have any clue what could be the reason for this?
Please tell me your suggestions even if you are not sure, i am running out of ideas here ...
It's also possible the non-determinism is created by address space randomization.
You may want to disable that to try and make the problem more deterministic.
EDIT:
Given that turning ASR off 'fixes' the problem then maybe the under-lying problem might be:
Somewhere thinking 0 is invalid when it should be valid, or visaversa. (What I had).
Using addresses from one run against a different run?
I'm doing a project that makes unix system calls. To be specific, my project heavily relies of calls to getcontext(), makecontext(), swapcontext() and setcontext(). I tried to debug my code using gdb. I stepped into the code line by line and examined the control but once a call to swapcontext() is made, it doesn't step into the code anymore. Instead, debugging almost stops there and the rest of the program is run automatically instead of line by line. I guess gdb does not go into context calls? Is there any way to get around this? Is there a debugger that i can use for this?
Thanks
setcontext and swapcontext calls change the program's stack, and gdb gets confused. I do not know whether some other debugger can handle it nicely.
gdb steps through one thread and calls this the current thread. Other threads will run as you are doing this. If you set a breakpoint that gets hit in a thread other than the current thread then gdb will change the current thread to that thread. Stepping is now relative to the new current thread.
Stepping with gdb over calls of swapcontext() with 'step' or 'next' does not work because not only the stackpointer changes but also the call returns to a different code line (which is the desired effect of swapcontext()). As gdb puts a breakpoint in the next code line which will not be executed until another swapcontext() returns to this place the execution will not break.
You need to foresee the line to which swapcontext() will return and set a breakpoint there. For a new (unused) context this will be the line you specified as entry function. For used contexts it will probably one of the lines after a swapcontext() there...
You can repeatedly use GDB's stepi command to first step into and then step through the swapcontext() function. You must step several dozen times, including a few steps over kernel system calls—I presume to save the floating point state?—and you'll eventually come out in the user thread you're swapping to. It's a tad time-consuming, but it works.
As much as you may not like this answer, the best bet is to step through your code in small chunks by hand. Threaded programs don't play very well with debuggers like GDB and Valgrind (at least in my experience) and most bugs can be determined by a careful step-by-step manual analysis of the code.
I have a program which produces a fatal error with a testcase, and I can locate the problem by reading the log and the stack trace of the fatal - it turns out that there is a read operation upon a null pointer.
But when I try to attach gdb to it and set a breakpoint around the suspicious code, the null pointer just cannot be observed! The program works smoothly without any error.
This is a single-process, single-thread program, I didn't experience this kind of thing before. Can anyone give me some comments? Thanks.
Appended: I also tried to call pause() syscall before the fatal-trigger code, and expected to make the program sleep before fatal point and then attach the gdb on it on-the-fly, sadly, no fatal occurred.
It's only guesswork without looking at the code, but debuggers sometimes do this:
They initialize certain stuff for you
The timing of the operations is changed
I don't have a quote on GDB, but I do have one on valgrind (granted the two do wildly different things..)
My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?
When a program runs under Valgrind,
its environment is slightly different
to when it runs natively. For example,
the memory layout is different, and
the way that threads are scheduled is
different.
Same would go for GDB.
Most of the time this doesn't make any
difference, but it can, particularly
if your program is buggy.
So the true problem is likely in your program.
There can be several things happening.. The timing of the application can be changed, so if it's a multi threaded application it is possible that you for example first set the ready flag and then copy the data into the buffer, without debugger attached the other thread might access the buffer before the buffer is filled or some pointer is set.
It's could also be possible that some application has anti-debug functionality. Maybe the piece of code is never touched when running inside a debugger.
One way to analyze it is with a core dump. Which you can create by ulimit -c unlimited then start the application and when the core is dumped you could load it into gdb with gdb ./application ./core You can find a useful write-up here: http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php
If it is an invalid read on a pointer, then unpredictable behaviour is possible. Since you already know what is causing the fault, you should get rid of it asap. In general, expect the unexpected when dealing with faulty pointer operations.
I'm trying to use check unit testing framework for my C application. But I can't use the debugger (gdb) with it because of two points:
first, check use some complex macros (START_TEST and END_TEST) and the debugger has trouble to put a breakpoint in my code between these two macros (in fact, I can put a software breakpoint but It is never seen by gdb)
second, check define some sort of exceptions by redefining behavior of interruption. Hence, when I try to put a hardware breakpoint, the test failed and exit because check consider the hardware breakpoint as a failure of my test.
Does anyone has already met this problem and has a solution?
Look at the no-fork mode:
Check normally forks to create a separate address space. This allows a signal or early exit to be caught and reported, rather than taking down the entire test program, and is normally very useful. However, when you are trying to debug why the segmentation fault or other program error occurred, forking makes it difficult to use debugging tools.
Actually, you CAN use fork-mode too.
gdb has two interesting options related to fork behaviour:
- detach-on-fork (set this to false)
- follow-on-fork (either parent or child; I always take child)
This will make gdb follow the child process.
When the child process has ended, you have to manually switch back to the parent process by using the inferior command.
I read this and he suggests a very simple solution:
gdb > set environment CK_FORK=no
that worked for me. I could then set a breakpoint in functions the test cases call (that is, the functions under test), and it broke at the right place.
Try TAP (Test Anything Protocol) … it's a lot easier to implement, ship and debug. It's also very easy to make it valgrind-aware and tends to play nicer with gdb.
I have some image processing code that runs on a background thread and updates an Image control on the UI thread when it's done processing using Dispatcher.BeginInvoke(). When I'm running my application outside of the debugger, it crashes quite often. As soon as I run it in the debugger, I can't get it to happen at all. Apparently the timing difference is enough to make my life miserable right now ;-)
I've tried putting try/catch blocks around any code that seems relevant and logging any errors that come up, but to no avail - it somehow keeps slipping past me, and I'm not sure where else to look.
My hope for using the debugger was to set the debugger's exception catching behavior to break whenever any exception was thrown, but since I can't get the exception to happen while debugging, I can't find out where my code is throwing.
I can attach to my crashed process (since it stays on screen, just is completely unresponsive), pause the debugger, and see where each thread is in the code, but that doesn't really help me - I have no idea what the actual exception being thrown is.
Any suggestions on how to proceed?
Edit:
I've been using System.Diagnostics.Trace.WriteLine() with DbgView in as many places as I can think. I can track down where it appears the exception is occurring, I can't find out what the exception is, which is what is important.
I've used WinDBG+SOS before, to track down memory leaks, but not to track down hard-to-find-exceptions. Can anyone suggest resources for using WinDBG+SOS in this capacity?
With only few exceptions every BeginInvoke should have a corresponding EndInvoke counterpart (see here for more details why, one exception is e.g. Control.BeginInvoke).
A missing EndInvoke might be the reason that an exception is not caught by the main thread and your application terminates.
Since in your special case you are dealing with Dispatcher (which does not implement EndInvoke) you will have to handle the Dispatcher.UnhandledException event to catch any exception thrown during execution of a delegate.
By the way, a good tool to monitor the System.Diagnostics.Trace messages is DbgView from Sysinternals.
How can you be sure it's an exception, when you've never caught it?
Also, rather than placing try/catch blocks all over the place, place them at boundaries, especially at thread boundaries. Put them around any ThreadStart methods or other code invoked by BeginInvoke, or callback methods, etc.
Can you put one try/catch in the static Main called on application start? So when app crash you can output stacktrace and exception info somewhere.