I am seeing a crash in a very simple code snippet. The crash occurs when cv::Mat::deallocate attempts to free unallocated memory. I even simplified the code ride down to the point where it is useless, but I still see the crash.
boost::shared_ptr<cv::Mat> mask = ...;
cv::Mat thresholdedImage = cv::Mat::zeros(mask->size(), CV_32FC1);
cv::Mat dummyMask = cv::Mat::zeros(mask->size(), CV_32FC1);
cv::threshold(dummyMask, thresholdedImage, 0.5, 1, cv::THRESH_BINARY);
int nonzeroCount = cv::countNonZero(thresholdedImage);
Here is the backtrace:
1 libsystem_c.dylib 0x00007fff93aa49a3 abort + 129
2 libsystem_malloc.dylib 0x00007fff92ec91cb free + 428
3 MyLib.dylib 0x0000000135b45d7c cv::StdMatAllocator::deallocate(cv::UMatData*) const + 60
4 MyLib.dylib 0x0000000135b0240c cv::Mat::deallocate() + 28
5 MyLib.dylib 0x0000000135ba9362 cv::countNonZero(cv::_InputArray const&) + 802
Am I missing something obvious here?
Related
I'm seeing a segfault from using NSLog and specifically, it is on a 64 bit device, with a SEGV_ACCERR. I'm new to iOS, so i'm a little confused.
Here's the stack trace:
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x108074000
Crashed Thread: 0
Thread 0 Crashed:
0 libsystem_platform.dylib 0x00000001826ea31c _platform_memmove + 300
1 libsystem_asl.dylib 0x00000001825289a4 asl_string_append_no_encoding_len + 92
2 libsystem_asl.dylib 0x0000000182522fc8 asl_string_new + 108
3 libsystem_asl.dylib 0x0000000182522df4 asl_msg_to_string_raw + 68
4 libsystem_asl.dylib 0x00000001825228dc _asl_send_message + 828
5 libsystem_asl.dylib 0x00000001825224fc asl_send + 8
6 CoreFoundation 0x0000000182a6fa1c __CFLogCString + 568
7 CoreFoundation 0x0000000182a6f7ac _CFLogvEx2 + 300
8 CoreFoundation 0x0000000182a6fc14 _CFLogvEx3 + 152
9 Foundation 0x0000000183435dd8 _NSLogv + 128
10 Foundation 0x000000018336ae04 NSLog + 28
Here is the code that calls this:
NSString *truncated = [NSString stringWithUTF8String:buffer];
// Using original NSLog to print.
#undef NSLog
NSLog(#"%#", truncated);
and it crashes from my NSLog call.
where buffer is just a char buffer.
My questions specifically are:
Is it even possible to crash from using Apple's provided NSLog? Or is my stack trace wrong?
What does SEG_ACCERR even mean in this context?
How could i go about finding if this was caused by a bad memory issue or not?
Is something blowing up with the asl file under multiple threads?
How should i approach debugging this?
Any help would be greatly appreciated! Thanks!
You say that buffer is a char buffer. If that is the case, you should initialize the string like this
NSString *truncated = [[NSString alloc] initWithBytes:buffer
length:len NSUTF8StringEncoding];
where len is the length of the characters in the buffer.
The problem:
I have 2 MH_EXECUTE iOS binary files (compiled, no source code).
Lets name them binary1 and binary2.
I try to switch between them before UIApplicationMain is called!
1 try
I successfully do this with binary1 and one dylib. So I try to convert MH_EXECUTE to MH_DYLIB.
step 1
creating iOS Application binary1
#import <dlfcn.h>
int main(int argc, char * argv[])
{
NSLog(#"binary1 -> Hello, World!");
void *handle = dlopen([[[NSBundle mainBundle] pathForResource:#"binary2" ofType:nil] cStringUsingEncoding:NSUTF8StringEncoding], RTLD_NOW);
if (handle)
{
NSLog(#"DLOPEN is OK!");
}
else
{
NSLog(#"!OK ... --> %s", dlerror());
}
return 0;
}
creating iOS Application binary2
int main(int argc, char * argv[])
{
NSLog(#"binary2 -> Hello, World!");
return 0;
}
When I run binary1 I get:
step 2
Lets see the difference MH_EXECUTE vs MH_DYLIB
fullscreen
as we can see the main difference here is File Type: MH_EXECUTE vs MH_DYLIB
Lets change them and run binary1 again.
After change the result was out of address space
step 3
Lets see Load Commands
fullscreen
* in dylib there is NO __PAGEZERO segment
* dylib __TEXT segment VM address == 0 but in binary2 == 0000000100000000
So lets patch them too ... (patched: __TEXT, ___DATA and __LINKEDIT)
After run binary1 i get malformed mach-o image: segment __PAGEZERO overlaps load commands
step 4
I successfully removed __PAGEZERO from Load Commands now binary looks like dylib:
fullscreen
But on start binary1 I get BAD_ACCESS
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Subtype: KERN_PROTECTION_FAILURE at 0x00000001019e0010
Triggered by Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 dyld 0x0000000120016d78 ImageLoaderMachOCompressed::rebase(ImageLoader::LinkContext const&) + 892
1 dyld 0x0000000120016c24 ImageLoaderMachOCompressed::rebase(ImageLoader::LinkContext const&) + 552
2 dyld 0x0000000120010c8c ImageLoader::recursiveRebase(ImageLoader::LinkContext const&) + 132
3 dyld 0x000000012001039c ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, bool, ImageLoader::RPathChain const&) + 176
4 dyld 0x00000001200088e0 dyld::link(ImageLoader*, bool, bool, ImageLoader::RPathChain const&) + 180
5 dyld 0x000000012000df68 dlopen + 684
6 libdyld.dylib 0x0000000194e65b94 dlopen + 68
7 binary1 0x00000001000b7e18 main (main.m:16)
8 libdyld.dylib 0x0000000194e66a04 start + 0
Any idea ???
You're getting BAD_ACCESS because you removed __PAGEZERO and thus invalidated the rebasing opcodes. Keep __PAGEZERO but nullify it. I similarly converted an executable into a shared library and it's loading fine on iOS and macOS.
On sporadic occasions I'm getting an EXC_BAD_ACCESS (SIGSEV) in one of Apple's Accelerator framework methods, vDSP_fft2d_zip. The crash report gave the following for Thread 10. Again, most of the time this works like a champ. Any ideas on how to find the cause and fix it?
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x412f2740
Triggered by Thread: 10
. . .
Thread 10 Crashed:
0 libvDSP.dylib 0x2ddfcdb4 ___lldb_unnamed_function431$$libvDSP.dylib + 68
1 libvDSP.dylib 0x2ddfab66 ___lldb_unnamed_function427$$libvDSP.dylib + 562
2 libvDSP.dylib 0x2ddfa8ee vDSP_fft2d_zop + 434
3 libvDSP.dylib 0x2ddfa732 vDSP_fft2d_zip + 18
4 ASSIST for iPad 0x000ac32e -[Processor setupFilterForBubbleSizeMM:rectWidth:rectImageWidth:dataFilled:dataUnfilled:] (Processor.mm:813)
5 ASSIST for iPad 0x000af4d2 -[Processor runConvolutionProcessOnImage:aveImage:] (Processor.mm:1835)
6 ASSIST for iPad 0x000ac5f6 -[Processor processAnswers] (Processor.mm:869)
7 ASSIST for iPad 0x000ae9cc -[Processor process] (Processor.mm:1644)
8 ASSIST for iPad 0x000d7744 -[ReallTimeScanner processImage:] (ReallTimeScanner.mm:1046)
9 Foundation 0x2f296c82 __NSThread__main__ + 1058
10 libsystem_pthread.dylib 0x396b6c1a _pthread_body + 138
11 libsystem_pthread.dylib 0x396b6b8a _pthread_start + 98
12 libsystem_pthread.dylib 0x396b4c8c thread_start + 4
The relevant code looks like this:
#define FFT_SIZE 512
#define FFT_POWER 9
dataFilledIn->imagp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
dataFilledIn->realp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
dataUnfilledIn->imagp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
dataUnfilledIn->realp=(float *) malloc(sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataFilledIn->imagp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataFilledIn->realp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataUnfilledIn->imagp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
memset(dataUnfilledIn->realp, 0, sizeof(float)*FFT_SIZE*FFT_SIZE);
for(float y=0; y<FFT_SIZE; y+=0.25)
{
for(float x=0; x<FFT_SIZE; x+=0.25)
{
dataFilledIn->realp[(int)y*FFT_SIZE+(int)x] += 0.0625;
dataUnfilledIn->realp[(int)y*FFT_SIZE+(int)x] -= 0.0625;
}
}
vDSP_fft2d_zip(setup, dataFilledIn, 1, 0, FFT_POWER, FFT_POWER, kFFTDirection_Forward);
Answering my own question here: Be sure that the very first parameter sent in (type FFTSetup) to vDSP_fft2d_zip() is initialized correctly, and you should use this call
vDSP_destroy_fftsetup(setup);
to clean it up. I was initializing the setup var properly, like this
setup = vDSP_create_fftsetup(FFT_POWER, kFFTRadix2);
and then cleaning it up, but then was not initializing it again before subsequent calls to vDSP_fft2d_zip(). Unfortunately it only rarely caused a crash, which made it seem like the frequent calls to vDSP_fft2d_zip(setup, . . .) were working when they weren't. The crashes were sporadic making the real cause hard to trace.
There are some articles in Raywenderlich may help you:
Objectively Speaking: A Crash Course in Objective C for iOS 6
Objectively Speaking 2: A Crash Course in Objective C for iOS 6
I have a iOS app. I allocate 2d memory and then deallocate using free function. Is this the right way to free? Recently I had crash pointing to free statement. Should I be releasing buf[i] in loop?
+(int**) initArr:(int) Nr:( int) Nc
{
int ** buf;
buf = calloc(Nr,sizeof(int*));
for(int i = 0; i < Nr; i++)
{
buf[i] = calloc(Nc,sizeof(int));
}
//Funny Processing
//Release
for(int i = 0; i < Nr; i++)
free(buf[i]);
free(buf);
}
Here is the error message
2 libsystem_c.dylib 0x328b87ec _sigtramp + 48
3 libsystem_c.dylib 0x328ae20e pthread_kill + 54
4 libsystem_c.dylib 0x328a729e abort + 94
5 libsystem_c.dylib 0x32862380 free + 380
6 MyApp 0x0009be52 +[clsGlobalHelper resizeImageAvg:::] (clsGlobalHelper.m:300)
I'm writing an assembler for a custom micro controller I'm working on. I've got the assembler to a point where it will assemble instructions down to binary.
However, I'm now having problems with getting labels to work. Currently, when my assembler encounters a new label, it stores the name of the label and the memory location its referring to. When an instruction references a label, the assembler looks up the label and replaces the label with the appropriate value.
This is fine and dandy, but what if the label is defined after the instruction referencing it? Because of this, I need to have my parser run over the code twice.
Here's what I currently have for my main function:
303 int main(int argc, char* argv[])
304 {
305
306 if(argc < 1 || strcmp(argv[1],"-h")==0 || 0==strcmp(argv[1],"--help"))
307 {
308 //printf("%s\n", usage);
309 return 1;
310 }
311 // redirect stdin to the file pointer
312 int stdin = dup(0);
313 close(0);
314
315 // pass 1 on the file
316 int fp = open(argv[1], O_RDONLY, "r");
317 dup2(fp, 0);
318
319 yyparse();
320
321 lseek(fp, SEEK_SET, 0);
322
323 // pass 2 on the file
324 if(secondPassNeeded)
325 {
326 fp = open(argv[1], O_RDONLY, "r");
327 dup2(fp, 0);
328 yyparse();
329 }
330 close(fp);
331
332 // restore stdin
333 dup2(0, stdin);
334
335 for(int i = 0; i < labels.size(); i++)
336 {
337 printf("Label: %s, Loc: %d\n", labels[i].name.c_str(), labels[i].memoryLoc);
338 }
339 return 0;
340 }
I'm using this inside a flex/bison configuration.
If that is all you need, you don't need a full two-pass assembler. If the label is not defined when you reference it, you simply output a stand-in address (say 0x0000) and have a data structure that lists all of the places with forward references and what symbol they refered to. At the end of the file (or block if you have local symbols), you simply go through that list and patch the addresses.