[TIMOB-20271] Frequent crash in Javascript Debugger when removing a breakpoint...
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Closed |
| Resolution | Cannot Reproduce |
| Resolution Date | 2016-07-28T19:18:38.000+0000 |
| Affected Version/s | Release 5.1.2 |
| Fix Version/s | n/a |
| Components | n/a |
| Labels | n/a |
| Reporter | Henry David Spells III |
| Assignee | Angel Petkov |
| Created | 2016-01-24T04:50:59.000+0000 |
| Updated | 2016-07-28T19:18:38.000+0000 |
Description
Process: Wazkal Mobile [83428]
Path: /Users/USER/Library/Developer/CoreSimulator/Devices/2E63D703-3377-46B4-B500-81CCFB2ED2B4/data/Containers/Bundle/Application/35A47306-2167-4E5D-B247-DD6A087F3478/Wazkal Mobile.app/Wazkal Mobile
Identifier: Wazkal Mobile
Version: 1.0 (1.0)
Code Type: X86-64 (Native)
Parent Process: launchd_sim [83356]
Responsible: Wazkal Mobile [83428]
User ID: 501
Date/Time: 2016-01-23 22:32:29.034 -0600
OS Version: Mac OS X 10.11.2 (15C50)
Report Version: 11
Anonymous UUID: C7744C05-FFEB-DA7E-85B0-7833DF56015D
Full Crash log can be found [here](https://gist.github.com/AngelkPetkov/95f0bf1a37ad4162a24a)
Attachments
| File | Date | Size |
|---|---|---|
| step1.png | 2016-01-24T18:49:49.000+0000 | 216711 |
| step2.png | 2016-01-24T18:49:53.000+0000 | 184242 |
| trunk.zip | 2016-01-24T06:26:39.000+0000 | 5973775 |
Hello, Please provide a sample code or step to reproduce about the issue that you are having. Try to be more descriptive as possible. In the meantime you can look through some of our previous community issues. 1. [execute javascript at breakpoint](https://archive.appcelerator.com/question/148070/how-to-execute-javascript-at-breakpoint). 2. [fix strange javascript behaviour](https://archive.appcelerator.com/question/122924/how-to-fix-strange-javascript-behaviour-and-crashes-on-ios). 3. [Alloy Javascript Interactive Debugger](https://archive.appcelerator.com/question/148847/alloy-javascript-interactive-debugger). Thanks.
I am not stopped in the debugger at the time of a crash. I just remove the breakpoint in the breakpoints window and it crashes almost every time. How much code do you need? Do you want all the code in the project? It's a new project with only a few files.
Yes, The full code and a step by step guidance to reproduce the issue. Did you check the debugging and breakpoint settings in your studio?
In Preferences > Studio > JavaScript Debug all the checkboxes are on except "Suspend at start". Are there any other settings I should look at? Also, my main project (BoxCommand which is shipping on iTunes, Google Play, Amazon App Store) I am not having any problem with breakpoints. In my new project that I just started on Friday, breakpoints don't seem to work at all. If the set a breakpoint it doesn't stop on the breakpoint. Then when I remove the breakpoint the debugger crashes in "TI::Debugger::removeBreakpoint(unsigned long) + 264" (see crashlog for full traceback). This is not my app crashing, this is the Titanium Debugger Crashing. I will upload a copy of my project in a few minutes.
Here is the project. I just started it on Friday. The JS Debugger has been useless. It is possible that it is a project setting since my other projects seem to work?
In Preferences > Studio > JavaScript Debug default config is unchecked suspend on exceptions. Try doing that. Also What the configuration look like in Preferences > Run/Debug. I am working with your project.
Unchecking "suspend on exceptions" had no effect (i.e. the debugger does not stop on breakpoints and the debugger itself crashes when I remove the breakpoint). In Preferences > Run Debug there are 9 sections. Do you want a screenshot of each on or is there one or more that you think will make a difference. I'm pretty sure that they are set to default. I just reinstalled my OS and the Studio within the past month.
Steps to reproduce crashing bug:
Make sure Breakpoints tab is open and debug perspective is visible (not sure if this is necessary but at least this is what I'm doing). See step1.png
Click on a line in a .js file in an edit window
Hit Cmd-Shift-B (Note the breakpoint has been added to the Breakpoints tab) See step2.png
Debug the application in an iOS simulator
Once the app is running. Go to the Breakpoints window and select the breakpoint with the mouse. See step2.png
Hit the delete key below the F13 key on the keyboard (i.e. not the backspace but the delete)
Results: The break point is removed but the Ti Debugger crashes and leaves a crashlog like the one in the description above Expected Results: The break point is removed, the Ti Debugger continues to run without crashing and the running application does not quit Also the debugger should suspend the application at the breakpointScreenshots of Breakpoints tab and surrounding perspective tabs
Were my bug steps helpful? Do you need any more environmental information from me? If you have a work around I would greatly appreciate it. It is much harder to debug a project someone is paying me for without a debugger. (Or at least I hope I get paid).
Sometimes I get this error when I launch the simulator to "Debug" 'Model Proxy installed notification job' has encountered a problem. An internal error occurred during: 'Model Proxy installed notification job". An internal error occurred during: "Model Proxy installed notification job". java.lang.NullPointerException
Having the same problem. In general the debugger crashes very often when evaluating expressions. Sometimes it even crashes if you forget the mouse over some variable in the code. This is very annoying and increases time for fixing bugs several times.
Hi can you indicate if this is platform specific? if you know if earlier versions of Titanium face this same issue? or only the latest release?
I've been developing on Appcelerator for since August 2013. For at least the a year and half now the Ti Debugger has been freezing, throwing errors, crashing, etc... I've been posting about this for a long time but I really didn't know where to find the crash logs until recently. I run on Mac OS X except for the times that I've tried to build for Windows phone. My guess is that it's specific to Mac OS X but I can't prove that. I'm including a stack trace of a crash while I was debugging the same project in a genymotion emulator tonight. It seems to be crashing while releasing one of the floating window controllers. It's not clear to me which floating window is causing the problem so I can't say for sure that it has to do with either the expression variables pane or the breakpoints pane but it does make it clear that there is a crash while debugging on android also. I hope my information helps a little bit. Process: AppceleratorStudio [15880] Path: /Applications/Appcelerator Studio/AppceleratorStudio.app/Contents/MacOS/AppceleratorStudio Identifier: com.appcelerator.appcelerator-studio Version: 4.4.0 (4.4.0.201511241829) Code Type: X86-64 (Native) Parent Process: ??? [1] Responsible: AppceleratorStudio [15880] User ID: 501 Date/Time: 2016-02-07 16:30:57.578 -0600 OS Version: Mac OS X 10.11.3 (15D21) Report Version: 11 Anonymous UUID: C7744C05-FFEB-DA7E-85B0-7833DF56015D Time Awake Since Boot: 440000 seconds System Integrity Protection: enabled Crashed Thread: 15 Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000078 Exception Note: EXC_CORPSE_NOTIFY VM Regions Near 0x78: --> __TEXT 0000000100000000-0000000100004000 [ 16K] r-x/rwx SM=COW /Applications/Appcelerator Studio/AppceleratorStudio.app/Contents/MacOS/AppceleratorStudio Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3fee43 Monitor::ILock(Thread*) + 251 5 libjvm.dylib 0x000000010a3feec1 Monitor::lock_without_safepoint_check() + 39 6 libjvm.dylib 0x000000010a4755ab SafepointSynchronize::block(JavaThread*) + 341 7 libjvm.dylib 0x000000010a4f7219 JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*) + 193 8 libjvm.dylib 0x000000010a1854f3 ThreadStateTransition::trans_from_native(JavaThreadState) + 119 9 libjvm.dylib 0x000000010a300db8 jni_ExceptionOccurred + 48 10 libswt-cocoa-4430.jnilib 0x00000001171b8cf6 callback + 676 11 libswt-cocoa-4430.jnilib 0x000000011719e525 fn3_6 + 90 12 com.apple.AppKit 0x00007fff8fa98b55 -[NSWindow trackEventsMatchingMask:timeout:mode:handler:] + 237 13 com.apple.AppKit 0x00007fff8fb4180e -[NSTableView mouseDown:] + 4839 14 com.apple.AppKit 0x00007fff8fb402ee -[NSOutlineView mouseDown:] + 74 15 libswt-pi-cocoa-4430.jnilib 0x00000001171f3ac0 Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSendSuper__Lorg_eclipse_swt_internal_cocoa_objc_1super_2JJ + 97 16 ??? 0x000000010b14d98b 0 + 4480883083 17 ??? 0x000000010b4ac488 0 + 4484416648 Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff86245ff6 kevent_qos + 10 1 libdispatch.dylib 0x00007fff8bc03099 _dispatch_mgr_invoke + 216 2 libdispatch.dylib 0x00007fff8bc02d01 _dispatch_mgr_thread + 52 Thread 2: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 3: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 4: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 5: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 6: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 7: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 8: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 9: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 10: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 11: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 12: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 13: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 14: 0 libsystem_kernel.dylib 0x00007fff86244eb2 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff90479150 _pthread_cond_wait + 767 2 libjvm.dylib 0x000000010a41e763 os::PlatformEvent::park() + 173 3 libjvm.dylib 0x000000010a3fe85e ParkCommon(ParkEvent*, long long) + 42 4 libjvm.dylib 0x000000010a3ff050 Monitor::IWait(Thread*, long long) + 160 5 libjvm.dylib 0x000000010a3ff2ad Monitor::wait(bool, long, bool) + 375 6 libjvm.dylib 0x000000010a26d3f6 GCTaskManager::get_task(unsigned int) + 56 7 libjvm.dylib 0x000000010a26e2eb GCTaskThread::run() + 349 8 libjvm.dylib 0x000000010a422b92 java_start(Thread*) + 294 9 libsystem_pthread.dylib 0x00007fff90478c13 _pthread_body + 131 10 libsystem_pthread.dylib 0x00007fff90478b90 _pthread_start + 168 11 libsystem_pthread.dylib 0x00007fff90476375 thread_start + 13 Thread 15 Crashed: 0 libsystem_kernel.dylib 0x00007fff86245002 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff9047a5c5 pthread_kill + 90 2 libsystem_c.dylib 0x00007fff965136e7 abort + 129 3 libjvm.dylib 0x000000010a42253f os::abort(bool) + 25 4 libjvm.dylib 0x000000010a52e6d4 VMError::report_and_die() + 2308 5 libjvm.dylib 0x000000010a423ef9 JVM_handle_bsd_signal + 1083 6 libsystem_platform.dylib 0x00007fff893a6eaa _sigtramp + 26 7 ??? 000000000000000000 0 + 0 8 libswt-cocoa-4430.jnilib 0x000000011719725e fn0_2 + 39 9 com.apple.AppKit 0x00007fff8f975e0c -[NSWindow orderWindow:relativeTo:] + 118 10 com.apple.AppKit 0x00007fff8fadf05e __18-[NSWindow _close]_block_invoke + 491 11 com.apple.AppKit 0x00007fff8fadee2d -[NSWindow _close] + 374 12 com.apple.FinderKit 0x00007fff8b5c654b -[FI_TFloatingInputWindowController dealloc] + 59 13 libobjc.A.dylib 0x00007fff9ba522f4 objc_object::sidetable_release(bool) + 242 14 com.apple.AppKit 0x00007fff8f9b3cce -[NSWindowController release] + 154 15 com.apple.FinderKit 0x00007fff8b5c6dea TRef
This is worse now I updated to the latest SDK 5.2.0.GA this week. I switched my project (Box Command) to 5.2.0.GA and hit the debug button and it crashed the TIDebugger. If switch to "Run" it does not crash with the new sdk (i.e. my app seems to run fine). Here is a crash log Process: BoxCommand [53763] Path: /Users/USER/Library/Developer/CoreSimulator/Devices/2E63D703-3377-46B4-B500-81CCFB2ED2B4/data/Containers/Bundle/Application/766A018B-AFC9-455A-99CF-84FBDB1947CE/BoxCommand.app/BoxCommand Identifier: BoxCommand Version: 3.5.5 (3.5.5) Code Type: X86-64 (Native) Parent Process: launchd_sim [15878] Responsible: BoxCommand [53763] User ID: 501 Date/Time: 2016-03-11 02:06:33.462 -0600 OS Version: Mac OS X 10.11.3 (15D21) Report Version: 11 Anonymous UUID: C7744C05-FFEB-DA7E-85B0-7833DF56015D Time Awake Since Boot: 380000 seconds System Integrity Protection: enabled Crashed Thread: 8 KrollContext
[~dspells] Hi, could you please try and re-produce the crash using the newest SDK which can be found [here](http://builds.appcelerator.com.s3.amazonaws.com/index.html#master) , also enable main thread
. After updating the SDK and enabling main thread the issue shouldn't persist. If following these steps doesn't eliminate the issue, we will investigate further!Your sdk link takes me to a crash log page (https://gist.github.com/AngelkPetkov/95f0bf1a37ad4162a24a)
[~dspells] Hi sorry about that, just edited my comment .Try again, thanks!
For some reason "http://builds.appcelerator.com.s3.amazonaws.com/index.html#master" takes me to a blank page I just did "appc ti sdk install --branch master" does that do the same thing? It installed 5.4.0.v20160315202153 I "debug" with the 5.4.0.v20160315202153 SDK and
Hmm that's quite peculiar that you are experiencing a full crash. I've tried to re-produce it using the steps above : add a breakpoint wait until one of them is hit and delete the lot. However I'm unable to crash studio on the newest or older SDK. Could you please tell me your environment specifications please ? Also could you create a new alloy or classic app , try the same steps again to see if the issue persists. Thank you!
I just tried adding
You should keep the run on main thread enabled while running on SDK 5.4.0 or higher. Yes that would be great thank you, could you also please give me the full specifications of your environment you are currently using ,including the version of studio. I asked a couple of colleagues on the Quality team([~htbryant] [~jlongton]) to try and re-produce your crash and they were unable too. There must be something else within your environment causing the issue not the SDK or debugger it self. As for the use of
remove that please as the debugger uses our own custom javaScript core just like the SDK. Which could be the reason your breakpoints are not being hit.I can't find the place in JIRA to add another attachment. On the atlassian site it says to use "More > Attach Files" there is no "More" item on the screen. I pushed my system report to Github since I couldn't find a way to add another attachment https://github.com/dspells/TIMOB-20271/blob/master/Mac%20Pro.spx.zip Appcelerator Studio, build: 4.5.0.201602170821 (c) Copyright 2012-2014 by Appcelerator, Inc. All rights reserved. Build: jenkins-appcelerator-rcp-master-340 (origin/master) Date: 17 February 2016, 08:22:10 Mac OS X 10.11.3 XCode 7.2.1 (7C1002) node v0.12.7 npm -g ls --depth=0 /usr/local/lib ├── appcelerator@4.2.3 ├── graceful-fs@4.1.2 ├── grunt@0.4.5 ├── grunt-cli@0.1.13 ├── mocha@2.3.4 ├── n@2.0.2 ├── nativescript@1.5.2 ├── npm@2.11.3 ├── ti-inspector@0.1.2 └── wd@0.4.0
Crash log from this [morning](https://gist.github.com/AngelkPetkov/2efd911f652619a691bf)
Henrys-Mac-Pro:~ dspells$ [appc info](https://gist.github.com/AngelkPetkov/5275de8f1520f95a25eb)
Your environment seems up to date enough that it should work, the crash you are experiencing seems to be a threading issue as you pointed out. Could you please create a new alloy or classic application on 5.4.X with
. I know i already asked that of you in a higher up comment and i do apologize. However could you do it with a brand new app , if it crashes again post that crash log. However could you please add the crashLogs to github gist or another online editor. Try this both through studio and the CLI. Make sure not to add useJsCoreFramework to the xml as that will cause problems.See here https://github.com/dspells/TIMOB-20271.git I did a brand new two tabbed alloy project. I ran the project successfully. I set a break point on line 2 of index.js. I hit the "Hello World" button and it crashed. I tried running again but breakpoints don't work now. Quitting Appcelerator Studio and restarting will then allow it break at the breakpoint and crash again. BTW: I put my projects on a separate SSD drive that is not my boot drive. Could that be why it crashes? Never mind. I put the project on my main hard drive and it still crashes. function doClick(e) { alert($.label.text); } $.index.open();
I created a new tab project , downloaded all the files from the online repository however i am still unable to re-produce the crash. A couple suggestions however , firstly update your node.js version to 4.2.4, also make sure the SDK selected in your cli is the same as the SDK being ran by studio.
I updated to node 4.2.4. I made sure that the SDK selected in the CLI was the same as the SDK selected in the project. Here is the crashed thread when I ran BoxCommand to a break point. It's the same out of range error while constructing a string object. Thread 6 Crashed:: KrollContext
Appcelerator Studio keeps asking me to update to Appcelerator CLI 5.2.1.RC. It updates but then appc -v still says 5.2.0. Also it tries to update to "Appcelerator CLI 5.2.1.RC" every time I check for updates (i.e. it seems to keep failing).
Are there any news on this issue? With the latest 5.2.1GA SDK we are not able to debug out application at all. Once a breakpoint is hit the debugger goes off. This is now becoming really serious for us.
We've not been able to re-produce the crash described by Henry , i asked a couple of members of QE to try and re-produce the issue , however they also had no luck.
[~dspells] Hi , just to let you know I'm on TiSlack most days from 8-5(UTC-08:00) , if you're online around that time we could work together to solve the issue you're having with the debugger :)!.
Our app developer is currently experiencing a similar issue since updating Appcelerator to 5.2.2 [TRACE] : [ioslib] App installed [TRACE] : [ioslib] Running: /Applications/Xcode.app/Contents/Developer/usr/bin/simctl launch F11E1C30-095A-42E5-82E4-AAE3FA15CC16 nl.dedicon.daisylezer01 [TRACE] : [ioslib] App launched [TRACE] : [ioslib] Found application log file: /Users/alexander/Library/Developer/CoreSimulator/Devices/F11E1C30-095A-42E5-82E4-AAE3FA15CC16/data/Containers/Data/Application/7DE5CB43-478D-4055-83B4-9843FF057A65/Documents/d34a4081-4846-40e5-9999-dd90c5f5bb49.log [TRACE] : [Daisylezer] assertion failed: 15E65 13E230: libxpc.dylib + 57882 [66C28065-C9DB-3C8E-926F-5A40210A6D1B]: 0x7d -- Start simulator log ------------------------------------------------------- *[DEBUG] : libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: basic_string* {noformat} Operating System Name = Mac OS X Version = 10.11.4 Architecture = 64bit # CPUs = 8 Memory = 16.0GB Node.js Node.js Version = 0.12.7 npm Version = 2.11.3 Appcelerator CLI Installer = 4.2.4 Core Package = 5.2.2 Titanium CLI CLI Version = 5.0.6 node-appc Version = 0.2.31 {noformat}
[~devillers] Hello , I'm sorry you have ran in to a critical bug, as this ticket is regarding a different issues. Could you please create a new ticket with simple steps to re-produce the issue, also I'm assuming you mean SDK 5.2.2 if so create a TIMOB ticket if you mean the CLI create a CLI ticket. Please also try running it on [5.4.0](http://builds.appcelerator.com/#master) with main-thread enabled and see if that fixes the issue, if it does not.We'll address the new ticket as soon as possible :). Thank you!
It would be good to see a stack trace from Martin. My crash log shows the same crash (i.e.) "[INFO] : libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: basic_string". Also it looks like he crashed while launching (which mine did). It just doesn't show which thread crashed (i.e. is it the TI::Debugger thread). How do you know his is a different crash without knowing what thread crashed? Or did I missed the thread somewhere?
I apologise I did not think you were getting a out of range crash. I checked the crash logs and you are getting the same error, my mistake. From what you explained above it seemed the crash was happening when deleting a breakpoint , also if we cannot re-produce the issue we'll have a hard time fixing it. I was hoping that the issue is different while still relating, if we were able to re-produce Martins issue it could help to solve both bugs. As I mentioned on a previous comment , the best way to re-produce this issue on our environment and have it fixed as soon as possible was if we could get in touch through Ti.Slack , that way we could work together on seeing what differs inside your environment and re-produce the issue.
I went on to TiSlack this morning and tried sending you a direct message Angel. I was on for about an hour starting at 8:14 central time.
[~Alexander Baars] Thank you , we will investigate the ticket soon! Could you also please attach a sample project to the description or code to re-produce. [~dspells] That's actually 6:14 my time i've replied on slack , i keep it open for the majority of the day, thanks :)!
[~dspells] Hello, could you please test the issue again with the [5.4.0](http://builds.appcelerator.com/#master) and with main-thread enabled. There was PR pushed with one of the tickets i related which will most likely also fix this issue. Thanks !
This is an improvement. I'm using 5.4.0.v20160419163640 I can now debug without crashing on launch. I was able to step through some code and delete a breakpoint without crashing. However, many times my app will freeze when hitting a breakpoint specifically when I hit a breakpoint twice in a row. Steps 1) Put a breakpoint in handleMenuEvent which is located in index.js of my current version 2) Press "Freedom Project" in the sidebar menu Note that "Freedom Project" is selected and that it stops at the breakpoint without crashing I can then step, remove and add breakpoints without crashing 3) Press F8 to continue 4) On the next menu choose "Presidential Minute Series" At this point the menu item gets selected and the app stops but the debugger does not come up. It's like the breakpoint is hit but the debugger is frozen / never shows the traceback in the "Debug Tab". If on the other hand if I have different breakpoints throughout the app, I can hit several of the breakpoints successfully but usually when I hit one of the breakpoints twice either in a row or not in a row it will freeze. If I have no breakpoints or I just "Run" instead of debug I can navigate through the menus, play content in the video player, etc and never freeze. If you need me to send you my latest project I should be able to do that if you think it will help. Thanks for the drastic improvement but it's still not really usable. Also, do you have an idea on how I might be able to see where it is frozen in the TiDebugger or look at a process in the activity monitor to see the status or something like that?
Hello Angel, I tested using sdk [5.4.0.v20160419234222](http://builds.appcelerator.com/mobile/master/mobilesdk-5.4.0.v20160419234222-osx.zip) Now the app doesn't crash and I am able to debug. The debugger stops on every breakpoint (single or consecutive ones). Best regards, Alexander
[~dspells] Hi could you upload the new project you're using, or just create a very simple app where you're re-producing this. As the one thats added to the description just has channel and episode on the side. Both which i can trigger and not freeze the debugger. Thank you :D! As for your inquiry , short answer: No. Long Answer : It's quite difficult as you cannot attach the debugger Xcode project to the running application. Consequently the best option is to add a lot of logs and see which logs get hit and which do not. As for on which method it crashed you can see that on the crash logs. For example before when the application was crashing for String out of range , you can see the last method ran is sourceParsed inside the DebuggerInterface class. Edit: When enabling main-thread instead of doing it the way i suggested above use :
also make sure that his property is added above the iOS tag. We changed the way mainThread is declared for parity reasons.I am crashing with this crash frequently. This is happening when I click in the text area. Tonight it happened 5 times in less than 30 minutes with Ti SDK 5.4.0.v20160506103806 [Crash Report](https://gist.github.com/AngelkPetkov/29c11e38a9e754d77f09169fd63daffe)
[~dspells] Hi, the original crash that this ticket reported has been fixed, from what I can see on the crash report its happening on a different thread now. This isn't the same string out of range crash as described above by yourself and Alexander, there is also no textArea in the attached project. Could you please create a new ticket with a very simple re-producible case regarding the textArea crash. This will make it a lot easier to fix promptly and for our QE team to test and close both tickets. We will prioritize the new ticket and attempt to fix it swiftly. Thanks!
Isn't this the crash log that I submitted 2 months ago (see crash log in original description) https://gist.github.com/AngelkPetkov/95f0bf1a37ad4162a24a Isn't it the exact same stack trace as the original crash except debugging a different app? The problem got worse and you fixed the more frequent crash and never fixed the original crash. Every time I click in the main text area I can still produce the original crash. I usually click in the text area and the use Cmd-Shift-B on the mac to add/remove break points when it crashes. You're just playing whack a mole with these bugs. The Debugger has been unstable and crashing with basic_string problems for more than a year now on the Mac. Can't someone there take a little more initiative on this? Is the source code for TiDebugger open source at this point? If so, where do I find it? Thanks!
I am not able to reproduce this issue with what information I can gather from the comments here. I tried to get as close to the environment that encounters this (from what I see in the logs/comments) and tested using: MacOS 10.11.5 (15F31a) Studio 4.6.0.201604292352 Ti SDK 5.4.0.v20160509133737 Appc NPM 4.2.4 Appc CLI 5.2.2 Xcode 7.2.1 (7C1002) I also could not reproduce the issue with our latest, GA stack. This was also tested with run-on-main-thread enabled in the tiapp.xml, outside the
[~dspells] You're right the logs are the same I'm sorry, I was looking at the wrong crash log in comments. Im sure you can understand the confusion with all the posted crash reports in the comments. I asked Eric one of our QE members to try and re-produce the issue once again, however he could not either. Im sorry you feel like we are lacking initiative, but we cannot fix something that we can't re-produce, which seems to be the case here. If you find any other details in your environment that differ from ours please feel free to post them,if you believe they could help us reproduce the issue. Also the debugger is currently a private repo. However even if the debugger was open source there is a lot of other key-factors you need to set it up. Thanks!