I’m porting a C++ sdk from Windows to Mac OSX 10.5. I have a problem in Xcode where my breakpoints in certain files will only be hit if I set them while debugging. If I stop debugging and then restart, the breakpoints no longer get hit. If I add them while not debugging, they don't get hit. This is only in certain files and my breakpoints are always dark blue. i.e. I can’t tell the difference between a breakpoint that will get hit and one that won’t.
Specifically, my sdk is made up of various dynamic libraries. These are built using Perforce jam, which calls the various compile and link executables depending on my OS and compiler version (such as Visual Studio’s cl.exe and link.exe). I have a simple (unit testing) command line application that links to these dynamic libraries and calls code in them. This application on Windows is a Visual Studio project, in which I set breakpoints on library code and expect them to be hit.
I’ve created the same C++ command line utility application in Xcode 3.1.2 that links to the sdk dylibs and calls code in them. Some of the breakpoints work fine. I can set breakpoints in code that’s called from the troublesome code, and step out to the troublesome code, which I can then step through fine. The troublesome code is compiled into the same dylib as code that works fine. It’s also long and complicated enough not to be a candidate for inlining.
I’ve tried the following:
Turn Load symbols lazily off.
Compile with both gcc 4.0 and gcc 4.2.
Do a full clean and shutdown.
Delete the user-specific files of the xcodeproj package.
Rename the files so they can’t clash with system files.
Clear everything out of the Breakpoints window.
Create a new Xcode project.
My application is compiled in debug with DWARF format and my libraries are built with the –g flag (along with –v, –arch i386 and –fvisibility-inlines-hidden).
Help would be much appreciated. Thanks.
Update: sorry for not updating this, my Mac port project was postponed. I never resolved this, but discovered that it actually only occurs in constructor bodies. I'll revisit this as and when I hit the problem again.
Have you tried these?
Why aren't my breakpoints working?
Not really an answer: You should make a bug report in the official Apple bugtracker. The chances are high that you get an answer sooner or later there - or perhaps it is really a bug.
Related
I don't have much prior experience in Android Studio. I'm trying to debug a problem in C++ code. Djinni and ninja are used in the product. I know that the same setup with zero additional tweaks is debuggable at another machine.
But on mine, the debugger doesn't want to stop at C++ breakpoints at all. Sometimes it shows "no executable code is associated with this line" message. Other times the breakpoints are just plain red without a check mark.
Debugger log says the debugger is attached.
I don't see the "app/.cxx/Debug" folder, only the "Release" one (the other machine also has only "Release"). Build.ninja files contain release flags for cpp code. Via the search in all files in the project directory, I did not find the set of debug flags that are used in CMakeLists anywhere among the build artefacts.
It seems like I tried everything that I found on SO:
checked for correct build variants
checked jni debuggable true, minify enabled false, empty proguard file
tried different debug types in Run/Debug config -> Debugger (however idk which symbol directories to add manually)
tried debugging in an emulator as well as on a real device
in the emulator, uninstalled the app and did cold boot
used the same Studio version as on that other machine
used the latest Studio version, and the newest preview
cleared caches, cleaned, refreshed linked C++ projects
made clean Studio reinstall with prior deep cleaning of all Gradle and Android files via Terminal
upgraded Gradle
use the same NDK version as in build.gradle
added NDK dir to local.properties manually
tried using "make module app" instead of simple "make" command
Nothing helped so far. Only once after a crash the execution stopped and showed an assembly line with a simple call stack, without details.
I have a C++ gradle app set up in Visual Studio 2019 Community Edition targeting Android. I'm using NDK 20 (the latest version in Microsoft's android sdk repo).
This app is composed of several .so libraries (SDL2, SDL2_image, SDL2_ttf, WolfSSL, MyGameCode, MyGameLibrary, MiscellaneousExternalDependencies.a) and all seems to compile and run properly. The issue I have is in attaching a breakpoint and seeing GDB trying to load the symbols for the associated .so (in this case, my game code specifically).
I have done some testing and found that if I strip out all my game code I can get breakpoints to hit with just my library and all other dependencies. I've also tested and found that including most of my game files still runs. However I have about 10 files that if I remove them everything seems to load just fine. It takes about 42 seconds to load symbols when I have a stripped down version of my project which allows for breakpoints to be hit.
It seems to be total symbols in the project rather than any specific code running during the application's lifetime since I have a main finction in C++ specified which does not load any of my game code and just runs a simple SDL2 test and simply by changing the number of files included in the project I can reproduce the GDB crash or eliminate it.
I should note that my project seems to run just fine without the debugger attached, and I can see output from the C++ modules I'm trying to set breakpoints in. The issue I have is limited to when I try to connect GDB and access a breakpoint through Visual Studio. At that point I am getting what appears to be a stack overflow (or possibly a timeout?) during the symbol loading process.
My question here has a few bullet points:
does GDB have some kind of symbol limit?
If so, is there a way to strip unused symbols from the final ".so" during the build process from within Visual Studio? I want to keep my build process simple to execute.
If not, can I break my project up in some kind of way with .so or .a files to get around this? It doesn't seem that it makes a difference currently if I do that so more advice would be appreciated!
Does Visual Studio's wrapper of GDB and the Android Emulator allow me to increase the timeout if there is a timeout? If I could specify it at like 200 seconds that would definitely be more than enough time to load my project's .so symbols.
Are there any other possible explanations for crashing on loading symbols in this way that have plausible work-arounds?
Essentially I don't know why it's crashing during loading symbols for my .so file
I have provided additional details here including a link to my project and exact testing methodology, but the full thrust of this question is present in this post.
https://developercommunity.visualstudio.com/content/problem/898890/gdb-exited-unexpectedly-with-exit-code-1073741571.html
It turns out replacing the gdb.exe and gdb-orig.exe files from my Microsoft Hosted NDK version 20.0.5594570 with the ones I got from downloading NDK 21 available here solved the problem (r21 at the time of writing): https://developer.android.com/ndk/downloads
There must be a defect which has been recently resolved in GDB itself and which had issues with my project size and/or composition. The NDK r21 bundled version of GDB works perfectly, however.
I have OSX Yosemite 10.10.5, QtCreator 4.1.0, Qt 5.7.0 and Xcode 7.2.1.
If I write any native C++ program in QtCreator (console, gui - anything) I am unable to debug that program from QtCreator. Breakpoints get ignored, the program executes without pause and runs to completion no matter what I try.
I have tried the Xcode's LLDb, system GDB and Homebrew GDB as debuggers. the versions of GDB fail to start. Homebrew GDB has been codesigned.
This all used to (a few year back) just work beautifully and I am at a loss as to what might have changed.
Curiously, if I generate an exception inside the program - like accessing through a null pointer, the debugger shows me where this happens in just the way I would expect so, presumably, the debugger is running but simply treating me with complete disdain.
I know there are many versions of this question but none seem to address the problem adequately or offer workable solutions, or they apply to much older versions of the products.
Any suggestions?
This version of qtCreator (4.1.0) saw the return of the warning about having the build directory at the same level as the project directory. In Windows, this is done automatically. My mac installation does not get it right. (I may have messed a while back - cannot remember).
So - if the build directory is inside the project directory, debugging fails. Move the build directory up to the same level as the project directory and everything seems to work fine.
You can set the default build directory in the preferences/Build & Run dialogue. The path should start with ../
You will need to think about the folder structure before setting up the project unless you want build folders appearing in awkward places. So, a project folder structure like this is OK:
But one like this is not:
If this was already obvious to you, great. I have been messing with this for ages.
Many thanks to those who replied and anyone else who took the time to read the question. What helped e find it was the suggestion by #AlexanderVX that his setup was the same as mine but his worked. The only bit of my setup he could not see in the screenshots was the start of the build path. So that was the clue.
I have a project which I created in Eclipse c++. The project invokes a function that does a lot of loops (Thousands) to calculate the result.
When I run it in Eclipse it takes 1 minute (~70 seconds).
I wanted to add a GUI to the project so I opened a WinForm (Win32) project in VisualStudio2010 and moved all files of the project from the eclipse directory to the new directory (created for VS2010).
Now, when I run the form, the function takes 4-5 minutes. I tried to cancel the progress bar but it wasn't the problem, so I understood that long time is not because of the GUI.
I think the problem is in the compilation in VS2010. I tried to change some Optimizations properties, but the project couldn't be compiled...
How can I reduce the run time?
Thanks!
Basically you answered your own question:
I think the problem is in the compilation in VS2010. I tried to change
some Optimizations properties, but the project couldn't be compiled...
however, it's hard to answer it, since there is a lot of optimization options in both of compilers, it's hard to tell what option makes it much faster/slower. It's also possible (and most probably is) that MS compiler just cant produce exactly the same or similar code to that of Eclipse's compiler.
Your options is to "play" with optimization switches of the VS compiler and see if it helps. You can try to compare it's options to ones of the Eclipse to find differences, but most likely they will be just too different.
As #Zuljin correctly mentioned also check you selected Win32 project, not CLR (Windows Forms) application. If you are using CLR project, then it's natural it will possibly run slower than Native program type.
My bet would be the debugger in VS2010
Build with your optimized settings but then start the generated file from the explorer, not from Visual Studio. You can also deactivate the debugger attachment in the project settings.
See if the run time is any different.
I'm writing a C++ application using VS2010 on two dev computers - both are Win7 64bit SP1. I use git to sync the repositories.
On one of the machines the compiled executable (and also the test exec) stopped working with the following error, while on the other machine it works fine and I'm able to continue development.
The application was unable to start correctly (0xc000000d). Click OK to close the application.
I tried deleting the repository and cloning it again. I also made sure I have the same versions of Boost, git, Visual Studio. Also, I tried debugging (stepping in) but the error occurs before any line of code is reached.
Notice as far as I understand I'm tracking Visual Studio's solution\project configuration files as detailed here.
I'm at a loss, how would you debug this?
UPDATE 1:
Only the Debug version fails to run. The Release version runs fine
UPDATE 2: The executable that doesn't work does work on the other computer!
UPDATE 3: I've reinstalled VS2010 (exactly the same version) - didn't help. Surprisingly the compiled files are not the same size between the two machines.
I got the same problem as you mentioned.
My solution:
Clean the manifest file and rebuild
In the property page-> Manifest tool -> make sure "Additional Options" is set to nothing.
(I set it as "/validate_manifest" before).
Or you can try "Embed Manifest -> NO", rebuild and then set back to Yes. It sounds to be ridiculous, but it really works sometimes. I don't know why.
I got the same phenomenon suddenly without a warning on Win7 / VS2010 / C++. Debug App couldn't be launched, got 0xC000000D at initializing and loading multiple dlls. Found one base dll of my own responsible, played around with linker settings. Modifying settings, incremential rebuild -> app starts, rebuild all -> app crashes again. After setting "generate manifest" to "no" in the linker settings the sample app works, but the main app still crashes. After setting "generate manifest" to "no" for the most of my dlls -> the app starts in debug mode again. The stuff is very spurious, because some dlls need the modified settings others do not.
Have a look at the top two answers to this question
Program crashes with 0xC000000D and no exceptions - how do I debug it?
On the machine where it fails, try running the debug executable NOT under the debugger, and update your question to say what happens. If it crashes, are you able to then attach the debugger whilst the message box is still there and get a stack trace that tells you what function it is crashing in?
This is the weirdest thing....
Try deleting the "ipch" directory and then rebuilding.
Hope it works for you, I have wasted hours on this.
disabling/enabling precompiled headers fixed the issue for me.
I was facing crash on Debug x64 only - I guess it was related to an upgrade from boost 1.50 to 1.52, while keeping pch files.
in my case i got it working again by setting generate manifest to NO on all projects
I have changed "Embed manifest" setting to NO and then back to YES but it didn't help.
For me setting General->Platform Toolset to Windows SDK 7.1 for my program and all dependent libraries compiled with it helped.
It's the ipch just delete the entire folder and it will clear it up. I was confused for a while too.
I saw the error while using OpenCV library compiled with MSVC2010 in a project running on MSVC2015. Changing project configuration properties->General->Platform toolset from Visual Studio 2015(v140) to Visual studio 2010(v100) resolved the error.