iphone Simulator crashing from Xcode run and go - iphone

Does anybody know what might be causing this problem? When I run the code, the program immediately crashes on the simulator before getting anywhere; however if I just go to the simulator and run the program, the changes were loaded and there doesn't seem to be any obvious problems.
Or how could I try to pinpoint this problem?
[Session started at 2009-09-18 03:31:02 -0700.]
GNU gdb 6.3.50-20050815 (Apple version gdb-966) (Tue Mar 10 02:43:13 UTC 2009)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin".sharedlibrary apply-load-rules all
Attaching to process 2171.
gdb-i386-apple-darwin(2172,0x778720) malloc: *** mmap(size=1420296192) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
gdb stack crawl at point of internal error:
[ 0 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300]
[ 1 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (xstrvprintf+0x0) [0x123394]
[ 2 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (xmalloc+0x28) [0x1235b7]
[ 3 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (dyld_info_read_raw_data+0x50) [0x1659d7]
[ 4 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (dyld_info_read+0x1bc) [0x168a80]
[ 5 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (macosx_dyld_update+0xbf) [0x168cc4]
[ 6 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (macosx_solib_add+0x36b) [0x169ff4]
[ 7 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (macosx_child_attach+0x478) [0x17dd39]
[ 8 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (attach_command+0x5d) [0x64eed]
[ 9 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (mi_cmd_target_attach+0x4c) [0x15de9]
[ 10 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (captured_mi_execute_command+0x16d) [0x17453]
[ 11 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (catch_exception+0x41) [0x7a9c2]
[ 12 ] /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/libexec/gdb/gdb-i386-apple-darwin (mi_execute_command+0xa9) [0x16f8f]
/SourceCache/gdb/gdb-966/src/gdb/utils.c:1144: internal-error: virtual memory exhausted: can't allocate 1420296192 bytes.
A problem internal to GDB has been detected, further debugging may prove unreliable.
The Debugger has exited with status 1.The Debugger has exited with status 1.

When this happens for me, I take out code until it runs, then put it back in one piece at a time until something breaks.

Inside Xcode -> Preferences-> Debugging window please uncheck the "Load symbols lazily" option.

Related

GDB Disconnects when trying to debug via openocd

I'm on windows 10 trying to debug my bluepill (STM32f103C8) board using a stlink, openocd, and vscode. I get this pop up: "OpenOCD GDB Server Quit Unexpectedly. See gdb-server output for more details."
And this message in the terminal:
Open On-Chip Debugger 0.11.0 (2021-11-18) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
CDRTOSConfigure
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
Info : Listening on port 50001 for tcl connections
Info : Listening on port 50002 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J36S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.186911
Info : stm32f1x.cpu: Cortex-M3 r1p1 processor detected
Info : stm32f1x.cpu: target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f1x.cpu on 50000
Info : Listening on port 50000 for gdb connections
[2022-06-07T02:43:25.028Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...
My launch.json is as follows:
"version": "0.2.0",
"configurations":
[
{
"name": "GDB",
"cwd": "${workspaceFolder}",
"executable": "./Test/Build/snake.elf",
"request": "launch",
"type": "cortex-debug",
"runToEntryPoint": "main",
"servertype": "openocd",
"device": "STM32f103C8",
"interface": "swd",
"configFiles":
[
"interface/stlink.cfg",
"target/stm32f1x.cfg",
],
}
]
}
I'm not sure what I'm doing wrong. Any help would be greatly appreciated.
I figured out my problem, so I figured I'd shared in case anyone else has similar issues.
arm-none-eabi-gdb was crashing at start up. This was due to me missing python27.dll. You need to have python 2.7 installed, and it has to be the x86 version of python 2.7 because gnu arm for windows is x86.
Its very odd that arm-none-eabi-gdb requires python 2.7 to be installed as it was EOL in 2020, but here we are. I imagine in some future release the python 2.7 dependency will be removed.
Ed's answer is totally correct.
An alternative solution: I ended up running into the same issue and just went with an earlier version of the ARM Embedded Toolchain (gcc-arm-none-eabi-10.3-2021.10) and got my project to debug using OpenOCD for the Nucleo STM32L476RG.
Hope this helps.

Dart stack trace all ends with 3/7/b/f (ARM architecture), while we know ARM/Thumb/Thumb(2) instructions are 2 or 4 bytes - How can that happen?

I see that, Dart stack trace all ends with 3/7/b/f (ARM architecture), while we know ARM/Thumb/Thumb(2) instructions are 2 or 4 bytes.
example: https://github.com/dart-lang/sdk/issues/43274
Warning: This VM has been configured to produce stack traces that violate the Dart standard.
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 29278, tid: 29340, name 1.ui
isolate_dso_base: 6fe9d64000, vm_dso_base: 6fe9d64000
isolate_instructions: 6fe9d74000, vm_instructions: 6fe9d66000
#00 abs 0000006fe9f4e87b virt 00000000001ea87b _kDartIsolateSnapshotInstructions+0x1da87b
#01 abs 0000006fe9f4e4a3 virt 00000000001ea4a3 _kDartIsolateSnapshotInstructions+0x1da4a3
#02 abs 0000006fe9d83ca3 virt 000000000001fca3 _kDartIsolateSnapshotInstructions+0xfca3
Thus, I wonder how could this happen? IMHO the ARM CPU will run the machine instructions (assembly) in the .so file in Android. But how can the CPU run it if all instructions do not align with 2/4 bytes?
Thanks for any suggestions!
The lsb is the "thumb bit" so to say.
You can switch between ARM and thumb mode with the instruction bx or blx.
These instructions scan the lsb, and if it's set, it will switch to thumb mode and to ARM mode if otherwise. Then branch to address&~1
The stack trace shows the return address of the caller functions, and that they are odd indicates that they are written/compiled in thumb mode.

kivy 1.10.1 and 1.11.0 not working on raspberry pi4 Buster

I just received my new raspberry pi4 and did a fresh install with the latest Raspian buster. I installed the latest kivy 1.11 and I cannot have it running. Kivy just get frozen at the start what application you are trying to open.
I also tried to do a fresh install of kivy 1.10.0 on my raspberry PI4 and the problem is the same.
Is there known issues or tricks to have kivy running on PI4 ?
I tried to start an apps I wrote which work working fine on Raspberry PI3 and Raspian.
I added log level = debug but don't see much in the logs.
[INFO ] [Logger ] Record log in /home/asysclay/.kivy/logs/kivy_19-07-09_3.txt
[INFO ] [Kivy ] v1.11.1
[INFO ] [Kivy ] Installed at "/home/asysclay/Container/local/lib/python2.7/site-packages/kivy/__init__.pyc"
[INFO ] [Python ] v2.7.16 (default, Apr 6 2019, 01:42:57)
[GCC 8.2.0]
[INFO ] [Python ] Interpreter at "/home/asysclay/Container/bin/python"
[WARNING] [Deprecated ] Python 2 Kivy support has been deprecated. The Kivy release after 1.11.0 will not support Python 2 anymore
[INFO ] [Factory ] 184 symbols loaded
[DEBUG ] [Cache ] register <kv.lang> with limit=None, timeout=None
[DEBUG ] [Cache ] register <kv.image> with limit=None, timeout=60
[DEBUG ] [Cache ] register <kv.atlas> with limit=None, timeout=None
[INFO ] [Image ] Providers: img_tex, img_dds, img_sdl2, img_gif (img_pil, img_ffpyplayer ignored)
[DEBUG ] [Cache ] register <kv.texture> with limit=1000, timeout=60
[DEBUG ] [Cache ] register <kv.shader> with limit=1000, timeout=3600
[INFO ] [Text ] Provider: sdl2
[INFO ] [Window ] Provider: egl_rpi
[DEBUG ] [Window ] Actual display size: 1920x1080
I got stuck here and even a Control-C cannot stop the apps.
I had the same problem. It appears to be caused by the fact that the text and window providers are different (sdl2 vs. egl_rpi).
Try this test:
export KIVY_WINDOW=sdl2
then run your Kivy program.
If it works, then you need to make the environment change permanent, or put the following at the head of each Kivy python file you write:
import os
os.environ["KIVY_WINDOW"] = "sdl2"
os.environ["KIVY_TEXT"] = "sdl2"
But to be honest, there are probably better solutions. This should work to get you over the hump.
The reply from Prince Hal was very helpful to me to get Kivy 1.11.1 working with Raspbian Buster on a Rpi 3B+. I run this without loading the desktop/window manager. The Kivy application is launched from the console at boot. The last thing that frustrated me is that there was no mouse cursor visible but its functions were there in the background. Setting this environment variable fixed that problem : )

GNU ARM Eclipse: troubles with openocd debug

I'm trying to use Eclipse with GNU ARM plugins to debug my stm32f4-discovery board, however, still no luck. The same board works perfectly in Keil running in the virtual machine, so, it doesn't seem to be hardware problem.
I use Linux Mint 13, I've installed all the prerequisites, I have created templated hello world project, it compiles, and when I try to start debug, it stops at the step "Configuring GDB", and after a couple of seconds it fails with the following:
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:3333
Error message from debugger back end:
localhost:3333: Connection timed out.
localhost:3333: Connection timed out.
Then I tried to manually start openocd:
$ openocd -f /usr/local/share/openocd/scripts/board/stm32f4discovery.cfg
Open On-Chip Debugger 0.7.0 (2014-11-08-01:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v23 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.918263
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
And arm-none-eabi-gdb:
$ arm-none-eabi-gdb ~/projects/test_stm/arm_c_1/Debug/arm_c_1.elf
GNU gdb (GNU Tools for ARM Embedded Processors) 7.6.0.20140731-cvs
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/dimon/projects/test_stm/arm_c_1/Debug/arm_c_1.elf...done.
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x00000000 in ?? ()
(gdb)
Then, openocd said that connection is accepted:
Info : accepting 'gdb' connection from 3333
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
But, when started by Eclipse, it doesn't work, for some reason.
Well, then I tried to keep openocd started manually and alter my Debug configuration: at the "Debugger" tab, I've unchecked "Start OpenOCD locally". Now, debug session a kind of starts: debug perspective is opened, no meaningful errors are echoed, but debug buttons (resume, suspend, etc) remain inactive. The chip isn't even reprogrammed: previous firmware programmed from inside Keil keeps flashing LEDs.
Here's a screenshot of what Eclipse looks like: http://i.imgur.com/sszA0hr.png
Output of openocd:
$ /usr/local/share/openocd/scripts/board openocd -f ./stm32f4discovery.cfg
Open On-Chip Debugger 0.7.0 (2014-11-08-01:25)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : This adapter doesn't support configurable speed
Info : STLINK v2 JTAG v23 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : Target voltage: 2.919691
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3333
Info : stm32f4x errata detected - fixing incorrect MCU_IDCODE
Info : device id = 0x10006413
Info : flash size = 1024kbytes
Warn : acknowledgment received, but no packet pending
undefined debug reason 6 - target needs reset
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000154 msp: 0x20030000
semihosting is enabled
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000154 msp: 0x20030000, semihosting
I even tried to re-install all the Eclipse plugins as well as openocd, nothing helped. What could be the trouble?

Simulated iphone app quits, whenever I turned on debugging

I always build my app choosing with 'Build and run' (not 'build and debug'). While the app running smoothly I opt to put a breakpoint over a line. When I do this the simulated application suddenly quits with a message 'Loading debugger..,Debugging terminated'.
...Actually, this happens only on putting breakpoint on first time.
Any help, please.
Xcode consol log..
Session started at 2010-03-31 20:54:59 +0530.]
GNU gdb 6.3.50-20050815 (Apple version gdb-1461.2) (Fri Mar 5 04:43:10 UTC 2010)
...
This GDB was configured as "x86_64-apple-darwin".A0:0
..
Attaching to process 10016.
Pending breakpoint 1 - ""XXX.mm":247" resolved
Current language: auto; currently objective-c++
sharedlibrary apply-load-rules all
Loading program into debugger…
Pending breakpoint 1 - ""XXX":247" resolved
kill
consol app log....
31/03/10 8:55:02 PM com.apple.launchd.peruser.502[94] (UIKitApplication:com.xxxx.yyyyy[0x25ab][10016]) Exited: Killed
31/03/10 8:55:02 PM SpringBoard[10014] Application 'XXXXXX' exited abnormally with signal 9: Killed
31/03/10 8:55:02 PM SpringBoard[10014] Unable to create CFServerConnection. Telephony state may be incorrect.
Do you have a second monitor connected to your development machine ? If so, try unplugging it and see if that helps. Seriously: http://support.appcelerator.net/discussions/support/572-iphone-simulator-shows-no-windows
I have very similar experience, rebuilding your application will fix the issue.
If it is still crashing try to crack the crash report http://www.anoshkin.net/blog/2008/09/09/iphone-crash-logs/
There is similar topic discussed in another forum go through this http://forums.macrumors.com/showthread.php?t=474267