I've got Xcode 3.1.2 on OS X 10.5.5. I have an iPhone project that builds fine but the debugger will not hit any of the breakpoints I set. I've tried all the standard fixes that I find on the net:
I've turned off 'Load Symbols Lazily' in Xcode preferences
My active config is Debug
Optimization level is 0 in build settings
I've cleaned all targets and rebuilt
I use Build and Debug (as opposed to Build and Run)
I thought I might have inadvertently tweaked settings on my project. So I created a new project and that one has the same problem.
I'm hoping that I am missing something easy here. My debugger was working just a few days back but all of a sudden it has stopped.
UPDATE:
Things are just getting stranger. Here are some answers to the responses
I cannot find 'GCC 4.0 - Code Generation' options anywhere. I've looked hi and low in both Target and Executable Info pages. The only option I see is to select the compiler version, and GCC 4.0 is selected, but that is a one-line section with no additional options.
About where to put breakpoints: My only breakpoint for now is in main(), and it is not being hit
I am starting the debugger with the Run -> Debug (/% Y) command. Still no luck
UPDATE 2:
Changed Base SDK in target settings to Sim 2.2.1. Changed Active SDK to Sim 2.2.1.
Now I can see GCC 4.0 Code Generation options - Debug Symbols are checked
Still does not hit breakpoints
here is the Console log (breakpoint set at first line of main.m):
[Session started at 2009-03-06 21:29:19 -0600.]
Loading program into debugger…
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
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".warning: Unable to read symbols for "/System/Library/Frameworks/UIKit.framework/UIKit" (file not found).
warning: Unable to read symbols from "UIKit" (not yet mapped into memory).
warning: Unable to read symbols for "/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics" (file not found).
warning: Unable to read symbols from "CoreGraphics" (not yet mapped into memory).
Program loaded.
sharedlibrary apply-load-rules all
Attaching to program: `/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/753D12B3-777C-473B-B098-3E0AF6282545/TestApp.app/TestApp', process 577.
Re-enabling shared library breakpoint 1
Also is here the gdb log:
t=0.000852 Tepoch=1236463545.631514
<- (gdb)
-> 135-gdb-version
# PBXGDB_MIGDBVersionCommand t=4.308986 Tepoch=1236463549.939648
-> 136-gdb-set auto-raise-load-levels 1
# PBXGDB_MISetAutoRaiseSymbols t=4.309420 Tepoch=1236463549.940082
-> 139-gdb-set env __CF_USER_TEXT_ENCODING 0x0:0:0
# PBXGDB_MISetEnvCommand t=4.309702 Tepoch=1236463549.940364
-> 140-gdb-set env USERBREAK 1
# PBXGDB_MISetEnvCommand t=4.309935 Tepoch=1236463549.940598
-> 141-gdb-set env DYLD_FRAMEWORK_PATH /Projects/TestApp/build/Debug-iphonesimulator
# PBXGDB_MISetEnvCommand t=4.310175 Tepoch=1236463549.940837
-> 142-gdb-set env Apple_PubSub_Socket_Render /tmp/launch-GqkpX5/Render
# PBXGDB_MISetEnvCommand t=4.310568 Tepoch=1236463549.941231
-> 143-gdb-set env SECURITYSESSIONID 715cd0
# PBXGDB_MISetEnvCommand t=4.310803 Tepoch=1236463549.941465
-> 144-gdb-set env DYLD_LIBRARY_PATH /Projects/TestApp/build/Debug-iphonesimulator
# PBXGDB_MISetEnvCommand t=4.311040 Tepoch=1236463549.941702
-> 145-gdb-set env SSH_AUTH_SOCK /tmp/launch-hRgLzb/Listeners
# PBXGDB_MISetEnvCommand t=4.311299 Tepoch=1236463549.941961
-> 146-gdb-set env HOME /var/root
# PBXGDB_MISetEnvCommand t=4.311587 Tepoch=1236463549.942250
-> 147-gdb-set env SHELL /bin/sh
# PBXGDB_MISetEnvCommand t=4.311818 Tepoch=1236463549.942480
-> 148-gdb-set env DYLD_NO_FIX_PREBINDING YES
# PBXGDB_MISetEnvCommand t=4.312048 Tepoch=1236463549.942710
-> 149-gdb-set env COMMAND_MODE unix2003
# PBXGDB_MISetEnvCommand t=4.312281 Tepoch=1236463549.942943
-> 150-gdb-set env DYLD_NEW_LOCAL_SHARED_REGIONS YES
# PBXGDB_MISetEnvCommand t=4.312546 Tepoch=1236463549.943209
-> 151-gdb-set env SSH_ASKPASS /Developer/Library/PrivateFrameworks/DevToolsInterface.framework/Resources/Xcode SSHPassKey
# PBXGDB_MISetEnvCommand t=4.312780 Tepoch=1236463549.943443
-> 152-gdb-set env PATH /Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin
# PBXGDB_MISetEnvCommand t=4.313612 Tepoch=1236463549.944275
-> 153-gdb-set env DISPLAY /tmp/launch-yrv3vV/:0
# PBXGDB_MISetEnvCommand t=4.313849 Tepoch=1236463549.944512
-> 154-gdb-set env USER root
# PBXGDB_MISetEnvCommand t=4.314141 Tepoch=1236463549.944803
-> 155-gdb-set env NSUnbufferedIO YES
# PBXGDB_MISetEnvCommand t=4.314377 Tepoch=1236463549.945039
# Enqueue seq in Command Q: <PBXGDB_SetupSharedLibrarySequence: 0x9049db0> t=4.314625 Tepoch=1236463549.945288
# Executing Sequence: <PBXGDB_SetupSharedLibrarySequence: 0x9049db0> t=4.314718 Tepoch=1236463549.945380
-> 157-gdb-set inferior-auto-start-cfm off
# PBXGDB_MISetLoadCFMInfoCommand t=4.314895 Tepoch=1236463549.945557
-> 156-gdb-set sharedLibrary load-rules dyld ".*Foundation.*" all dyld ".*libobjc.*" all dyld ".*libauto.*" all dyld ".*/usr/lib/dyld.*" all dyld ".*CFDataFormatters.*" all dyld ".*PBGDBIntrospectionSupport.*" all dyld ".*AppKit.*" all dyld ".*libSystem.*" all dyld ".*CarbonDataFormatters.*" all dyld ".*CoreFoundation.*" extern dyld "/System/Library/Frameworks\\\\|/System/Library/PrivateFrameworks\\\\|/usr/lib" extern dyld ".*" extern exec ".*" extern
# PBXGDB_MISetSharedLibraryLoadSymbolsCommand t=4.315975 Tepoch=1236463549.946637
-> 137-file-exec-and-symbols "/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp"
# PBXGDB_MILoadExecutableCommand t=4.320612 Tepoch=1236463549.951275
# Enqueue seq in Command Q: <PBXGDB_FixAndContinueIsSupportedSequence: 0x9bdc260> t=4.321476 Tepoch=1236463549.952138
# Enqueue seq in Command Q: <PBXGDB_NewBreakpointSequence: 0xa516f90> t=4.321941 Tepoch=1236463549.952603
# Enqueue seq in Command Q: <PBXGDB_AttachControlSequence: 0xa4fceb0> t=4.322157 Tepoch=1236463549.952820
<- ~"GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)\n"
<- ~"Copyright 2004 Free Software Foundation, Inc.\n"
<- ~"GDB is free software, covered by the GNU General Public License, and you are\nwelcome to change it and/or distribute copies of it under certain conditions.\nType \"show copying\" to see the conditions.\nThere is absolutely no warranty for GDB. Type \"show warranty\" for details.\n"
<- ~"This GDB was configured as \"i386-apple-darwin\"."
<- 135^done,version="6.3.50-20050815 (Apple version gdb-962)",rc_version="962",target="i386-apple-darwin",build-date="Sat Jul 26 08:14:40 UTC 2008",time={wallclock="0.03311",user="0.00081",system="0.00014",start="1236463549.989179",end="1236463550.022291"}
# processing result t=4.392345 Tepoch=1236463550.023007
<- (gdb)
<- 136^done,time={wallclock="0.00005",user="0.00005",system="0.00001",start="1236463550.024272",end="1236463550.024325"}
# processing result t=4.394163 Tepoch=1236463550.024826
<- (gdb)
<- 139^done,time={wallclock="0.00007",user="0.00005",system="0.00002",start="1236463550.025511",end="1236463550.025581"}
# processing result t=4.395347 Tepoch=1236463550.026010
<- (gdb)
<- 140^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.026564",end="1236463550.026597"}
# processing result t=4.396328 Tepoch=1236463550.026991
<- (gdb)
<- 141^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.027857",end="1236463550.027890"}
# processing result t=4.397653 Tepoch=1236463550.028315
<- (gdb)
<- 142^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.029080",end="1236463550.029113"}
# processing result t=4.398865 Tepoch=1236463550.029528
<- (gdb)
<- 143^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.030126",end="1236463550.030159"}
# processing result t=4.399923 Tepoch=1236463550.030585
<- (gdb)
<- 144^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.031449",end="1236463550.031482"}
# processing result t=4.401855 Tepoch=1236463550.032518
<- (gdb)
<- 145^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.033257",end="1236463550.033291"}
# processing result t=4.403022 Tepoch=1236463550.033685
<- (gdb)
<- 146^done,time={wallclock="0.00006",user="0.00003",system="0.00002",start="1236463550.034226",end="1236463550.034287"}
# processing result t=4.404018 Tepoch=1236463550.034680
<- (gdb)
<- 147^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.035215",end="1236463550.035247"}
# processing result t=4.405007 Tepoch=1236463550.035670
<- (gdb)
<- 148^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.036306",end="1236463550.036340"}
# processing result t=4.406068 Tepoch=1236463550.036731
<- (gdb)
<- 149^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.037344",end="1236463550.037377"}
# processing result t=4.407107 Tepoch=1236463550.037770
<- (gdb)
<- 150^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.038448",end="1236463550.038483"}
# processing result t=4.408214 Tepoch=1236463550.038876
<- (gdb)
<- 151^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.040541",end="1236463550.040576"}
# processing result t=4.410438 Tepoch=1236463550.041101
<- (gdb)
<- 152^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.041901",end="1236463550.041933"}
# processing result t=4.411665 Tepoch=1236463550.042327
<- (gdb)
<- 153^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.042984",end="1236463550.043016"}
# processing result t=4.412784 Tepoch=1236463550.043446
<- (gdb)
<- 154^done,time={wallclock="0.00003",user="0.00002",system="0.00001",start="1236463550.043956",end="1236463550.043988"}
# processing result t=4.413717 Tepoch=1236463550.044379
<- (gdb)
<- 155^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.044974",end="1236463550.045007"}
# processing result t=4.414737 Tepoch=1236463550.045400
<- (gdb)
<- 157^done,time={wallclock="0.00003",user="0.00003",system="0.00001",start="1236463550.046108",end="1236463550.046141"}
# processing result t=4.415931 Tepoch=1236463550.046594
<- (gdb)
<- 156^done,time={wallclock="0.00005",user="0.00005",system="0.00001",start="1236463550.050271",end="1236463550.050324"}
# processing result t=4.420235 Tepoch=1236463550.050897
-> 158sharedlibrary apply-load-rules all
# PBXGDB_MISharedLibraryApplyLoadRulesCommand t=4.420386 Tepoch=1236463550.051049
<- (gdb)
<- &"warning: Unable to read symbols for \"/System/Library/Frameworks/UIKit.framework/UIKit\" (file not found).\n"
<- &"warning: Unable to read symbols from \"UIKit\" (not yet mapped into memory).\n"
<- &"warning: Unable to read symbols for \"/System/Library/Frameworks/CoreGraphics.framework/CoreGraphics\" (file not found).\n"
<- &"warning: Unable to read symbols from \"CoreGraphics\" (not yet mapped into memory).\n"
<- 137^done,time={wallclock="0.34917",user="0.17115",system="0.11409",start="1236463550.052577",end="1236463550.401747"}
# processing result t=4.771918 Tepoch=1236463550.402580
<- (gdb)
<- &"sharedlibrary apply-load-rules all\n"
<- 158^done
# processing result t=4.820019 Tepoch=1236463550.450681
# didFinish Sequence: <PBXGDB_SetupSharedLibrarySequence: 0x9049db0> t=4.820135 Tepoch=1236463550.450797
# Executing Sequence: <PBXGDB_FixAndContinueIsSupportedSequence: 0x9bdc260> t=4.820259 Tepoch=1236463550.450921
-> 159-mi-verify-command file-fix-file-is-grooved
# PBXGDB_MIVerifyCommandCommand t=4.820398 Tepoch=1236463550.451060
<- (gdb)
<- 159^done,name="file-fix-file-is-grooved",defined="true",implemented="true",time={wallclock="0.00011",user="0.00007",system="0.00001",start="1236463550.451848",end="1236463550.451955"}
# processing result t=4.821746 Tepoch=1236463550.452409
-> 160-file-fix-file-is-grooved
# PBXGDB_MIFixAndContinueSupportedCommand t=4.821894 Tepoch=1236463550.452556
<- (gdb)
<- 160^done,supported="1",details="Yes grooved!",time={wallclock="0.00006",user="0.00005",system="0.00002",start="1236463550.453356",end="1236463550.453417"}
# processing result t=4.823203 Tepoch=1236463550.453865
# didFinish Sequence: <PBXGDB_FixAndContinueIsSupportedSequence: 0x9bdc260> t=4.823344 Tepoch=1236463550.454006
# Executing Sequence: <PBXGDB_NewBreakpointSequence: 0xa516f90> t=4.823433 Tepoch=1236463550.454095
# Passed verification of state before break create command t=4.823569 Tepoch=1236463550.454231
-> 161-break-insert -l -1 -f -s "TestApp" "\"main.m:13\""
# PBXGDB_MICreateFileBreakpointCommand t=4.823679 Tepoch=1236463550.454342
<- (gdb)
<- =shlib-state-modified,shlib-info=[num="1",name="TestApp",kind="-",dyld-addr="-",reason="exec",requested-state="Y",state="Y",path="/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp",description="/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp",loaded_addr="",slide="0x0",prefix="",dsym-objpath="/Projects/TestApp/build/Debug-iphonesimulator/TestApp.app.dSYM/Contents/Resources/DWARF/TestApp"]
<- 161^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000028cf",func="main",file="/Projects/TestApp/main.m",line="13",shlib="/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp",times="0"},time={wallclock="0.15835",user="0.00321",system="0.00184",start="1236463550.455187",end="1236463550.613542"}
# processing result t=4.996437 Tepoch=1236463550.627100
# didFinish Sequence: <PBXGDB_NewBreakpointSequence: 0xa516f90> t=4.996599 Tepoch=1236463550.627262
# Executing Sequence: <PBXGDB_AttachControlSequence: 0xa4fceb0> t=4.996690 Tepoch=1236463550.627352
-> 162-mi-verify-command target-attach
# PBXGDB_MIVerifyCommandCommand t=4.996824 Tepoch=1236463550.627486
<- (gdb)
<- 162^done,name="target-attach",defined="true",implemented="true",time={wallclock="0.00007",user="0.00006",system="0.00001",start="1236463550.627975",end="1236463550.628046"}
# processing result t=4.998137 Tepoch=1236463550.628799
-> 163-target-attach 288
# PBXGDB_MIAttachCommand t=4.998293 Tepoch=1236463550.628955
<- (gdb)
<- ~"Attaching to program: `/private/var/root/Library/Application Support/iPhone Simulator/User/Applications/09734C45-F595-4CB9-8707-744E92D66245/TestApp.app/TestApp', process 288.\n"
<- ~"Re-enabling shared library breakpoint 1\n"
<- =shlibs-updated
<- 163^done,thread-id="1",time={wallclock="0.00362",user="0.00151",system="0.00203",start="1236463550.629436",end="1236463550.633055"}
# processing result t=5.010455 Tepoch=1236463550.641117
# Enqueue seq in Command Q: <PBXGDB_ThreadListSequence: 0xa4e0520> t=5.011284 Tepoch=1236463550.641946
-> 164-exec-continue
# PBXGDB_MIContinueExecutableCommand t=5.011420 Tepoch=1236463550.642082
<- (gdb)
<- 164^running
# processing result t=5.070065 Tepoch=1236463550.700727
# didFinish Sequence: <PBXGDB_AttachControlSequence: 0xa4fceb0> t=5.071843 Tepoch=1236463550.702505
<- (gdb)
I cannot find 'GCC 4.0 - Code
Generation' options anywhere. I've
looked hi and low in both Target and
Executable Info pages. The only option
I see is to select the compiler
version, and GCC 4.0 is selected, but
that is a one-line section with no
additional options.
That's an Xcode bug in 3.1.1 and 3.1.2 if the Active SDK is out of synch with the target's Base SDK. Set the Target's Base SDK to Simulator, make sure your Active SDK is Simulator, and try again.
If you really want this answered, you're going to have to post more information about your project: a screen shot of the Build Settings, or text from the Debugger Console.
UPDATED:
Also note in Xcode > Preferences > Debugging:
alt text http://idisk.mac.com/cdespinosa/Public/GDB%20Log.png
Check the box, enter a reasonable path into the path field, try your debug scenario, then file a bug at http://bugreporter.apple.com with the log attached and a description of your scenario, or ask the good people over at xcode-users#lists.apple.com. The gdb log contains all the information about how the debugger is interacting with your application.
In the Xcode preferences go into the debugging section and turn off 'Load symbols lazily'.
That fixed it for me a few months ago when I first run into this problem.
This is sort of a "is it plugged in" answer, but hey, sometimes that is the problem: Are breakpoints enabled? Sometimes when I debug, I forget to click the button in the debugging toolbar that enables and disables breakpoints.
The GCC 4.0 - Code Generation section only shows up when you set the Active SDK to Device - iPhone OS 2.x. Go figure. They disappear when the Active SDK is the simulator.
You should change your Active SDK to Device, change the settings, and then change back to Simulator. The settings made under Device should also hold for Simulator. This also works with eg. setting a -DDEBUG flag for preprocessing.
(Update: I was only half right. See Chris Espinosa's accepted answer re: this SDK bug. It's not that the GCC 4.0 section shows up when the Active SDK is set to "Device," it's that your Base SDK and Active SDK must match up to access these settings).
Another simple suggestion:
Are the breakpoints light blue are dark blue?
Xcode allows you to deactivate breakpoints and these are indicated with a light blue arrow (like it has been dimmed).
Try running the project by hitting Command-Option-Y (this forces Xcode to start the program with the debugger).
The buttons on the menu bar of Xcode can be somewhat misleading. If the button says 'Run', it doesn't run the program in the debugger. If it says 'Go' it runs the program however it was last built (ie release or debug). Command-Option-Y starts the program specifically in the debugger.
Also, make sure your breakpoints are enabled. You can right click on them to check. Also, in the Debugger window, there should be an option on the toolbar for Activate or Deactivate Breakpoints. Make sure they're activated.
This may be an exceptionally obvious answer, but it could work. Have you tried adding breakpoints in code other than main() ? For instance, in the App Delegate's applicationDidFinishLaunching method? I know it SHOULD go through main first, but since that code in main is not normally modified for iPhone apps, it might be a bit flaky. It's worth a try, anyway.
Also, to find the GCC 4.0 - Code Generation options, click the triangle to open the Targets group, and click on your app's name underneath Targets. Click on the Info button up in the top of the Xcode window and you'll get the settings for your app. Go to Build. Make sure the Show: dropdown is set to All Settings. If you scroll down from there, it should be one of the lists you can edit (after Versioning and before GCC 4.0 - Language)
When the program is running, can you do a CTRL-C in the Console window (while cursor is there). If you interrupt the program type info br which should give a list of the active breakpoints, question then is, are they what you set?
There are two gdb configuration files that can be good to have a look at.
/etc/gdb.conf
Mine have MD5 (/etc/gdb.conf) = 31b58e1ecf038554faadf777d63e9085
~/.gdbinit
I have no, do you have one?
Have you verified that your build configuration is using your development certificate for code signing?
If you are using an Ad Hoc certificate, it'll still build and run fine, but shortly after launching the app, Xcode will detach from the device so no breakpoints will ever hit. You can quickly tell whether it has detached or not if you look in the bottom left of the main Xcode window after you've clicked Build & Go - if you aren't using the actual development device certificate, you'll see a message that says something like "Invalid Hex Code Received from Device".
I looks like you are running the program as root, that doesn't seem to be right...
In your build setting list, you don't cover the most crucial one:
alt text http://idisk.mac.com/cdespinosa/Public/Generate%20Debug%20Symbols.png
Make sure Generate Debug Symbols is checked for the Debug configuration, and make sure that the Debug configuration is active when you Build and Debug.
Two other things to try:
1) Uncheck Fix and Continue. Your detailed gdb log indicates that it may be on. Make sure you are looking at the target settings and not the project settings when confirming this.
2) Try not running as root. It's unclear why you need to. It is possible that Xcode running as root has interactions with the simulator; frankly we don't use that configuration much so I wouldn't know.
The log shows everything operating pretty normally. You have a built binary that's being launched in the Simulator; it's the right architecture and well-formed; you have debug symbols; you have a breakpoint, and the breakpoint is being set. We're taking your word for it (as we don't see your source) that the breakpoint is actually on a line of code that is being executed.
If you are using an Ad Hoc certificate, it'll still build and run fine, but shortly after
launching the app, Xcode will detach from the device so no breakpoints will ever hit.
This helped me.
I have to ask, as I had the same problem, is this a 'real' mac? There is this exact problem with the voodoo hacintosh kernal. If you are using the voodoo kernal, boot with std_dyld=1 and all will be well
This really works on voodoo kernel, booting with std_dyld=1 make Xcode stop at breakpoint. Amazing tip, really. Many thanks to you John your a kind of life saver !!!
I used OSX86Tools to add this boot flag automatically.
Polo
I tried pretty much everything in this thread and restarting the device solved my problem.
I just had the same problem. I don't have a real solution yet, but I figured out, that in my case it is device dependent. The error only happens on my iPod Touch 4G. When I switch to my iPhone 3G, everything works fine and the breakpoints work again.
I don't know if this has anything to do with the problem, but may be the iPod4 has problem due to the installed iOS 5 beta 2. Usually when I encounter a bug in iOS 5 it's fine to just reboot the device. However... rebooting the iPod4 didn't help in my case...
Solution:
This problem bugged me now for some weeks, but I finally found a solution for my case:
Make sure the SDK on your Mac is the same (or newer) as the iOS version on your device.
Reboot the device while it is connected via USB and Xcode is running.
I had a similar situation.. after 6 hours of debugging and project file comparison, it finally worked. The situation was I had a 2 year old project originally made in Xcode 3.1 days. I tried to run it in Xcode 4.5.1 with breakpoints and it never worked.
Here is what I did to fix it..
1) In the Project>Build Settings.. Search for Debug.
2) Build active Architecture only > Change Debug to Yes
3) Generate Debug Symbols > Yes
4) Preprocessor Macros > Debug = 1
It runs fine now.
Apple should really improve the overall Xcode experience. I understand its free (hey, you get what you pay for), but still, the bugs in it is almost insulting to developers.
Related
I have multiple installations of Eclipse(2021-12) + PyDev(9.3.0.202203051235) all using Iron Python(2.7). All running on Windows 10. They all run the scripts as expected, but one installation has a much more robust console output when debugging, almost like a tracing option is enabled. I've tried reinstalling, deleting workspaces, deleting '.metadata' folders, etc. All the project settings seem identical.
Any ideas how to minimize the console output? Something in registry?
Expected Console output:
pydev debugger: starting (pid: 15312)
Actual Console output:
1.99s - Using GEVENT_SUPPORT: False
0.00s - Using GEVENT_SHOW_PAUSED_GREENLETS: False
0.00s - pydevd __file__: C:\\Eclipse-2021-12-R\plugins\org.python.pydev.core_9.3.0.202203051235\pysrc\pydevd.py
0.11s - Initial arguments: (['C:\\Eclipse-2021-12-R\\plugins\\org.python.pydev.core_9.3.0.202203051235\\pysrc\\pydevd.py', '--multiprocess', '--protocol-http', '--print-in-debugger-startup', '--vm_type', 'python', '--client', '127.0.0.1', '--port', '60413', '--file', 'C:\\Test.py'],)
0.00s - Current pid: 8884
pydev debugger: starting (pid: 8884)
Those should only appear if you add an environment variable asking it to be shown.
i.e.: Something as:
PYDEVD_DEBUG=1
PYDEV_DEBUG=1
Maybe you have such an environment set in your launch configuration or interpreter configuration or elsewhere in your system?
You may want to check the os.environ of the running program to see what's set there.
I am on linux ubuntu and target is a PIC18F47J53.
I basically want to program the chip and then let it run, using command lines and using pickit4.
using ipecmd (from mplab x ide v5.45), this is my command:
/opt/microchip/mplabx/v5.45/sys/java/zulu8.40.0.25-ca-fx-jre8.0.222-linux_x64/bin/java -jar /opt/microchip/mplabx/v5.45/mplab_platform/mplab_ipe/ipecmd.jar -TPPK4 /P18F47J53 -M -F"/path_to_myfile.hex" -W
This is my output
DFP Version Used : PIC18F-J_DFP,1.4.41,Microchip
*****************************************************
Connecting to MPLAB PICkit 4...
Currently loaded versions:
Application version............00.06.66
Boot version...................01.00.00
Script version.................00.04.17
Script build number............db473af2f4
Tool pack version .............1.6.961
PICkit 4 is supplying power to the target (3.25 volts).
Target device PIC18F47J53 found.
Device Revision Id = 0x1
*****************************************************
Calculating memory ranges for operation...
Erasing...
The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3ff
program memory: start address = 0x1fc00, end address = 0x1fff7
configuration memory
Programming/Verify complete
Program Report
30-Jan-2021, 12:54:41
Device Type:PIC18F47J53
Program Succeeded.
Operation Succeeded
All good, and takes about 12 seconds, however, after that the pickit4 turns off the power target, and the pickit LED is BLUE (I guess state "ready")
The main question is how can I let the pickit4 powering the boards? any specific parameter? (I cannot find on the readme.html)
If I use MPLAB X IPE GUI to program, the programming is much quicker (3 or 4 seconds), the pickit LED is YELLOW and the target is left powered on. (I selected "release from reset")
I have tried to get the log out with as many details as possible, but I cannot see the commands sent to the pickit4.
Any idea? thanks
I realize that it's been a while since you asked, but i put the answer here for anyone who needs it. Add -OL to your command line options.
I've been stuck for a little while now. I am using a PIC18J67j60 with MPLAB IDE (8.92).
My goal is to write my application (application works fine) at the address 0x2A in the PIC18 program memory.
To do so, I added the 18f67j60_g.lkr linker script into my application project (in the "Linker Script" folder). In this 18f67j60_g.lkr script, I added the line : " CODEPAGE NAME=page START=0x2A END=0xFFF".
Then I also added the c018i.c file in the "Source Files" folder of my project and into it, I changed the line "#pragma code _entry_scn=0x000000" to "#pragma code _entry_scn=0x2A".
Everything is compiling and I checked in my project.MAP file and as expected it says : " _entry_scn code 0x00002a program 0x000006" and "start 0x00002a end 0x00013d ".
Then, I use MPLAB IPE only to load the hex.file (obtained from the compilation) (with a pickit3) into my PIC18 (the picKit3 powers the PIC18). BUT in the output window of MPLAP IPE, it says the start writting address is 0x00.. instead of 0x2A. And I dont get why its not writing at 0x2A address..
Thank you for all your help
I downloaded and installed the latest Ma version of Maxima from source forge. When I try to launch it, I get
“Maxima.app” is damaged and can’t be opened. You should move it to the Trash.
This happens with both available versions, the one with VTK and the one without VTK.
How can I get it running?
I have MacOS 10.12.6
and both versions are here:
https://sourceforge.net/projects/maxima/files/Maxima-MacOS/5.40.0-MacOSX/
Others have run into the same problem. I don't use MacOS so I'm not sure what the problem is. Anyway, take a look at this bug report: #3316: Maxima VTK for Mac 5.40 is corrupt. The person who submitted it reported they got it working by following the advice in the comments.
See also thread 39: https://sourceforge.net/p/maxima/support-requests/39/
This is a really important thread to the larger MacOS community.
I have a MacBook Pro running OS X El Capitan, which is locked down a few versions back from the current MacOS Mojave.
I spent an entire night trying to get every wxMaxima from 5.36 to 5.42 running without success - even compiling from sources.
In desperation I found the thread 39 and entered the line:
(setf sb-impl::default-external-format :utf-8)
into a ~home/.sbclrc file (/Users/myName/.sbclrc). It was only then that the GUI and the Maxima engine could connect and a normal session could be established. Maxima, its maintainers and its users are too important a world resource to be stymied by such an esoteric and non-obvious bug.
A user encountering this bug will first go into the preferences menu and start trying to make sure that the file addresses and port numbers are correct, but experimentation can corrupt these and lead to other problems.
In my case following excerpt from https://sourceforge.net/p/maxima/mailman/message/35910588/ helped:
(0) Double-click the icon of "Terminal.app" in the folder "/Applications/Utilities", then the command-line-user-interface window is opened.
(1) Move the current working directory to the location of the disc image with the command "cd". (e.g. "Downloads" folder)
$ cd $HOME/Downloads
(2) You can check the attribute with the command "ls -l#":
(You will be able to find "com.apple.quarantine" which is the name of the attribute.)
$ ls -l# ./*.dmg
-rw-r--r--# 1 name staff 471227521 6 24 23:17 ./Maxima-5.40.0-VTK-macOS.dmg
com.apple.quarantine 62
(3) Remove the attribute "com.apple.quarantine" with the command "xattr -d com.apple.quarantine ./*.dmg":
$ xattr -d com.apple.quarantine ./Maxima-5.40.0-VTK-macOS.dmg
(4) Verify that the attribute "com.apple.quarantine" was removed:
$ ls -l# ./*.dmg
-rw-r--r-- 1 name staff 471227521 6 24 23:17 ./Maxima-5.40.0-VTK-macOS.dmg
(5) Double-click the icon of the disc image file to open.
After that, you should install Maxima.app into your "Applications" folder ("/Applications"). And you should drag the Launchers icon from the disc image to another place of your filesystem. You can install launchers to anywhere you like.
Then you will be able to launch Maxima with Maxima.app or launchers.
In a device driver source in the Linux tree, I saw dev_dbg(...) and dev_err(...), where do I find the logged message?
One reference suggest to add #define DEBUG . The other reference involves dynamic debug and debugfs, and I got lost.
dev_dbg() expands to dynamic_dev_dbg(), dev_printk(), or no-op depending on the compilation flags.
#if defined(CONFIG_DYNAMIC_DEBUG)
#define dev_dbg(dev, format, ...) \
do { \
dynamic_dev_dbg(dev, format, ##__VA_ARGS__); \
} while (0)
#elif defined(DEBUG)
#define dev_dbg(dev, format, arg...) \
dev_printk(KERN_DEBUG, dev, format, ##arg)
#else
#define dev_dbg(dev, format, arg...) \
({ \
if (0) \
dev_printk(KERN_DEBUG, dev, format, ##arg); \
})
#endif
dynamic_dev_dbg() and dev_printk() call dev_printk_emit() which calls vprintk_emit().
This very same function is called in a normal mode when you just do a printk(). Just note here, that the rest functions like dev_err() will end up in the same function.
Thus, obviously, the buffer is all the same, i.e. kernel intrenal buffer.
The logged message at the end is printed to
Current console if kernel loglevel value (can be changed via kernel command line or via procfs) is high enough for certain message, here KERN_DEBUG.
Internal buffer which can be read by running dmesg command.
Note, data in 2 is kept as long as there still room in the buffer. Since it's limited and circular, newer data preempts old one.
Additional information how to enable Dynamic Debug.
First of all, be sure you have CONFIG_DYNAMIC_DEBUG=y in the kernel configuration.
Assume we would like to enable all debug prints in the built-in module with name 8250. To achieve that we simple add to the kernel command line the following 8250.dyndbg=+p.
If the same driver is compiled as loadable module we may either add options 8250 dyndbg to the modprobe configuration or to the shell command line when do it manually, like modprobe 8250 dyndbg.
More details are described in the Dynamic Debug documentation.
The "How certain debug prints are automatically enabled in linux kernel?" raises the question why some debug prints are automatically enabled and how DEBUG affects that when CONFIG_DYNAMIC_DEBUG=y. The answer is lying in the dynamic_debug.h and since it's used during compilation the _DPRINTK_FLAGS_DEFAULT defines the certain message appearence.
#if defined DEBUG
#define _DPRINTK_FLAGS_DEFAULT _DPRINTK_FLAGS_PRINT
#else
#define _DPRINTK_FLAGS_DEFAULT 0
#endif
you can find dev_err(...) in kernel messages. As the name implies, dev_err(...) messages are error messages, so they will definitely be printed if the execution comes to that point. dev_dbg(...) are debug messages which are more generously used in the kernel driver code and they are not printed by default. So everything you have read about dynamic_debugging comes into play with dev_dbg(...).
There are several pre-conditions to have dynamic debugging working, below 1. and 2. are general preconditions for dynamic debugging. 3. and later are for your particular driver/module/subsystem and can be .
Dynamic debugging support has to be in your kernel config CONFIG_DYNAMIC_DEBUG=y. You may check if it is the case zgrep DYNAMIC_DEBUG /proc/config.gz
debugfs has to be mounted. You can check with sudo mount | grep debugfs and if not existing, you can mount with sudo mount -t debugfs /sys/kernel/debug
refer to dynamic_debugging and enable the particular file/function/line you are interested