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.
Related
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'm using Visual Studio 2017's integration to build and debug a CMake Linux application locally in the Windows Subsystem for Linux.
When running the application, Visual Studio uses an ssh connection to localhost to run cmake -DCMAKE_BUILD_TYPE="Debug" .. and make, then uses gdbserver to debug the application. This works fine for my application's own code, including breakpoints and line-by-line debugging.
This application links to a library file, libhypro.so.17.09, which is also part of a CMake project. This library is also built locally (stored in my Windows file system, built within Linux through the /mnt/c/ mount, just as the main application) in debug mode. CMake did discover that dependency automatically.
I'm having trouble debugging my calls to this library. For example, if I break just before a call to library code and choose to Step Into, this is where I end up:
Note that
the Call Stack has disappeared, showing [Unknown/Just-In-Time compiled code] instead,
I'm inside an unhandled exception (which I'd expect to hit eventually, but certainly not immediately after a Step Into) and
the Modules window indicates that no symbols are available.
In addition, I did set a breakpoint in the library's code, and Visual Studio (correctly) asserts that “the breakpoint will not currently be hit”. Also, Debug output prints Loaded '/mnt/c/Users/felix/git/hypro/build/libhypro.so.17.09'. Cannot find or open the symbol file.
I'm relatively certain that libhypro.so.17.09 does include debug symbols as nm -gC libhypro.so prints a lot of output.
My case appears to be similar to this question but I'm not specifying the library's path manually, it's discovered by CMake.
Why are gdb and, in turn, Visual Studio failing to debug the library's code?
If you are debugging in gdbserver mode, the default, try switching to gdb mode in the project properties / debugging page.
Basically, gdbserver mode is a nice idea that never quite delivered. Here's one discussion about it on the VCLinux GitHub site. As you'll see, gdb will become the default debugging mode once they've fixed the problems with console applications.
[edit] Sorry, I out thought myself. I was using a .bat file to set environment variables that wasn't set up properly. When I went to a straight VS2005 command prompt, the configure ran fine. Sorry for the noise.[/edit]
I'm trying to compile qt-everywhere-opensource for embedded. I'm using MSVC2005. However, I guess I am confused on the process. I am getting compiler errors during the configure step. I thought the configure step was just trying to generate the needed makefiles, so I'm not sure what it is trying to compile.
I expected to modify the mkspec, but I'm not sure if during configure I should point to windows headers or sdk headers. I know during the build phase I should point to sdk headers, but I'm not getting that far.
I can change the errors by modifying INCPATH, there's also a QMAKE_INCDIR that seems to have an effect. It occurred to me that since I pulled the source, maybe configure needs to build the compiler tools, in which case I should point to MSVC headers. I also tried downloading the SDK and adding the path to it's bin folder to my path ahead of the -everywhere- source, but that didn't fix the problem and I don't want to jack up my system too much testing things.
Hope someone out there can help!
When you install Qt from source under Win32, you must:
Extend the PATH variable to include $(QTDIR)\bin, where $(QTDIR) is the directory where you installed Qt.
Open a Visual Studio command prompt in $(QTDIR); a plain old Windows command prompt won't do (unless you run vcvars.bat to load Visual Studio's environment variables; but opening a Visual Studio command prompt directly is better).
At this point, configure should run properly, after which you can run nmake.
I suggest that you clear your previous installation attempts from your system before you try these steps.
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.
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.