I'm using the Twilio Conversations Client SDK in an iOS app. It works fine, but I'm getting a crash when I try and create a new TCHMessageOptions object to send a message.
TCHMessageOptions *message = [[TCHMessageOptions alloc] withBody:value];
The crash is happening inside this method. Xcode just shows me the assembly in the debugger.
I've also tried creating a TCHMessageOptions with the other instance methods, but they crash too.
#0 0x00000001a05b32e4 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::operator=(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) ()
#1 0x0000000102f90f34 in rtd::TMessageOptions::withBody(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) [inlined] at /Users/distiller/rtd-sdk-monorepo/cpp/chat-lib/Interface/Chat/ITMOptions.h:102
#2 0x0000000102f90f28 in -[TCHMessageOptions withBody:] at /Users/distiller/rtd-sdk-monorepo/sdk/ios/convo/Sources/TCHMessageOptions.mm:72
Twilio Developer is here.
The best way to solve your issue is to file a support ticket.
In general, version of the SDK you are using is required to answer your question.
While setting body for a message options, make sure that body is available (not nil) and it has type of a NSString.
Related
I'm trying to import a library of objective-c into swift. I've created a bridging file (a .h) and added it to the build settings, in Objective-C Bridging Header under Swift Compiler - General. Into the bridging file I've added #import <MyFramework>.
The problem comes now. This framework is private and particular. To install it correctly in Objective-C they told you to change the main.m to main.mm (which don't have sense in swift).
When I try to build the project I get 111 errors (Apple Mach-O linker error). It start with:
Undefined symbols for architecture x86_64:
And all the errors are similar to:
std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__grow_by(unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long)", referenced from:
So I really don't understand it. Do you have any clue why is this happening?
If you need me to post some more information just tell me.
Thanks for the help.
.mm extension is used for using c++ code .. std :: is c++ code. you just need to edit yourBridgingHeaderFile.m to YourBridingHeaderName.mm and you would be good to go
I am trying to compile my first Objective-C program. It is just the simple "Programming is fun!" code:
#import <Foundation/Foundation.h>
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSLog (#"Programming is fun!");
[pool drain];
return 0;
}
I downloaded the gnustep-msys-system-0.30.0-setup.exe and gnustep-core-0.34.0-setup.exe and installed them in that order. I copied the file named prg1.m (which contain the previous code) to the /GNUstep/msys/1.0/home/username folder. I opened the GNUstep shell and proceeded to issue the following command:
gcc -o prg1 prg1.m -I /GNUstep/System/Library/Headers -L /GNUstep/System/Library/Libraries -lobjc -lgnustep-base -fconstant-string-class=NSConstantString
I get the following output:
In file included from C:/GNUstep/GNUstep/System/Library/Headers/GNUstepBase/GSCo
nfig.h:281:0,
from C:/GNUstep/GNUstep/System/Library/Headers/GNUstepBase/GSVe
rsionMacros.h:219,
from C:/GNUstep/GNUstep/System/Library/Headers/Foundation/Found
ation.h:30,
from prg1.m:1:
c:\mingw\include\w32api.h:27:2: warning: #warning WARNING - The w32api.h header
file is deprecated and will be removed. [-Wcpp]
#warning WARNING - The w32api.h header file is deprecated and will be removed.
^
In file included from C:/GNUstep/GNUstep/System/Library/Headers/Foundation/NSPor
tMessage.h:30:0,
from C:/GNUstep/GNUstep/System/Library/Headers/Foundation/Found
ation.h:99,
from prg1.m:1:
C:/GNUstep/GNUstep/System/Library/Headers/Foundation/NSPort.h:210:3: error: unkn
own type name 'WSAEVENT'
WSAEVENT eventListener;
^
Anyone know why I am getting this error at the end? I have been googling it for a couple of hours without much luck. Any help would be greatly appreciated. Thanks in advance.
The issue you have seems to be in the foundation/foundation.h library you downloaded. The real question here is it seems you are using a PC as you downloaded a .exe thus I wonder, why are you programing in Objective-C? The only platform that still uses Objective-C is the iOS/Apple platform which you really can not effectively code for with out an Apple computer. If you just want to learn Objective-C because you plan to get into iOS soon then I understand but if you do not plan to do this then there is no reason to learn Objective-C, you are better off learning Java, C# or C++.
The more specific answer to your question is that WSAEVENT is a signal used in windows threads. Chances are somehow your system is not finding the support for it correctly it may be because the w32api.h was removed which had the reference to where the WSAEVENT was located.
I am running my program though valgrind, but it appears it is generating errors caused by the tool itself? All my errors look like the following, but from reading through other posts, it seems that usually the at line tells you where in your program the offending malloc occurs, but all my at lines are coming from valgrind. Are these legit errors in my program?
==10551== 32,808 (24 direct, 32,784 indirect) bytes in 1 blocks are definitely lost in loss record 840 of 843
==10551== at 0x54D7: malloc_zone_malloc (in /usr/local/Cellar/valgrind/3.8.1/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==10551== by 0x7C5171: NXCreateMapTableFromZone (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7C4722: _read_images (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7C39EB: map_images_nolock (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7C34F3: map_images (in /usr/lib/libobjc.A.dylib)
==10551== by 0x7FFF5FC04936: dyld::notifyBatchPartial(dyld_image_states, bool, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==10551== by 0x7FFF5FC0467C: dyld::registerImageStateBatchChangeHandler(dyld_image_states, char const* (*)(dyld_image_states, unsigned int, dyld_image_info const*)) (in /usr/lib/dyld)
==10551== by 0xA99ED9: dyld_register_image_state_change_handler (in /usr/lib/system/libdyld.dylib)
==10551== by 0x7C204C: _objc_init (in /usr/lib/libobjc.A.dylib)
==10551== by 0x6BB27: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==10551== by 0x7FFF5FC13377: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==10551== by 0x7FFF5FC13761: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)
==10551==
I used homebrew to install valgrind. It probably has something to do with this error:
==10551== WARNING: Support on MacOS 10.8 is experimental and mostly broken.
==10551== WARNING: Expect incorrect results, assertions and crashes.
but I just want to make sure (by someone who has used this before) that these errors are not coming from my program. (I am on 10.8).
Valgrind replaces the default implementations of the library functions allocating and deallocating memory (malloc(), calloc(), realloc(), free() being the most important), by its own to track calls to them and do the bookkeeping. The backtrace shows the call stack to the malloc() call that allocated the memory that was never free()'d. So the problem doesn't lie in malloc() itself - but rather in the code calling malloc() without corresponding free().
The error-checking tools detect numerous problems in the system libraries, such as the C library, which come pre-installed with your OS. You can't easily fix these, but you don't want to see these errors (and yes, there are many!) So Valgrind reads a list of errors to suppress at startup. A default suppression file is created by the ./configure script when the system is built.
You can modify and add to the suppressions file at your leisure, or, better, write your own. Multiple suppression files are allowed. This is useful if part of your project contains errors you can't or don't want to fix, yet you don't want to continuously be reminded of them.
Note: By far the easiest way to add suppressions is to use the --gen-suppressions=yes option described in Core Command-line Options. This generates suppressions automatically. For best results, though, you may want to edit the output of --gen-suppressions=yes by hand, in which case it would be advisable to read through this section.
Each error to be suppressed is described very specifically, to minimise the possibility that a suppression-directive inadvertently suppresses a bunch of similar errors which you did want to see. The suppression mechanism is designed to allow precise yet flexible specification of errors to suppress.
I'm trying to use a static library, and the categories that are in it aren't being used at run-time. There are no compile-time errors, but when I go to run, I get the standard 'unrecognized selector sent to instance' message and my app crashes.
Many solutions say to add -ObjC -all_load to the "Other Linker Flags" property in your application's target (many others say that as of XCode 4, that is no longer needed, this is the only reason I have bothered to include the XCode version). I've tried it and I get 115 errors during build:
Undefined symbols for architecture i386:
"_CLLocationCoordinate2DMake", referenced from:
-[QMapElement init] in libQuickDialog.a(QMapElement.o)
"_OBJC_CLASS_$_MKMapView", referenced from:
objc-class-ref in libQuickDialog.a(QMapViewController.o)
"_OBJC_CLASS_$_MKPinAnnotationView", referenced from:
objc-class-ref in libQuickDialog.a(QMapViewController.o)
"std::istream::gcount() const", referenced from:
GT::AES::decode(std::istream&, std::ostream&, unsigned int&, bool) in GD(gtaes.o)
GT::AES::encode(std::istream&, std::ostream&, unsigned int&, bool) in GD(gtaes.o)
"std::string::find_first_of(char const*, unsigned long, unsigned long) const", referenced from:
-[GDSetPasswordViewController checkPasswordStrength:] in GD(GDSetPasswordViewController.o)
GD::EacpCReq::EacpCReq(std::string, std::string, GT::Dbb&) in GD(GDEacpCommands.o)
GD::RawSocket::connect() in GD(GDRawSocket.o)
"std::string::copy(char*, unsigned long, unsigned long) const", referenced from:
GD::Socket::toString() const in GD(GDSocket.o)
(and so on, that's about 5 or 6 of the 115).
Whether I have either of those linker flags, or both, I get the exact same set of errors.
Not sure if this is the culprit, or just coincidental, but after looking at the errors a little more closely, it seems like they are all from one of two 3rd-party libraries I am using. One as an installed .framework, the other as a regular static library. Maybe I need to do something to their builds (if possible), as well?
Thanks!
It seems to me that the error message is pointing to a few missing frameworks:
CoreLocation (_CLLocationCoordinate2DMake symbol);
MapKit (_OBJC_CLASS_$_MKPinAnnotationView symbol);
C++ standard library.
Try to include them with your target... specifically, for the C++ standard library, you should check a specific build setting in Xcode under "Apple LLVM Compiler x.y - Language".
This will not rule out the chance of other missing frameworks, of course...
I'm having an issue where my iOS App is crashing on exit and I've narrowed it down to this:
// File.h
struct Name {
NSString *name;
}
// File.mm
Name names[] = {
#"foo",
#"bar",
};
When the App exits (pushing the home button on the iPad), I get a crash in objc_msgSend with a EXC_BAD_ACCESS (SIGSEGV). It's happening the the destructor Name::~Name().
0 libobjc.A.dylib 0x37586e3a objc_release + 10
1 MyApp 0x0014abfc Name::~Name() (NameManager.h:21)
2 MyApp 0x0014ab42 Name::~Name() (NameManager.h:21)
3 MyApp 0x0014ad94 __cxx_global_array_dtor + 120
4 libsystem_c.dylib 0x36bba1cc __cxa_finalize + 216
5 libsystem_c.dylib 0x36b854f6 exit + 6
Keep in mind that this is in a .mm file, so it's being compiled as obj-c++.
This has worked fine for months and months. I don't know exactly when it started happening, but I suspect it was when I updated to xcode 4.4.
NSString literals should be protected (or always have been) against multiple releases, but I don't think that is happening here anyway.
Does anyone know if something changed in xcode 4.4?
I can fix the crash by doing:
struct Name {
__unsafe_unretained NSString *name;
}
But I hate to do that without understanding why what has worked before no longer works. Or maybe it never should have worked. I also fear a memory over-write, so this might just be a symptom.
This happens in both DEBUG and RELEASE.
UPDATE: I put a breakpoint in ~Name() and verified that memory is not corrupt. LLDB is able to dump the NSString OK. But it crashes when I step.
When you declare a "Plain Old Data" struct in Objective-C++ that contains Objective-C objects with ARC turned on, the compiler is obligated to provide a destructor that correctly deallocates the ObjC members of the struct, even if you do not write them yourself.
This restriction does not apply in Objective-C++. However, nontrivally
ownership-qualified types are considered non-POD: in C++11 terms, they
are not trivially default constructible, copy constructible, move
constructible, copy assignable, move assignable, or destructible. It
is a violation of C++’s One Definition Rule to use a class outside of
ARC that, under ARC, would have a nontrivially ownership-qualified
member.
When you declared that Name structure, the compiler would have written you a destructor involving an implicit strongly held Objective-C object. At execution time, what this means is that the C++ destructor erases what it expects is a C++ structure and instead winds up borking the pointers to the string. With no valid pointer around, the -release ARC tries to send segfaults when it tries to dereference a nonexistent receiver.
When you declare an Objective-C member __unsafe_unretained, it tells ARC to exclude it from the destructor it would have to write, thus the struct is just destroyed, and the -release is never sent. It is recommended that you mark all Objective-C objects in structures or classes as __unsafe_unretained and provide the appropriate memory management yourself, because ARC can significantly complicate object lifetimes across languages.