Search Results

Search found 4462 results on 179 pages for 'snow crash'.

Page 12/179 | < Previous Page | 8 9 10 11 12 13 14 15 16 17 18 19  | Next Page >

  • Do Java programs ever crash?

    - by singh
    Hi I am a c++ programmer , I know little bit about java. I know that java programmers do not have to work with memory directly like C++. I also know that most crashes in C++ appliations are due to memory corruptions. So can an application written in Java crash due to a memory related issue? Thanks

    Read the article

  • VSS causing crash in VS 2008

    - by David
    We use Visual Studio 2008, with visual source safe v8. Lately, I seem to be getting a lot more crashes than usual, mainly when viewing history (comparing, etc.). I have taken a screencapture of the series of dialog boxes that will always appear, leading up to the crash: http://img529.imageshack.us/img529/1360/msvscrash.jpg Does anyone know what could be causing this? Thanks.

    Read the article

  • iPhone Crash Report

    - by skywalker168
    My iPhone app is crashing for certain users in UK. I tried using UK timezone and their region format but couldn't reproduce the crash on my iPhone or emulator. Eventually got a crash report and I was able to symbolicate it. However, I have a hard time understanding the results. It appears thread 0 crashed in a system library. The only call from my app is main.m. Thread 4 has something familiar. It was at: My App 0x00004cca -[TocTableController parser:didEndElement:namespaceURI:qualifiedName:] (TocTableController.m:1369) Code is: NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease]; It crashed doing alloc/init? Out of memory, only in UK? Any one has idea what might be cause? Thanks in advance! Date/Time: 2010-04-06 21:41:17.629 +0100 OS Version: iPhone OS 3.1.3 (7E18) Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x00000000, 0x00000000 Crashed Thread: 0 Thread 0 Crashed: 0 libSystem.B.dylib 0x00090b2c __kill + 8 1 libSystem.B.dylib 0x00090b1a kill + 4 2 libSystem.B.dylib 0x00090b0e raise + 10 3 libSystem.B.dylib 0x000a7e34 abort + 36 4 libstdc++.6.dylib 0x00066390 __gnu_cxx::__verbose_terminate_handler() + 588 5 libobjc.A.dylib 0x00008898 _objc_terminate + 160 6 libstdc++.6.dylib 0x00063a84 __cxxabiv1::__terminate(void (*)()) + 76 7 libstdc++.6.dylib 0x00063afc std::terminate() + 16 8 libstdc++.6.dylib 0x00063c24 __cxa_throw + 100 9 libobjc.A.dylib 0x00006e54 objc_exception_throw + 104 10 Foundation 0x0000202a __NSThreadPerformPerform + 574 11 CoreFoundation 0x000573a0 CFRunLoopRunSpecific + 1908 12 CoreFoundation 0x00056c18 CFRunLoopRunInMode + 44 13 GraphicsServices 0x000041c0 GSEventRunModal + 188 14 UIKit 0x00003c28 -[UIApplication _run] + 552 15 UIKit 0x00002228 UIApplicationMain + 960 16 My App 0x00002414 main (main.m:14) 17 My App 0x000023e4 start + 32 Thread 1: 0 libSystem.B.dylib 0x00001488 mach_msg_trap + 20 1 libSystem.B.dylib 0x00004064 mach_msg + 60 2 CoreFoundation 0x00057002 CFRunLoopRunSpecific + 982 3 CoreFoundation 0x00056c18 CFRunLoopRunInMode + 44 4 WebCore 0x000841d4 RunWebThread(void*) + 412 5 libSystem.B.dylib 0x0002b780 _pthread_body + 20 Thread 2: 0 libSystem.B.dylib 0x00001488 mach_msg_trap + 20 1 libSystem.B.dylib 0x00004064 mach_msg + 60 2 CoreFoundation 0x00057002 CFRunLoopRunSpecific + 982 3 CoreFoundation 0x00056c18 CFRunLoopRunInMode + 44 4 Foundation 0x0005a998 +[NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:] + 172 5 Foundation 0x00053ac6 -[NSThread main] + 42 6 Foundation 0x00001d0e __NSThread__main__ + 852 7 libSystem.B.dylib 0x0002b780 _pthread_body + 20 Thread 3: 0 libSystem.B.dylib 0x000262c0 select$DARWIN_EXTSN + 20 1 CoreFoundation 0x000207e2 __CFSocketManager + 342 2 libSystem.B.dylib 0x0002b780 _pthread_body + 20 Thread 4: 0 libSystem.B.dylib 0x00015764 fegetenv + 0 1 libSystem.B.dylib 0x0002a160 time + 8 2 libicucore.A.dylib 0x00009280 uprv_getUTCtime + 6 3 libicucore.A.dylib 0x0000a492 icu::Calendar::getNow() + 2 4 libicucore.A.dylib 0x0000a2a0 icu::GregorianCalendar::GregorianCalendar(icu::Locale const&, UErrorCode&) + 86 5 libicucore.A.dylib 0x0000a242 icu::GregorianCalendar::GregorianCalendar(icu::Locale const&, UErrorCode&) + 2 6 libicucore.A.dylib 0x000098ec icu::Calendar::createInstance(icu::TimeZone*, icu::Locale const&, UErrorCode&) + 160 7 libicucore.A.dylib 0x00008762 icu::SimpleDateFormat::initializeCalendar(icu::TimeZone*, icu::Locale const&, UErrorCode&) + 28 8 libicucore.A.dylib 0x0000bd2c icu::SimpleDateFormat::SimpleDateFormat(icu::Locale const&, UErrorCode&) + 82 9 libicucore.A.dylib 0x0000bcd2 icu::SimpleDateFormat::SimpleDateFormat(icu::Locale const&, UErrorCode&) + 2 10 libicucore.A.dylib 0x000084aa icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) + 148 11 libicucore.A.dylib 0x0000840e icu::DateFormat::createDateTimeInstance(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) + 14 12 libicucore.A.dylib 0x00008336 udat_open + 70 13 CoreFoundation 0x0006c2e0 CFDateFormatterCreate + 252 14 Foundation 0x00019fd2 -[NSDateFormatter _regenerateFormatter] + 198 15 Foundation 0x00019ebe -[NSDateFormatter init] + 150 16 My App 0x00004cca -[TocTableController parser:didEndElement:namespaceURI:qualifiedName:] (TocTableController.m:1369) 17 Foundation 0x000380e6 _endElementNs + 442 18 libxml2.2.dylib 0x00011d2c xmlParseXMLDecl + 1808 19 libxml2.2.dylib 0x0001ef08 xmlParseChunk + 3300 20 Foundation 0x0003772a -[NSXMLParser parse] + 178 21 My App 0x000055e2 -[TocTableController parseTocData:] (TocTableController.m:1120) 22 Foundation 0x00053ac6 -[NSThread main] + 42 23 Foundation 0x00001d0e __NSThread__main__ + 852 24 libSystem.B.dylib 0x0002b780 _pthread_body + 20 Thread 0 crashed with ARM Thread State: r0: 0x00000000 r1: 0x00000000 r2: 0x00000001 r3: 0x384e83cc r4: 0x00000006 r5: 0x001d813c r6: 0x2ffff2b8 r7: 0x2ffff2c8 r8: 0x38385cac r9: 0x0000000a r10: 0x0002c528 r11: 0x0012be50 ip: 0x00000025 sp: 0x2ffff2c8 lr: 0x33b3db21 pc: 0x33b3db2c cpsr: 0x00070010

    Read the article

  • Hard crash when drawing content for CALayer using quartz

    - by Lukasz
    I am trying to figure out why iOS crash my application in the harsh way (no crash logs, immediate shudown with black screen of death with spinner shown for a while). It happens when I render content for CALayer using Quartz. I suspected the memory issue (happens only when testing on the device), but memory logs, as well as instruments allocation logs looks quite OK. Let me past in the fatal function: - (void)renderTiles{ if (rendering) { //NSLog(@"====== RENDERING TILES SKIP ======="); return; } rendering = YES; CGRect b = tileLayer.bounds; CGSize s = b.size; CGFloat imageScale = [[UIScreen mainScreen] scale]; s.height *= imageScale; s.width *= imageScale; dispatch_async(queue, ^{ NSLog(@""); NSLog(@"====== RENDERING TILES START ======="); NSLog(@"1. Before creating context"); report_memory(); CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB(); NSLog(@"2. After creating color space"); report_memory(); NSLog(@"3. About to create context with size: %@", NSStringFromCGSize(s)); CGContextRef ctx = CGBitmapContextCreate(NULL, s.width, s.height, 8, 0, colorSpace, kCGImageAlphaPremultipliedLast); NSLog(@"4. After creating context"); report_memory(); CGAffineTransform flipTransform = CGAffineTransformMake(1.0, 0.0, 0.0, -1.0, 0.0, s.height); CGContextConcatCTM(ctx, flipTransform); CGRect tileRect = CGRectMake(0, 0, tileImageScaledSize.width, tileImageScaledSize.height); CGContextDrawTiledImage(ctx, tileRect, tileCGImageScaled); NSLog(@"5. Before creating cgimage from context"); report_memory(); CGImageRef cgImage = CGBitmapContextCreateImage(ctx); NSLog(@"6. After creating cgimage from context"); report_memory(); dispatch_sync(dispatch_get_main_queue(), ^{ tileLayer.contents = (id)cgImage; }); NSLog(@"7. After asgning tile layer contents = cgimage"); report_memory(); CGColorSpaceRelease(colorSpace); CGContextRelease(ctx); CGImageRelease(cgImage); NSLog(@"8. After releasing image and context context"); report_memory(); NSLog(@"====== RENDERING TILES END ======="); NSLog(@""); rendering = NO; }); } Here are the logs: ====== RENDERING TILES START ======= 1. Before creating context Memory in use (in bytes): 28340224 / 519442432 (5.5%) 2. After creating color space Memory in use (in bytes): 28340224 / 519442432 (5.5%) 3. About to create context with size: {6324, 5208} 4. After creating context Memory in use (in bytes): 28344320 / 651268096 (4.4%) 5. Before creating cgimage from context Memory in use (in bytes): 153649152 / 651333632 (23.6%) 6. After creating cgimage from context Memory in use (in bytes): 153649152 / 783159296 (19.6%) 7. After asgning tile layer contents = cgimage Memory in use (in bytes): 153653248 / 783253504 (19.6%) 8. After releasing image and context context Memory in use (in bytes): 21688320 / 651288576 (3.3%) ====== RENDERING TILES END ======= Application crashes in random places. Sometimes when reaching en of the function and sometime in random step. Which direction should I look for a solution? Is is possible that GDC is causing the problem? Or maybe the context size or some Core Animation underlying references?

    Read the article

  • How to resolve "HTTP/1.1 403 Forbidden" errors from iCal/CalDAV server after upgrade to Snow Leopard Server?

    - by morgant
    We recently upgraded our Open Directory Master & Replica to Mac OS X 10.6.4 Snow Leopard Server. We had a mismatched server FQDN & LDAP Search Base/Kerberos Realm, so we exported all users & groups, created the new Open Directory Master w/matching FQDN & Search Base/Realm, reimported users & groups, and re-bound all servers & workstations to the new OD Master. At the same time as all of this, we upgraded our iCal/CalDAV server to Mac OS X 10.6.4 Snow Leopard Server. Ever since doing so, we've seen the following issues with our iCal/CalDAV server and iCal clients on both Mac OS X 10.5 Leopard & Mac OS X 10.6: If a user attempts to move or delete an event (single or repeating) that was created prior to the upgrade to 10.6 Server, they get the following error: Access to "blah" in "blah" in account "blah" is not permitted. The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVWriteEntityQueueableOperation. New users added to the directory get the following error when attempting to add their account to in iCal's preferences: The user "blah" has no configured pricipals. Confirm with your network administrator that your account has at least one CalDAV principal configured. Interestingly, we've since discovered that users seem to be able to delete individual events from an old repeating event without error, but that's a massive amount of work to get rid of a repeating event. I will note that we have not yet added an SRV record in DNS as instructed on page 19 of iCal_Server_Admin_v10.6.pdf. Further Investigation: In this particular case, a user is attempting to decline repeating events created prior to the upgrade to Snow Leopard Server. Granting the user full write access with sudo calendarserver_manage_principals --add-write-proxy users:user1 users:user2 (which did work) doesn't allow deletion of the events. Still get the usual error: Access to "blah blah" in "blah blah" in account "blah blah" is not permitted. The server responded: "HTTP/1.1 403 Forbidden" to operation CalDAVWriteEntityQueueableOperation. The error that shows up in /var/log/caldavd/error.log on the iCal Server when attempting to delete one of the events is: 2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.extensions#info] PUT /calendars/__uids__/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/calendar/XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.ics HTTP/1.1 2011-03-17 15:14:30-0400 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.scheduling.implicit#error] Cannot change ORGANIZER: UID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX And the error in /var/log/system.log on the client is: Mar 17 15:14:30 192-168-21-169-dhcp iCal[33509]: CalDAV CalDAVWriteEntityQueueableOperation failed: status 'HTTP/1.1 403 Forbidden' request:\n\nBEGIN:VCALENDAR^M\nVERSION:2.0^M\nPRODID:-//Apple Inc.//iCal 3.0//EN^M\nCALSCALE:GREGORIAN^M\nBEGIN:VTIMEZONE^M\nTZID:US/Eastern^M\nBEGIN:DAYLIGHT^M\nTZOFFSETFROM:-0500^M\nTZOFFSETTO:-0400^M\nDTSTART:20070311T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU^M\nTZNAME:EDT^M\nEND:DAYLIGHT^M\nBEGIN:STANDARD^M\nTZOFFSETFROM:-0400^M\nTZOFFSETTO:-0500^M\nDTSTART:20071104T020000^M\nRRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU^M\nTZNAME:EST^M\nEND:STANDARD^M\nEND:VTIMEZONE^M\nBEGIN:VEVENT^M\nSEQUENCE:5^M\nDTSTART;TZID=US/Eastern:20090117T094500^M\nDTSTAMP:20081227T143043Z^M\nSUMMARY:blah blah^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT:urn:uuid^M\n :XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nATTENDEE;CN="First Last";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED:mailto:user@d^M\n omain.tld^M\nEXDATE;TZID=US/Eastern:20110319T094500^M\nDTEND;TZID=US/Eastern:20090117T183000^M\nRRULE:FREQ=WEEKLY;INTERVAL=1^M\nTRANSP:OPAQUE^M\nUID:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX^M\nORGANIZER;CN="First Last":mailto:[email protected]^M\nX-WR-ITIPSTATUSML:UNCLEAN^M\nCREATED:20110317T191348Z^M\nEND:VEVENT^M\nEND:VCALENDAR^M\n\n\n... response:\nHTTP/1.1 403 Forbidden^M\nDate: Thu, 17 Mar 2011 19:14:30 GMT^M\nDav: 1, access-control, calendar-access, calendar-schedule, calendar-auto-schedule, calendar-availability, inbox-availability, calendar-proxy, calendarserver-private-events, calendarserver-private-comments, calendarserver-principal-property-search^M\nContent-Type: text/xml^M\nContent-Length: 134^M\nServer: Twisted/8.2.0 TwistedWeb/8.2.0 TwistedCalDAV/2.5 (iCal Server v12.56.21)^M\n^M\n<?xml version='1.0' encoding='UTF-8'?><error xmlns='DAV:'>^M\n <valid-attendee-change xmlns='urn:ietf:params:xml:ns:caldav'/>^M\n</error> One thing I have noticed, and I'm not sure if this has any real effect is that in many of these pre-Snow Leopard Server migration events, the ORGANIZER is specified like the following: ORGANIZER;CN=First Last:mailto:[email protected] But newer ones are more like one of the two following: ORGANIZER;CN=First Last;[email protected];SCHEDULE-STATUS=1 ORGANIZER;CN=First Last;[email protected]:urn:uuid:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX iCal_Server_Admin_v10.6.pdf notes that the ".db.sqlite" files are completely disposable, they're merely a performance cache and are re-built on the fly, so are safe to delete. I did delete the one for the organizer's calendars and it took longer to process the attempted event delete while it rebuilt the database, but still errored out in the end. FWIW the error is thrown by this code: https://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/scheduling/implicit.py Any further suggestions? I see lots of questions about this in my Google searches, but not solutions and this is a widespread problem on our iCal Server. Now, we mostly try to get users to ignore them (hence the amount of time this question has been open), but every now and then I dig in deeper trying to find the culprit and/or solution.

    Read the article

  • How Will Mac OS X Snow Leopard Upgrade Work?

    - by Blaenk
    I am relatively new to Mac OS X. I got my MacBook in January, and I have never experienced a new version of the operating system. I am wondering if I should simply upgrade my install to Snow Leopard. I come from Windows where it is advised to do a complete reformat. I would rather not do this, however, and I have a feeling that due to Mac OS X' POSIX based nature, it might actually not be all that bad if I upgrade. I guess if things end up screwing up I can simply go ahead and reformat, but I am wondering what it is like to upgrade systems running Mac OS X. I wouldn't want my Snow Leopard installation to be somehow deficient due to certain inconsistencies within the system.

    Read the article

  • A strategy to troubleshoot/ fix application crashes in Windows?

    - by Manav Sharma
    All, Over a period of time I have observed that fixing issues related to application crash is a discipline in itself. Some people have this nice way of attacking such problems. Ranging from Viewing the 'Event Viewer' to running Static/ Dynamic memory analysis tools to some of their 'personal favorites', these people have developed this art. Can we share articles/ links/ personal approaches that we use to understand/ troubleshoot/ fix such issues? Thanks

    Read the article

  • Whats the best way to stop this app crash when buttons rapidly pressed iphone obj-c

    - by dubbeat
    Hi, I'm not entirely sure why this crash is happening and I'd like to get advice on the best way to deal with it. My app has 3 buttons. Each button requests a different XML file from a server which is used to populate a table view. If I rapidly press the buttons in sequence , button 1 button 2 button3 button 1 button 2 button3 button 1 button 2 button3 the application quits. What could be causing this. Would id be in the NSURLRequest side of things or the table view population side? How would you suggest I stop this behaviour? I was going to just set a boolean "isRequesting" to true when a button is pressed and set it to false when the table view is finished populating. If any button is pressed while isRequesting is True they do nothing. Does that sound wise or is there a better way? Thanks, dub

    Read the article

  • why does this code crash?

    - by ashish yadav
    why does this code crash? is using strcat illegal on character pointers? #include <stdio.h> #include <string.h> int main() { char *s1 = "Hello, "; char *s2 = "world!"; char *s3 = strcat(s1, s2); printf("%s",s3); return 0; } please give a proper way with referring to both array and pointers.

    Read the article

  • MS-Access 2007 Runtime SendObject Crash

    - by ccraiff
    I have programmed an Access Database program using Access 2007. I have a button that points to the event: DoCmd.SendObject acSendReport to have it email a PDF report (acFormatPDF). Everything works fine in the normal Access 2007 program, but when a user opens the program with Access 2007 Runtime, when clicking on this button it goes through the normal steps (notifying Outlook, waiting for Allow/Deny clearance), and then after you click Allow, the program crashes with a Runtime Error. Does anybody know what is going on here? Is this a normal error with Access Runtime? I have tried other file formats (RTF and XLS) instead of PDF, but it seems to be the SendObject command that is crashing the Runtime Environment? Clarification: Access Runtime does not output an error code upon this crash. Just a window stating a "runtime error has occurred".

    Read the article

  • UINavigationController crash because of pushing and poping UIViewControllers

    - by Wayne Lo
    My question is related to my discovery of a reason for UINavigationController to crash. So I will tell you about the discovery first. Please bare with me. The issue: I have a UINavigationController as as subview of UIWindow, a rootViewController class and a custom MyViewController class. The following steps will get a Exc_Bad_Access, 100% reproducible.: [myNaviationController pushViewController:myViewController_1stInstance animated:YES]; [myNaviationController pushViewController:myViewController_2ndInstance animated:YES]; Hit the left back tapBarItem twice (pop out two of the myViewController instances) to show the rootViewController. After a painful 1/2 day of try and error, I finally figure out the answer but also raise a question. The Solutio: I declared many objects in the .m file as a lazy way of declaring private variables to avoid cluttering the .h file. For instance, #impoart "MyViewController.h" NSMutableString*variable1; @implement ... -(id)init { ... varialbe1=[[NSMutableString alloc] init]; ... } -(void)dealloc { [variable1 release]; } For some reasons, the iphone OS may loose track of these "lazy private" variables memory allocation when myViewController_1stInstance's view is unloaded (but still in the navigation controller's stacks) after loading the view of myViewController_2ndInstance. The first time to tap the back tapBarItem is ok since myViewController_2ndInstance'view is still loaded. But the 2nd tap on the back tapBarItem gave me hell because it tried to dealloc the 2nd instance. Executing [variable release] resulted in Exc_Bad_Access because it pointed randomly (loose pointer). To fix this problem is simple, declare variable1 as a @private in the .h file. Here is my Question: I have been using the "lazy private" variables for quite some time without any issues until they are involved in UINavigationController. Is this a bug in iPhone OS? Or there is a fundamental misunderstanding on my part about Objective C? Please help.

    Read the article

  • Cocoa Bindings and Application Preferences - Crash

    - by iaefai
    Using the document provided by Apple to create an application preferences window that doesn't require any extra code, I seem to have triggered a crash that cannot be traced by me. While the stuff from Apple is older, I believe I have the settings pretty much the same as shown here: When I run my application (Hcode) and go to the preferences menu item, it brings up the proper window with the defaults I specified in the bindings with the exception of the Spaces per tab is blank (no idea how to fix this). When the window is closed, the application crashes with a backtrace similar to this: (gdb) bt #0 0x00007fff800cb1d4 in objc_msgSend_vtable5 () #1 0x00007fff80447cf3 in -[NSMenu _enableItem:] () #2 0x00007fff80447ad8 in -[NSCarbonMenuImpl _carbonUpdateStatusEvent:handlerCallRef:] () #3 0x00007fff8042b3b0 in NSSLMMenuEventHandler () #4 0x00007fff80e06b57 in DispatchEventToHandlers () #5 0x00007fff80e060a6 in SendEventToEventTargetInternal () #6 0x00007fff80e23d85 in SendEventToEventTarget () #7 0x00007fff80e52e61 in SendHICommandEvent () #8 0x00007fff80e66357 in UpdateHICommandStatusWithCachedEvent () #9 0x00007fff80e02a6d in HIApplication::EventHandler () #10 0x00007fff80e06b57 in DispatchEventToHandlers () #11 0x00007fff80e060a6 in SendEventToEventTargetInternal () #12 0x00007fff80e23d85 in SendEventToEventTarget () #13 0x00007fff80e6599b in SendMenuOpening () #14 0x00007fff80e65388 in DrawTheMenu () #15 0x00007fff80e65149 in MenuChanged () #16 0x00007fff80e643d4 in TrackMenuCommon () #17 0x00007fff80e60dbe in MenuSelectCore () #18 0x00007fff80e60596 in _HandleMenuSelection2 () #19 0x00007fff802fc3b9 in _NSHandleCarbonMenuEvent () #20 0x00007fff802cfeda in _DPSNextEvent () #21 0x00007fff802cf379 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #22 0x00007fff8029505b in -[NSApplication run] () #23 0x00007fff8028dd7c in NSApplicationMain () #24 0x0000000100001cac in main (argc=1, argv=0x7fff5fbff5e0) at /Users/iaefai/Projects/Hcode/Source/main.m:13 I am at a complete loss as to what the problem is. Is there potentially a better way of doing this?

    Read the article

  • Windows 7 dsound.dll load from dll crash

    - by Jonas Byström
    I'm getting a crash when loading dsound.dll from another DLL in Windows 7. The following code crashes: #include <Windows.h> #include <mmreg.h> #include <dsound.h> #include <assert.h> HRESULT (WINAPI *pDirectSoundEnumerateA)(LPDSENUMCALLBACKA pDSEnumCallback, LPVOID pContext); HMODULE hDsound; BOOL CALLBACK DSEnum(LPGUID a, LPCSTR b, LPCSTR c, LPVOID d) { return TRUE; } void CrashTest() { HRESULT hr; hDsound = LoadLibraryA("dsound.dll"); assert(hDsound); *(void**)&pDirectSoundEnumerateA = (void*)GetProcAddress(hDsound, "DirectSoundEnumerateA"); assert(pDirectSoundEnumerateA); hr = pDirectSoundEnumerateA(DSEnum, NULL); assert(!FAILED(hr)); } BOOL APIENTRY DllMain(HANDLE hModule,DWORD ul_reason_for_call,LPVOID lpReserved) { if (ul_reason_for_call == DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(hModule); CrashTest(); } } with this error code: Unhandled exception at ... in ...: 0xC0000005: Access violation reading location 0x00000044. (it's always 0x44 for some reason). It works on Windows XP or when loading directly from the .exe (not from a separate DLL). Help!?! :)

    Read the article

  • A weird crash...

    - by Nima
    Hi, I have a piece of code that runs in debug mode in VS2008, C++. The problem is that when I am debugging the code line by line, at a very weird point of the code, it crashes and says: debug assertion faild. Expression: _BLOCK_TYPE_IS_VALID(pHead-nBlockUse) The crash point is on the first closed curly bracket (after mesh-edges[e].needsUpdate=false;) I don't understand why on a curly bracket? does that make sense to you guys? Can anybody help me understanding what is going on..? for(int e=0; e<mesh->edges.size(); e++) { if(mesh->edges[e].valid && mesh->edges[e].v[0]>=0 && mesh->edges[e].v[1]>=0 && mesh->points[mesh->edges[e].v[0]].writable && mesh->points[mesh->edges[e].v[1]].writable) { //update v_hat and its corresponding error DecEdge Current = DecEdge(e); pair<Point, float> ppf = computeVhat(e); Current.v_hat = ppf.first; Current.error = ppf.second; edgeSoup.push(Current); mesh->edges[e].needsUpdate=false; } }

    Read the article

  • What could cause these Apache crash errors ?

    - by jacobanderssen
    Hello guys. I had a server crash several days ago. I use Cacti to keep stats: at the time when the server crashed, a huge spike from Load 1 to Load 200 occurred, with over 800 processes in the run queue ( from 300 average). Upon checking /var/log/httpd I notice this: * glibc detected /usr/sbin/httpd: double free or corruption (out): 0x00002b8f3142c2f0 ** Followed by alot of these: [Sat Mar 13 19:20:20 2010] [warn] child process 3090 still did not exit, sending a SIGTERM [Sat Mar 13 19:20:20 2010] [warn] child process 3091 still did not exit, sending a SIGTERM Followed by this: ======= Backtrace: ========= /lib64/libc.so.6[0x2b8f1463c2ef] /lib64/libc.so.6(cfree+0x4b)[0x2b8f1463c73b] /usr/lib64/libapr-1.so.0(apr_pool_destroy+0x131)[0x2b8f13f98821] /usr/sbin/httpd[0x2b8f126df47e] /usr/sbin/httpd[0x2b8f126df4ab] /lib64/libpthread.so.0[0x2b8f141b87c0] /etc/httpd/modules/mod_file_cache.so[0x2b8f1cdf00fb] ======= Memory map: ======== And finally a lot of these: [Sat Mar 13 19:20:27 2010] [error] could not make child process 733 exit, attempting to continue anyway [Sat Mar 13 19:20:27 2010] [error] could not make child process 24560 exit, attempting to continue anyway [Sat Mar 13 19:20:27 2010] [error] could not make child process 31384 exit, attempting to continue anyway I am also noticing one or two lines like this: [Mon Mar 15 01:17:26 2010] [notice] child pid 20765 exit signal Segmentation fault (11) Please help me shed some light on this. Thanks !

    Read the article

  • crash when using stl vector at instead of operator[]

    - by Jamie Cook
    I have a method as follows (from a class than implements TBB task interface - not currently multithreading though) My problem is that two ways of accessing a vector are causing quite different behaviour - one works and the other causes the entire program to bomb out quite spectacularly (this is a plugin and normally a crash will be caught by the host - but this one takes out the host program as well! As I said quite spectacular) void PtBranchAndBoundIterationOriginRunner::runOrigin(int origin, int time) const // NOTE: const method { BOOST_FOREACH(int accessMode, m_props->GetAccessModes()) { // get a const reference to appropriate vector from member variable // map<int, vector<double>> m_rowTotalsByAccessMode; const vector<double>& rowTotalsForAccessMode = m_rowTotalsByAccessMode.find(accessMode)->second; if (origin != 129) continue; // Additional debug constrain: I know that the vector only has one non-zero element at index 129 m_job->Write("size: " + ToString(rowTotalsForAccessMode.size())); try { // check for early return... i.e. nothing to do for this origin if (!rowTotalsForAccessMode[origin]) continue; // <- this works if (!rowTotalsForAccessMode.at(origin)) continue; // <- this crashes } catch (...) { m_job->Write("Caught an exception"); // but its not an exception } // do some other stuff } } I hate not putting in well defined questions but at the moment my best phrasing is : "WTF?" I'm compiling this with Intel C++ 11.0.074 [IA-32] using Microsoft (R) Visual Studio Version 9.0.21022.8 and my implementation of vector has const_reference operator[](size_type _Pos) const { // subscript nonmutable sequence #if _HAS_ITERATOR_DEBUGGING if (size() <= _Pos) { _DEBUG_ERROR("vector subscript out of range"); _SCL_SECURE_OUT_OF_RANGE; } #endif /* _HAS_ITERATOR_DEBUGGING */ _SCL_SECURE_VALIDATE_RANGE(_Pos < size()); return (*(_Myfirst + _Pos)); } (Iterator debugging is off - I'm pretty sure) and const_reference at(size_type _Pos) const { // subscript nonmutable sequence with checking if (size() <= _Pos) _Xran(); return (*(begin() + _Pos)); } So the only difference I can see is that at calls begin instead of simply using _Myfirst - but how could that possibly be causing such a huge difference in behaviour?

    Read the article

  • why it makes ie6 or ie8 compatible mode crash

    - by hylin
    Anybody can tell me why those code can make ie6 or ie8 compatible mode crash? PS:I know,there is so many ways to avoid this satuation, but I just want to know why. To avoid: Change class="wrapper"--class="wrapper2" or other != "wrapper" $('wrapper').style.overflow='visible'; -- setTimeout(function(){$('wrapper').style.overflow='visible';},10); Or remove any style , js operation... <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <style>.wrapper{width:975px;margin:60px auto 0}</style> </head> <body id="wrapper" style="overflow:hidden;"> <div id="overlay" style="position:absolute;"></div> <div class="wrapper"> <input type="text" id="input1"/> <a id="btn" href="javascript:;">test</a> </div> <script type="text/javascript"> $('btn').onclick = function(){ $('overlay').style.display='none'; $('wrapper').style.overflow='visible'; $("input1").focus(); } function $(s){ return document.getElementById(s); } </script> </body> </html>

    Read the article

  • Lack of understanding crash report

    - by Alan Lai
    I have this crash report. Incident Identifier: CA9E350A-C842-4349-AAD8-E9E62E93BDD1 CrashReporter Key: 360bc129d2f79a48e291eb5ca38b24e822ed5b6b Hardware Model: xxx Process: OrientalDailyiOS [1502] Path: /var/mobile/Applications/39480A57-68FF-4C46-8445-340EFE204119/OrientalDailyiOS.app/OrientalDailyiOS Identifier: OrientalDailyiOS Version: ??? (???) Code Type: ARM (Native) Parent Process: launchd [1] Date/Time: 2012-10-14 15:49:10.884 -0700 OS Version: iOS 6.0 (10A403) Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Crashed Thread: 0 Last Exception Backtrace: 0 CoreFoundation 0x37a0a29e __exceptionPreprocess + 158 1 libobjc.A.dylib 0x34e3197a objc_exception_throw + 26 2 CoreFoundation 0x37955b70 -[__NSArrayM objectAtIndex:] + 160 3 OrientalDailyiOS 0x00064fdc -[Main_NewsDetail viewDidLoad] (Main_NewsDetail.m:43) 4 UIKit 0x386cb590 -[UIViewController loadViewIfRequired] + 360 5 UIKit 0x38757336 -[UIViewController shouldAutorotate] + 22 6 UIKit 0x38798cd4 -[UIWindowController transition:fromViewController:toViewController:target:didEndSelector:] + 1540 7 UIKit 0x38797fca -[UIViewController presentViewController:withTransition:completion:] + 3390 8 UIKit 0x388ba252 -[UIViewController presentModalViewController:animated:] + 26 9 Foundation 0x34364a6a __NSFireDelayedPerform + 446 10 CoreFoundation 0x379df5da __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 10 11 CoreFoundation 0x379df28c __CFRunLoopDoTimer + 268 12 CoreFoundation 0x379ddefc __CFRunLoopRun + 1228 13 CoreFoundation 0x37950eb8 0x37948000 + 36536 14 CoreFoundation 0x37950d44 CFRunLoopRunInMode + 100 15 GraphicsServices 0x373e32e6 GSEventRunModal + 70 16 UIKit 0x387002fc 0x386a9000 + 357116 17 OrientalDailyiOS 0x0005fac2 main (main.m:16) 18 OrientalDailyiOS 0x0005fa84 0x5e000 + 6788 However, I couldn't know where is error, I play around with my apps but show no error. I also tried iOS 6 with iPad, no problem. what apple feedback was We found that your app crashed on iPad running iOS 6, which is not in compliance with the App Store Review Guidelines. Your app crashed on both Wi-Fi and cellular networks when we: 1. Launch the app. 2. Tap any item on main page. 3. App crashes.

    Read the article

  • How to debug nondeterministic access violation crash?

    - by Special Touch
    Our C#/COM/C++ application is crashing and I need help debugging it. Running with gflags enabled and WinDbg attached, we determined the crashes are caused by an access violation, but we haven't been able to narrow it down any more than that. We are not seeing the issue on all machines; there are a couple of machines that seem to reproduce the issue frequently but not deterministically. We have observed the application crash from simply switching away from the application (say, Alt-Tab) and then back. Output from WinDbg is below. We have been trying to systematically comment out areas of code that could be causing the problem, but we haven't had much success yet. Any suggestions on what debugging steps or tools we should try? !analyze -v EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 1a584ff2 (+0x1a584ff1) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 1a584ff2 Attempt to read from address 1a584ff2 PROCESS_NAME: ProcessFiles.exe ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 1a584ff2 READ_ADDRESS: 1a584ff2 FOLLOWUP_IP: Ed20+1a584ff1 1a584ff2 ?? ??? NTGLOBALFLAG: 2000000 APPLICATION_VERIFIER_FLAGS: 0 IP_MODULE_UNLOADED: Ed20+1a584ff1 1a584ff2 ?? ??? MANAGED_STACK: (TransitionMU) 0EC6F6F4 7B1D8CCE System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(Int32, Int32, Int32)+0x24e 0EC6F790 7B1D8937 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)+0x177 0EC6F7E4 7B1D8781 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)+0x61 0EC6F814 7B195911 System_Windows_Forms_ni!System.Windows.Forms.Application.Run(System.Windows.Forms.Form)+0x31 0EC6F828 0969D97A Extract_Utilities_Forms!Extract.Utilities.Forms.VerificationForm`1[[System.__Canon, mscorlib]].A(System.Object)+0x23a 0EC6F8C0 79A00EEE mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context(System.Object)+0x72a25e 0EC6F8CC 792E019F mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)+0x6f 0EC6F8E4 797DB48A mscorlib_ni!System.Threading.ThreadHelper.ThreadStart(System.Object)+0x4a (TransitionUM) LAST_CONTROL_TRANSFER: from 7e418734 to 1a584ff2 FAULTING_THREAD: ffffffff ADDITIONAL_DEBUG_TEXT: Followup set based on attribute [ip_not_executable] from Frame:[0] on thread:[e30] BUGCHECK_STR: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_READ_WRONG_SYMBOLS_WINDOW_HOOK PRIMARY_PROBLEM_CLASS: BAD_INSTRUCTION_PTR DEFAULT_BUCKET_ID: BAD_INSTRUCTION_PTR STACK_TEXT: 7b1d8cce System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop+0xc 7b1d8937 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner+0x0 7b1d8781 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop+0x0 7b195911 System_Windows_Forms_ni!System.Windows.Forms.Application.Run+0x31 0969d97a Extract_Utilities_Forms!Extract.Utilities.Forms.VerificationForm`1[[System.__Canon, mscorlib]].A+0x23a 79a00eee mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context+0x72a25e 792e019f mscorlib_ni!System.Threading.ExecutionContext.Run+0x6f 797db48a mscorlib_ni!System.Threading.ThreadHelper.ThreadStart+0x4a STACK_COMMAND: .ecxr ; ~~[e30] ; .frame 0 ; ** Pseudo Context ** ; kb FAILED_INSTRUCTION_ADDRESS: Ed20+1a584ff1 1a584ff2 ?? ??? SYMBOL_NAME: Ed20 FOLLOWUP_NAME: MachineOwner MODULE_NAME: Ed20 IMAGE_NAME: Ed20 DEBUG_FLR_IMAGE_TIMESTAMP: 0 FAILURE_BUCKET_ID: BAD_INSTRUCTION_PTR_c0000005_Ed20!Unloaded BUCKET_ID: APPLICATION_FAULT_BAD_INSTRUCTION_PTR_INVALID_POINTER_READ_WRONG_SYMBOLS_WINDOW_HOOK_BAD_IP_Ed20 Followup: MachineOwner

    Read the article

  • Casting between variant and bstr_t causing inconsisten crash in Windows 2008

    - by user58470
    We have a C# application, calling a simple C++ wrapper class, that then calls an existing C++ DLL. The C++ code is all VC++ 6.0. We are getting inconsistent behaviour, but the crash, when it happens, always happens within the C++ wrapper DLL, and always in the same spot (have confirmed using painful logging statements). It never happens on any environment except on Windows 2008, so we suspect some bad-but-not-fatal memory trashing is going on that somehow Windows 2008 is being more mindful of. Here's the relevant code, if anyone has any ideas on why this might be crashing it would be much appreciated. We've been tearing our hair out for a few days and project timelines are slipping all for the want of being able to return a simple string back to C#... I've been told we've tried setting the VARIANT vresult using VariantInit, and clearing it when we are done with VariantClear, but that didn't help. // JobMgrDll.cpp : Defines the entry point for the DLL application. // #include "stdafx.h" #include "JobMgrDll.h" #include "jobmgr.h" CString gcontext; CString guser; CString ghost; CString glog; JOBMGRDLL_API int nJobMgrDll=0; extern "C" JOBMGRDLL_API char* perform_billcalc(char* cmd, char* context, char* user,char* host,BSTR* log,int* loglen) { char* result = new char[1000]; memset(result,0,999); result[999] = '\0'; bstr_t bt_command = cmd; UUID uuid = __uuidof(BRLib::Rules); VARIANT vresult; char *p_rv; gcontext = context; guser = user; ghost = host; write_log("execute_job"); p_rv = execute_job(uuid, "none", bt_command, &vresult); write_log("DONE execute_job"); CString message; write_log ("Intializing bstr_t with variant"); // WE ALWAYS GET HERE bstr_t res(vresult); //message.Format("%s result = %s",p_rv,res); //write_log(message); write_log("copying Result"); // WE DON'T ALWAYS GET HERE, BUT SOMETIMES WE DO strcpy(result,(char*)res); write_log(CString(result)); *loglen = glog.GetLength(); *log = glog.AllocSysString(); return result; } Again, any ideas much, much appreciated.

    Read the article

  • iPhone crash on CoreData save

    - by davetron5000
    This is a different situation than this question, as the solution provided doesn't work and the stack is different. Periodical crash when I save data using coredata. The stack trace isn't 100% clear on where this is happening, but I'm certain it's this routine that's being called. It's either the save: in this method or the one following. Code: -(void)saveWine { if ([self validInfo]) { Wine *wine = (Wine *)wineToEdit; if (wine == nil) { wine = (Wine *)[NSEntityDescription insertNewObjectForEntityForName:@"Wine" inManagedObjectContext:self.managedObjectContext]; } wine.uuid = [Utils createUUID]; wine.name = self.wineNameField.text; wine.vineyard = self.vineyardField.text; wine.vintage = [[self numberFormatter] numberFromString:self.vintageField.text]; wine.timeStamp = [NSDate date]; wine.rating = [NSNumber numberWithInt:self.ratingControl.selectedSegmentIndex]; wine.partnerRating = [NSNumber numberWithInt:self.partnerRatingControl.selectedSegmentIndex]; wine.varietal = self.currentVarietal; wine.tastingNotes = self.currentTastingNotes; wine.dateTasted = self.currentDateTasted; wine.tastingLocation = [[ReferenceDataAccessor defaultReferenceDataAccessor] addEntityForType:TASTING_LOCATION withName:self.currentWhereTasted]; id type = [[ReferenceDataAccessor defaultReferenceDataAccessor] entityForType:WINE_TYPE withOrdinal:self.typeControl.selectedSegmentIndex]; wine.type = type; NSError *error; NSLog(@"Saving %@",wine); if (![self.managedObjectContext save:&error]) { [Utils showAlertMessage:@"There was a problem saving your wine; try restarting the app" withTitle:@"Problem saving"]; NSLog(@"Error while saving new wine %@, %@", error, [error userInfo]); } } else { NSLog(@"ERROR - someone is calling saveWine with invalid info!!"); } } Code for addEntityForType:withName:: -(id)addEntityForType:(NSString *)type withName:(NSString *)name { if ([Utils isStringBlank:name]) { return nil; } id existing = [[ReferenceDataAccessor defaultReferenceDataAccessor] entityForType:type withName:name]; if (existing != nil) { NSLog(@"%@ with name %@ already exists",type,name); return existing; } NSManagedObject *newEntity = [NSEntityDescription insertNewObjectForEntityForName:type inManagedObjectContext:self.managedObjectContext]; [newEntity setValue:name forKey:@"name"]; NSError *error; if (![self.managedObjectContext save:&error]) { [Utils showAlertMessage:[NSString stringWithFormat:@"There was a problem saving a %@",type] withTitle:@"Database Probem"]; [Utils logErrorFully:error forOperation:[NSString stringWithFormat:@"saving new %@",type ]]; } return newEntity; } Stack trace: Thread 0 Crashed: 0 libSystem.B.dylib 0x311de2d4 __kill + 8 1 libSystem.B.dylib 0x311de2c4 kill + 4 2 libSystem.B.dylib 0x311de2b6 raise + 10 3 libSystem.B.dylib 0x311f2d72 abort + 50 4 libstdc++.6.dylib 0x301dea20 __gnu_cxx::__verbose_terminate_handler() + 376 5 libobjc.A.dylib 0x319a2594 _objc_terminate + 104 6 libstdc++.6.dylib 0x301dcdf2 __cxxabiv1::__terminate(void (*)()) + 46 7 libstdc++.6.dylib 0x301dce46 std::terminate() + 10 8 libstdc++.6.dylib 0x301dcf16 __cxa_throw + 78 9 libobjc.A.dylib 0x319a14c4 objc_exception_throw + 64 10 CoreData 0x3526e83e -[NSManagedObjectContext save:] + 1098 11 Wine Brain 0x0000651e 0x1000 + 21790 12 Wine Brain 0x0000525c 0x1000 + 16988 13 Wine Brain 0x00004894 0x1000 + 14484 14 Wine Brain 0x00008716 0x1000 + 30486 15 CoreFoundation 0x31477fe6 -[NSObject(NSObject) performSelector:withObject:withObject:] + 18 16 UIKit 0x338c14a6 -[UIApplication sendAction:to:from:forEvent:] + 78 17 UIKit 0x3395c7ae -[UIBarButtonItem(UIInternal) _sendAction:withEvent:] + 86 18 CoreFoundation 0x31477fe6 -[NSObject(NSObject) performSelector:withObject:withObject:] + 18 19 UIKit 0x338c14a6 -[UIApplication sendAction:to:from:forEvent:] + 78 20 UIKit 0x338c1446 -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 26 21 UIKit 0x338c1418 -[UIControl sendAction:to:forEvent:] + 32 22 UIKit 0x338c116a -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 350 23 UIKit 0x338c19c8 -[UIControl touchesEnded:withEvent:] + 336 24 UIKit 0x338b734e -[UIWindow _sendTouchesForEvent:] + 362 25 UIKit 0x338b6cc8 -[UIWindow sendEvent:] + 256 26 UIKit 0x338a1fc0 -[UIApplication sendEvent:] + 292 27 UIKit 0x338a1900 _UIApplicationHandleEvent + 5084 28 GraphicsServices 0x35d66efc PurpleEventCallback + 660 29 CoreFoundation 0x314656f8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 20 30 CoreFoundation 0x314656bc __CFRunLoopDoSource1 + 160 31 CoreFoundation 0x31457f76 __CFRunLoopRun + 514 32 CoreFoundation 0x31457c80 CFRunLoopRunSpecific + 224 33 CoreFoundation 0x31457b88 CFRunLoopRunInMode + 52 34 GraphicsServices 0x35d664a4 GSEventRunModal + 108 35 GraphicsServices 0x35d66550 GSEventRun + 56 36 UIKit 0x338d5322 -[UIApplication _run] + 406 37 UIKit 0x338d2e8c UIApplicationMain + 664 38 Wine Brain 0x000021ba 0x1000 + 4538 39 Wine Brain 0x00002184 0x1000 + 4484 I have no idea why my app's memory locations aren't being symbolocated, but the code paths lead to only two manavedObjectContext save: calls. The time this happend, addEntityForType was called all the way through, creating a new object for the "whereTasted" entity, before the final save: on the entire wine object. When I go through the same procedure again, it works fine. This leads me to believe it's something to do with the app having been run for a while when adding a new location, but I'm not sure. Any thoughts on how I can debug this and get more info the next time this happens?

    Read the article

  • Box2d Cocos2d circle crash on contact with ground

    - by Oliver Cooper
    this is my first question here so sorry if I do something wrong or this is too long. I have been reading this tutorial by Ray Wenderlich, I have modified it so it is flatter and gradually goes down hill. Basically I have a ball roll down a bumpy hill, but at the moment the ball only drops from about 100 pixels above. When ever the touch the app crashes (the app is a Mac Cocos2d Box2d app). The ball code is this: CGSize winSize = [CCDirector sharedDirector].winSize; self.oeva = [CCSprite spriteWithTexture:[[CCTextureCache sharedTextureCache] addImage:@"Ball.png"]rect:CGRectMake(0, 0, 64, 64)]; _oeva.position = CGPointMake(68, winSize.height/2); [self addChild:_oeva z:1]; b2BodyDef oevaBodyDef; oevaBodyDef.type = b2_dynamicBody; oevaBodyDef.position.Set(68/PTM_RATIO, (winSize.height/2)/PTM_RATIO); // oevaBodyDef.userData = _oeva; _oevaBody = world->CreateBody(&oevaBodyDef); b2BodyDef bodyDef; bodyDef.type = b2_dynamicBody; bodyDef.position.Set(60/PTM_RATIO, 400/PTM_RATIO); bodyDef.userData = _oeva; b2Body *body = world->CreateBody(&bodyDef); // Define another box shape for our dynamic body. b2CircleShape dynamicBox; dynamicBox.m_radius = 70/PTM_RATIO;//These are mid points for our 1m box // Define the dynamic body fixture. b2FixtureDef fixtureDef; fixtureDef.shape = &dynamicBox; fixtureDef.density = 1.0f; fixtureDef.friction = 0.3f; body->CreateFixture(&fixtureDef); That works fine. This is the terrain code, this also works fine: -(void)generateTerrainWithWorld: (b2World *) inputWorld: (int) hillSize;{ b2BodyDef bd; bd.position.Set(0, 0); body = inputWorld->CreateBody(&bd); b2PolygonShape shape; b2FixtureDef fixtureDef; currentSlope = 0; CGSize winSize = [CCDirector sharedDirector].winSize; float xf = 0; float yf = (arc4random() % 10)+winSize.height/3; int x = 200; for(int i = 0; i < maxHillPoints; ++i) { hillPoints[i] = CGPointMake(xf, yf); xf = xf+ (arc4random() % x/2)+x/2; yf = ((arc4random() % 30)+winSize.height/3)-currentSlope; currentSlope +=10; } int hSegments; for (int i=0; i<maxHillPoints-1; i++) { CGPoint p0 = hillPoints[i-1]; CGPoint p1 = hillPoints[i]; hSegments = floorf((p1.x-p0.x)/cosineSegmentWidth); float dx = (p1.x - p0.x) / hSegments; float da = M_PI / hSegments; float ymid = (p0.y + p1.y) / 2; float ampl = (p0.y - p1.y) / 2; CGPoint pt0, pt1; pt0 = p0; for (int j = 0; j < hSegments+1; ++j) { pt1.x = p0.x + j*dx; pt1.y = ymid + ampl * cosf(da*j); fullHillPoints[fullHillPointsCount++] = pt1; pt0 = pt1; } } b2Vec2 p1v, p2v; for (int i=0; i<fullHillPointsCount-1; i++) { p1v = b2Vec2(fullHillPoints[i].x/PTM_RATIO,fullHillPoints[i].y/PTM_RATIO); p2v = b2Vec2(fullHillPoints[i+1].x/PTM_RATIO,fullHillPoints[i+1].y/PTM_RATIO); shape.SetAsEdge(p1v, p2v); body->CreateFixture(&shape, 0); } } However when ever the two collide the app crashes. The crash error is: Thread 6 CVDisplayLink: Program received signal: "SIGABRT" The error occurs on line 96 of b2ContactSolver.cpp: b2Assert(kNormal > b2_epsilon); The error log is: Assertion failed: (kNormal 1.19209290e-7F), function b2ContactSolver, file /Users/coooli01/Documents/Xcode Projects/Cocos2d/Hill Slide/Hill Slide/libs/Box2D/Dynamics/Contacts/b2ContactSolver.cpp, line 96. Sorry if I rambled on for too long, i've been stuck on this for ages.

    Read the article

< Previous Page | 8 9 10 11 12 13 14 15 16 17 18 19  | Next Page >