I am Cross Compiling PARSEC Benchmarks in Alpha, and several of the benchmarks seg fault when the program exits. I have narrowed the issue down to the Pthreads Library as I went ahead and ran a non-pthreads version and there was no seg fault. The programs get the correct results despite the seg fault, but this issue is unacceptable.
Some Info:
I am running these benchmarks in the M5 Simulator so I cannot dynamically link libaries, everything is statically link with -static.
Any Ideas on how to solve this?
Not sure whether I need to rebuild the pthreads library on my Alpha Cross Compiler or add additional flags.
Can you post a stack trace at the segfault? It could be that you still have some threads running when you are exiting, which can lead to crashes. You should make sure that all threads are finished before exiting.
Related
I am facing an issue with Ground-based RGBD people detection (https://pcl.readthedocs.io/projects/tutorials/en/latest/ground_based_rgbd_people_detection.html). The error is inconsistent and hence has been pretty difficult to narrow down.
When I am running the detection, sometimes it throws a std::length error, and what() says vector_M_fill_insert.
Initially, I assumed it happened when people were detected (because it ran fine and the moment a person entered the frame, it stopped), and it was probably associated with the clustering, but in a few cases, it threw the error just after I launched the node.
I passed a processed point cloud to it and then passed the direct camera point cloud as well just to try to check if the issue was with the processed point cloud, but in both cases, it threw the error unpredictably.
I am confused as to how to go about debugging the error or what might be causing it. Any help is appreciated thank you!
You need to build your nodes with debug flags enabled and that can be achieved in some ways ...
Adding to your CMakelists.txt
set(CMAKE_BUILD_TYPE Debug)
Or
compiling with -DCMAKE_BUILD_TYPE=Debug.
Then you should attach the gdb debugger to whatever node you want. If you are using VS Code as IDE, there is already an extension for it with tutorials, otherwise, you can also add it to your launch file as described here
My code is unable to build on xcode 7. What is Segmentation fault?
A segmentation fault happens when your code tries to access memory that it isn't allowed to access. This is often a sign of an uninitialized reference.
It's not clear to me from your screenshot exactly what is going on, though. Perhaps you could provide more details?
From the screenshot it looks like it is happening when you build your project. If this is correct, you need to create a minimal example that displays the problem i.e a code fragment that crashes the compiler in the same way and then you need to raise a bug report about it with Apple (supplying your minimal example so they can reproduce it).
This has happened to me a couple of times in the past and the way I have identified the bit that crashes the compiler is to comment out everything in the source file and then add it back in function by function.That will narrow the problem down to the function. After that you repeat with the lines of code in the offending function, until you get the line that crashes the compiler.
Along the way you may find a work around to stop the compiler crashing. If you do, do not be tempted to skip reporting the bug to Apple. They need to know.
I have met the following messages in the console at runtime, and i have no idea why. I have searched everywhere and nobody seems to meet this:
INFO: fetch-response is unable to open the file /Users/userName/Library/Application Support/iPhone Simulator/7.0.3/Applications/964A590B-7131-4BAE-958B-1783BEC193EF/Library/Caches/userName.AppName/fsCachedData/2F1A8708-35A9-491E-9C21-154BA428CA10. Errno: 2
ERROR: failed to mmap cache data from FS: /Users/userName/Library/Application Support/iPhone Simulator/7.0.3/Applications/964A590B-7131-4BAE-958B-1783BEC193EF/Library/Caches/userName.AppName/fsCachedData/83A968D1-0A2B-4D20-97D5-487A876649DC, errno:22
It does not seem to affect the execution though, but I suppose it is not a good sign. I am using Core Data with a timer which frequently updates the database from a server. These messages appear synchronously with the updates, but not systematically. Only one at the time, the "INFO" or the "ERROR". Reset Content and Settings in the Simulator did not solve the problem.
Does anyone have any idea about the meaning of these messages?
I experienced this when running on my device with an app I am building. It has worked perfect for weeks and then all of a sudden this error. I figured out that it is due to a lack of memory available on the device. I use a little app call "System Status" that allows you to view the memory stats and release any old unused memory. I only get this error in Xcode when I have less than 5% available memory on my device. Therefore it cannot load the cache file the app is request, hence the error. Either close all your multitasking apps and restart your device or get the app and free you memory.
After some testing/debugging (sorry for the delay), I have at least a temporary solution.
Because of the multi-threaded saving process of Core Data, I found it a little tricky to identify the exact error location, but it definitely appears that the error occurs when Core Data is trying to save one of the context in the stack (probably the last "root" one).
As each save take a few seconds (without freezing the UI :p) , I figured the error could be generated by a "save overlap".
So even if I do not have enough to be sure, reducing the save frequency effectively solved my problem: no message anymore in the output.
Now there still is a hitch, and any expert answer would be much appreciated!
Uninstalling the app from the device and installing it again removes this error message.
Note that that doesn't fix the problem if you can see this log from earlier versions of your app that is already on your users' devices. It's generally okay to uninstall-install, though, if you're only seeing this during the development phase.
For me this happened when my phone ran out of batteries and died as a result. Deleting the app, then restarting my phone, then rebuilding/installing solved the problem.
I ran into this error because my app was stuck in an infinite loop, doing network requests multiple times a second, causing the file to be overwritten before it could be read.
In the situation described in the original post, this might very well be the case.
When I am compiling my program the build output says
"Methods without GOT slots: 0 (0%)"
I am using Xamarin and writing a program for the iPad. There are no errors in the build and the program runs just fine. I assume because there are 0 methods without GOT slots it would work right?
What is a GOT slot and how do methods have or don't have them? What are things to look out for when coding so that I don't run into problems with this if it is a problem?
Those are Global Offset Table.
To keep it a short story, do not worry about the output of the AOT compiler if it does not return an error.
If you're curious about the AOT process it from the Mono wiki. It's not 100% identical to what Xamarin.iOS is using (full AOT) but it's an interesting read to satisfy most curiosity.
Every once in a while, while debugging an application on an iPad (OS 6.1.3, SDK 6.1), the program pauses after receiving a SIGTRAP signal. I first noticed this happening inside the stat function (from /usr/include/stat.h), but it's also happening in a few other places, like semwait_signal (from nanosleep). The most obvious pattern is that it always happens immediately after running the instruction svc #128. In the case of stat, it returned 0 and there were no errors, so it doesn't seem to indicate any kind of failure state.
Has anyone else experienced this, or know how to get around it?
Thanks!
Unfortunately I didn't discover why exactly the SIGTRAP was being raised by these basic functions, but this symptom went away when I fixed a larger problem with my iOS project.
The app target and static library targets I was linking in didn't consistently define the preprocessor macro _DEBUG, which generated some weird assembly. They had the same levels of optimization, but apparently including/excluding _DEBUG made enough of a difference to cause problems.