I'm using Swift to use Google Nearby Messages library. I followed the sample code to setup the library. I'm using both bluetooth and microphone to test the function. I dealloc the publication/subscription in viewDidDisappear(). Basically it's two lines of code:
publication = nil
subscription = nil
However, when I dismiss the view controller, sometimes the whole app will crash. The stacktrace only shows that the crash has something to do with the audio. Here's part of the stacktrace:
Crashed: AudioRecorderCallbackQueue
0 libdispatch.dylib 0x18df39f60 _dispatch_barrier_sync_f_slow + 596
1 ProjectLibs 0x1037ad8e0 std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::vector(std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > const&) + 2808
2 ProjectLibs 0x1037ad8e0 std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::vector(std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > const&) + 2808
3 ProjectLibs 0x1037ad0f4 std::__1::vector<unsigned char, std::__1::allocator<unsigned char> >::vector(std::__1::vector<unsigned char, std::__1::allocator<unsigned char> > const&) + 780
4 libsystem_blocks.dylib 0x18df7ea28 _Block_release + 144
Does anyone have any idea what may have caused the crash, and how to solve it or prevent the app from crash?
Thanks!
I set up an app to behave the way you have described yours as working. By enabling the logging, I notice that it is still sending messages for a brief period of time, which is likely where your crash is coming from.
You can enable logging with this command:
GNSMessageManager.setDebugLoggingEnabled(true)
By setting them to nil earlier in the process, I was able to get them to stop being sent before the viewcontroller was completely closed down.
The following does it at the soonest point possible (even before viewWillDisappear):
override func willMove(toParentViewController parent: UIViewController?) {
super.willMove(toParentViewController: parent)
if parent == nil {
publication = nil
subscription = nil
}
}
Related
I've run into an interesting issue with the Swift compiler, which seems to be caused by a very simple generic function. I've got a workaround, but I'd really like to understand what the underlying issue is.
In my app I have a requirement to fade in some UICollectionViewCells in a given order, sequentially, with a slight overlap between the animations.
I've implemented this using the methods below. The revealCells method takes an array of cells. If the collection is empty, it simply returns. Otherwise it animates the fade-in on the first cell in the array, and then waits a certain amount of time before making a recursive call to itself, passing all the cells except the one it just animated.
Code below:
func revealCells(cells:[UICollectionViewCell],animationTime:NSTimeInterval,overlap:Double) {
if cells.count > 0 {
let firstCell = cells.first
UIView.animateWithDuration(0.3, animations: { () -> Void in
firstCell?.alpha = 1.0
let timeMinusOverlap = animationTime - overlap
let delayTime = dispatch_time(DISPATCH_TIME_NOW,Int64(timeMinusOverlap * Double(NSEC_PER_SEC)))
dispatch_after(delayTime, dispatch_get_main_queue(), { () -> Void in
self.revealCells(self.cdr(cells),animationTime: animationTime,overlap: overlap)
})
})
}
}
}
//Returns the collection passed into the function with its first element removed
//i.e the traditional LISP cdr function
func cdr<T>(input:[T]) -> [T] {
var rVal = [T]()
if input.count == 1 {
rVal.append(input.first!)
} else {
rVal = [T](input[1...input.count-1])
}
return rVal
}
All this works fine in the simulator. But when I try to archive the build, the swift compiler crashes with the message Swift Compiler Error Command failed due to signal: Segmentation fault 11. My setup is Xcode 6.3.1 (iOSSDK 8.3), and my min deployment target is 8.3.
Fixing the problem is trivial - if I just replace the code inside the dispatch_after with:
let newCells = [UICollectionViewCell](cells[1...cells.count-1])
self.revealCells(newCells,animationTime: animationTime,overlap: overlap)
the problem goes away. So it seems to be something to do with the generic function, or possibly something block related.
Stack trace is:
0 swift 0x000000010105ba18 llvm::sys::PrintStackTrace(__sFILE*) + 40
1 swift 0x000000010105bef4 SignalHandler(int) + 452
2 libsystem_platform.dylib 0x00007fff8725ef1a _sigtramp + 26
3 libsystem_platform.dylib 0x000000000000000f _sigtramp + 2027557135
4 swift 0x00000001021a98cb llvm::AsmPrinter::EmitFunctionBody() + 4379
5 swift 0x000000010116c84c llvm::ARMAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 220
6 swift 0x0000000100d81d13 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 99
7 swift 0x00000001024d5edf llvm::FPPassManager::runOnFunction(llvm::Function&) + 495
8 swift 0x00000001024d60cb llvm::FPPassManager::runOnModule(llvm::Module&) + 43
9 swift 0x00000001024d658f llvm::legacy::PassManagerImpl::run(llvm::Module&) + 975
10 swift 0x0000000100a09b41 performIRGeneration(swift::IRGenOptions&, swift::Module*, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, swift::SourceFile*, unsigned int) + 4369
11 swift 0x0000000100a09cb3 swift::performIRGeneration(swift::IRGenOptions&, swift::SourceFile&, swift::SILModule*, llvm::StringRef, llvm::LLVMContext&, unsigned int) + 51
12 swift 0x0000000100945687 frontend_main(llvm::ArrayRef<char const*>, char const*, void*) + 6647
13 swift 0x0000000100943ae6 main + 1814
14 libdyld.dylib 0x00007fff8a46b5c9 start + 1
(a long list of program arguments, which are mostly the names of file being compiled)
1. Running pass 'Function Pass Manager' on module '/Users/tolleyr/Library/Developer/Xcode/DerivedData/ParseTestQuiz-fgnfjkxxlyqfnrfrfntgtsjnrcfv/Build/Intermediates/ArchiveIntermediates/ParseTestQuiz/IntermediateBuildFilesPath/ParseTestQuiz.build/Release-iphoneos/ParseTestQuiz.build/Objects-normal/armv7/QuizQuestionViewController.o'.
2. Running pass 'ARM Assembly / Object Emitter' on function '#_TFC13ParseTestQuiz26QuizQuestionViewController13viewDidAppearfS0_FSbT_'
(the last part enabled me to figure out what code was causing the problem). The command being run was CompileSwift normal armv7
I'm going to file a radar for this, since the compiler itself is crashing , but thought I'd post it here in case anyone has an idea of what might be going on, or has run into the same issue.
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.
I've recently read The Swift Programming Language document, which introduced to me Extensions, and so I tried to implement this code:
extension SKTexture{
var size: CGSize {
return self.size()
}
}
Later in the same code, I try to access a property of the SKTexture:
someTexture.size.width
However, when I run the app, I get a EXC_BAD_ACCESS
I have also noticed that even if I don't try to access the width property via my new computed property, implementing someTexture.size().width instead of someTexture.size.width , I get this error. Could someone explain me what I'm doing wrong?
Short answer:
For a class derived from NSObject, a Swift property
which has the same name as an existing Objective-C method replaces that method.
Therefore in your case,
var size: CGSize {
return self.size()
}
calls itself recursively until the program aborts with a stack overflow
(well, that's what this site is for :).
If you choose a different name for the property, e.g.
var theSize: CGSize {
return self.size()
}
then everything works nicely.
Long answer:
SKTexture is a subclass of NSObject. Therefore all Swift properties are
"Objective-C compatible". As a consequence, the compiler generates a getter
method that can be called from Objective-C code. The getter method for the
size property is a -size method. So you have now two -size methods:
The original one from SKTexture and a second one defined in your Swift code.
If you do the same with your own Objective-C class defined in the same project
then you will get a linker warning:
instance method 'size' in category from /Users/.../main.o overrides
method from class in /Users/.../MyClass.o
If the Objective-C class is defined in a external framework (as in your case)
the linker does not notice the conflict.
Now return self.size() calls the generated Objective-C getter method, which in turn
calls the extension method. This leads to "infinite" recursion and ultimately
to a stack overflow.
This is confirmed by the stack backtrace which you can get with the lldb bt
command when the program has crashed:
* thread #1: tid = 0x3d2ef, 0x000000010fb15e01 libobjc.A.dylib`objc::DenseMapBase, unsigned long, true, objc::DenseMapInfo > >, DisguisedPtr, unsigned long, objc::DenseMapInfo >, true>::FindAndConstruct(DisguisedPtr const&) + 21, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x7fff51b9cfe8)
frame #0: 0x000000010fb15e01 libobjc.A.dylib`objc::DenseMapBase, unsigned long, true, objc::DenseMapInfo > >, DisguisedPtr, unsigned long, objc::DenseMapInfo >, true>::FindAndConstruct(DisguisedPtr const&) + 21
frame #1: 0x000000010fb13e14 libobjc.A.dylib`objc_object::sidetable_retain() + 94
* frame #2: 0x000000010d8674d9 cdtest2`ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize(self=0x00007fcceea020f0) + 25 at AppDelegate.swift:19
frame #3: 0x000000010d867542 cdtest2`#objc ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize + 34 at AppDelegate.swift:0
frame #4: 0x000000010d8674ed cdtest2`ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize(self=0x00007fcceea020f0) + 45 at AppDelegate.swift:19
frame #5: 0x000000010d867542 cdtest2`#objc ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize + 34 at AppDelegate.swift:0
frame #6: 0x000000010d8674ed cdtest2`ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize(self=0x00007fcceea020f0) + 45 at AppDelegate.swift:19
frame #7: 0x000000010d867542 cdtest2`#objc ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize + 34 at AppDelegate.swift:0
frame #8: 0x000000010d8674ed cdtest2`ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize(self=0x00007fcceea020f0) + 45 at AppDelegate.swift:19
...
frame #149556: 0x000000010d8674ed cdtest2`ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize(self=0x00007fcceea020f0) + 45 at AppDelegate.swift:19
frame #149557: 0x000000010d867542 cdtest2`#objc ext.cdtest2.ObjectiveC.SKTexture.size.getter : C.CGSize + 34 at AppDelegate.swift:0
frame #149558: 0x000000010d8694e0 cdtest2`cdtest2.AppDelegate.application (application=0x00007fccee8005a0, launchOptions=None, self=0x00007fccebc06410)(ObjectiveC.UIApplication, didFinishLaunchingWithOptions : Swift.Optional>) -> Swift.Bool + 112 at AppDelegate.swift:83
frame #149559: 0x000000010d8697b0 cdtest2`#objc cdtest2.AppDelegate.application (cdtest2.AppDelegate)(ObjectiveC.UIApplication, didFinishLaunchingWithOptions : Swift.Optional>) -> Swift.Bool + 560 at AppDelegate.swift:0
...
frame #149572: 0x000000010d86bcaa cdtest2`main + 42 at AppDelegate.swift:0
frame #149573: 0x00000001102f0145 libdyld.dylib`start + 1
This (hopefully) explains also why the problem occurs with both someTexture.size().width and someTexture.size.width:
In both cases, the custom extension method is called.
I have some trouble with managing memory in my function. Valgrid says I'm having a memory leak after the convert-function. Could it be because of the data is not being properly released? I've tried to use temp-pointers, but my program either crashes or is not working properly. Have someone encountered this problem before?
this->images.push_back(new cv::Mat()); //ID
cv::threshold(*this->images[MASK], *this->images[ID], 0.0, 1.0, cv::THRESH_BINARY);
this->images[ID]->convertTo(*this->images[ID], CV_32SC1);
This is the valgrid output:
==5663== 64,339,996 bytes in 1 blocks are possibly lost in loss record 380 of 380
==5663== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5663== by 0x4E95117: cv::fastMalloc(unsigned long) (in /usr/local/lib/libopencv_core.so.2.4.9)
==5663== by 0x4F31F38: cv::Mat::create(int, int const*, int) (in /usr/local/lib/libopencv_core.so.2.4.9)
==5663== by 0x4F39CF9: cv::_OutputArray::create(cv::Size_<int>, int, int, bool, int) const (in /usr/local/lib/libopencv_core.so.2.4.9)
==5663== by 0x4EB9373: cv::Mat::convertTo(cv::_OutputArray const&, int, double, double) const (in /usr/local/lib/libopencv_core.so.2.4.9)
==5663== by 0x40D168: DataFrame::init() (DataFrame.cpp:68)
==5663== by 0x40C943: DataFrame::DataFrame(char const*, LeafClassifier*) (DataFrame.cpp:31)
==5663== by 0x414A19: DataHandler::loadFrame() (DataHandler.cpp:68)
==5663== by 0x406680: main (main.cpp:58)
please don't store pointers to Mat in your vector(or anywhere else !).
those things are refcounted internally, like smartpointers, and you're wrecking that by storing/copying pointers (a vector of pointers to smartpointers would sound silly anyway, no?).
use a plain vector<Mat>, trade some additional ~56 bytes per item against sound sleep tonight ;)
I've been struggling with a strange problem for two days now. I went through every related question on SO but none solved the issue. I'm working on Xcode5. I'm using ARC and CoreData.
On iOS7 (simulator):
`[CFString release]: message sent to deallocated instance`
Thread 1, Queue : com.apple.main-thread
0 0x03c7d3ba in __kill ()
1 0x03c7c4b8 in kill$UNIX2003 ()
2 0x0347a921 in ___forwarding___ ()
3 0x0347a4ee in _CF_forwarding_prep_0 ()
4 0x02b7b002 in -[NSConcreteAttributedString dealloc] ()
5 0x02f66692 in objc_object::sidetable_release(bool) ()
6 0x02f65e81 in objc_release ()
7 0x02f66ce7 in (anonymous namespace)::AutoreleasePoolPage::pop(void*) ()
8 0x00739bc4 in CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) ()
9 0x0345253e in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
10 0x0345248f in __CFRunLoopDoObservers ()
11 0x034303b4 in __CFRunLoopRun ()
12 0x0342fb33 in CFRunLoopRunSpecific ()
13 0x0342f94b in CFRunLoopRunInMode ()
14 0x04bd19d7 in GSEventRunModal ()
15 0x04bd17fe in GSEventRun ()
16 0x0196794b in UIApplicationMain ()
17 0x0000262d in main
The Zombies Instruments point to the second line where I set the cell's text labels:
cell.txtLabel.text = _reservationModule.newReservationText;
cell.subtitleTxtLabel.text = _reservationModule.newReservationSubtitle;
_reservationModule is a Core Data entity featuring the string properties. It's defined in the view controller as #property (nonatomic, strong) ReservationModule *reservationModule;
The Zombie history:
Event Type ∆ RefCt RefCt Timestamp Responsible Library Responsible Caller
Malloc/Retain/Release (4) 01:01.114.922 CoreData _prepareResultsFromResultSet
0 Malloc +1 1 01:01.114.922 CoreData _prepareResultsFromResultSet
1 Retain +1 2 01:01.116.184 CoreData -[_CDSnapshot mutableCopy]
2 Release -1 1 01:01.318.588 MyApp -[ReservationModuleChoice2ViewController configureSubtitleImageTableViewCell:atIndexPath:]
3 Release -1 0 01:05.004.359 CoreData -[_CDSnapshot dealloc]
4 Zombie -1 01:07.441.465 CoreData -[_CDSnapshot dealloc]
They've never occurred on Xcode 4.6.x though.
Any help is highly appreciated!
Thanks!
The answer is trivial and hasn't anything to do with retain counters...
I oversaw that it isn't allowed to name variables/properties starting with new with ARC enabled. This obviously resulted in an over release thus generating the error...
From Apple documentation: https://developer.apple.com/library/ios/releasenotes/objectivec/rn-transitioningtoarc/introduction/introduction.html
To allow interoperation with manual retain-release code, ARC imposes a
constraint on method naming:
You cannot give an accessor a name that begins with new. This in turn
means that you can’t, for example, declare a property whose name
begins with new unless you specify a different getter