Question

I am sure most of you have dealt with a similar issue. Well, it turns out I'm trying to run this simple program with parse, but I've encountered an interesting issue pertaining to the program's assemblies and it's thread-composition.

The program found no compiling errors

<!-- language: «lang-c» -->

«#import "PCommonsAppDelegate.h"

@implementation PCommonsDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:        (NSDictionary *)launchOptions
{
// Override point for customization after application launch.

[Parse setApplicationId:@"100000000pUgmUXDRT64dF6mTT8mY"
              clientKey:@"aLT1itwGri41wZ5Nva8WBb6hWGVBGkjk5aWvmDTm"];

return YES;

} »

The main looks like this.

<!-- language: «lang-c» -->

«//  main.m
 //PCommons using PARSE
 //  
 //

#import <UIKit/UIKit.h>

#import "PCommonsAppDelegate.h"

int main(int argc, char *argv[])
{
@autoreleasepool {
    return UIApplicationMain(argc, argv, nil, NSStringFromClass([PCommonsAppDelegate     class]));
    }
}

»

The log output looks like this:

<!-- language: «lang-bsh» -->

«2013-07-30 13:52:48.930 ParseTask[691:c07]
 *** Assertion failure in -[UITableView_configureCellForDisplay:forIndexPath:], 
 /SourceCache/UIKit_Sim/UIKit-2380.17/UITableView.m:5471

 2013-07-30 13:52:48.931 ParseExample[691:c07] *** Terminating app due to uncaught   exception 
'NSInternalInconsistencyException', reason: 'UITableView dataSource 
must return a cell from tableView:cellForRowAtIndexPath:'
*** First throw call stack:
(0x213d012 0x1f62e7e 0x213ce78 0x1c21665 
0x1185c1b 0x111a40c 0x1185a7b 0x118a919 
0x118a9cf  0x11731bb 0x1183b4b 0x11202dd 
0x1f766b0 0x565fc0 0x55a33c 0x55a150 
0x4d80bc 0x4d9227 0x4d98e2 0x2105afe  
0x2105a3d 0x20e37c2 0x20e2f44 0x20e2e1b 
0x2b6a7e3 0x2b6a668 0x10cfffc 0x2b3d 0x2a65)

libc++abi.dylib: terminate called throwing an exception»

And, when taking a look at the Thread structure, I've noticed there is a THREAD 1: signal SIGBRT 'breakpoint' affecting the stacks. For example:

I was made aware of

0x93e0ea72: movl 26027(%edx), %edx

on UIApplicationMain.

Thread 1(main thread) :: 0__pthread_kill

«libsystem_kernel.dylib`__pthread_kill:
0x93e0ea60:  movl   $524616, %eax
0x93e0ea65:  calll  0x93e104c2 ; _sysenter_trap
0x93e0ea6a:  jae    0x93e0ea7a ; __pthread_kill + 26
0x93e0ea6c:  calll  0x93e0ea71 ; __pthread_kill + 17
0x93e0ea71:  popl   %edx
0x93e0ea72:  movl   26027(%edx), %edx
0x93e0ea78:  jmpl   *%edx
0x93e0ea7a:  ret    
0x93e0ea7b:  nop    

»

the breakpoint raised also on thread 2, thread 3, thread 4...until thread 13 which makes me wonder if it's a problem with sockets.

How do I compile this effectively?

Was it helpful?

Solution

You need to provide a proper data source for your UITableView. Somewhere you have a UITableView and you have pointed it at a data source. That class must implement tableView:cellForRowAtIndexPath: and return a proper UITableViewCell.

See https://www.parse.com/docs/ios/api/Classes/PFQueryTableViewController.html#//api/name/tableView:cellForRowAtIndexPath:object:

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top