as I said in the title, my application simply works fine in debug mode, but when I extract a release mode apk it just crashes on startup.
I have tried every possible fix I could found on google and none worked, that's what I tried so far:-
Setting linking to None / SDK Assemblies Only.
Setting code shrinker to None / ProGaurd.
Enabling support architectures armeabi-v7a and arm64-v8a.
Adding Internet permission.
Cleaning the whole solution and rebuilding everything.
Setting projects assemblies (PCL & Android & IOS) to lowercase names fails the archiving.
Enabling the Use Shared Runtime fails the archiving.
Enabling the Bundle assemblies into native code.
Uninstalling the Mono Shared Runtime from the device.
I also cleaned the solution and did a rebuild after each of these tries...
Nothing worked...
What am I missing here ?!
Thanks in advance ^_^
As #MohamedAshraf mentioned, when he tried to build it on an emulator in the release configuration, the app still crashed.
So, he was able to enable debug symbols and debugging in the release configurations as well, and was able to catch the exception and fix the issue.
Don't forget to turn debugging off in the release config again afterwards.
Related
I'm trying to debug an executable which has been created with CMake configuration
SET(CMAKE_BUILD_TYPE Debug)
However, CLion does not hit any breakpoints. What could be the problem?
I had the same issue today. I figured out that the configuration for the project was not set to Debug. After setting the configuration to Debug all the breakpoints are hit.
Please ensure that you have following configuration:
Select the MenuItem Run/EditConfigurations
Select the right Target
Select Debug as Configuration
Now the breakpoints should be hit.
In case this helps someone else, it turned out that my (somewhat embarrassing) issue was that I was hitting Run instead of Debug. So in the Run menu don't use the play icon, instead choose the cute bug icon instead. Choosing Run was causing it to automatically build the non-debug build so breakpoints wouldn't work. Once I started choosing the bug icon, the breakpoints worked like a charm.
As it has turned out, the executable was compiled with following CMake options (further down in the script):
SET(CMAKE_C_FLAGS_DEBUG "-D_DEBUG")
This was breaking debug functionality for CLion (it was also breaking most of the debug functionality of gdb)
I also had the same Problem. Since 2016.3 CLion changed the CMake workflow so that only one configuration is allowed at one time clion new workflow
The solution is File -> Settings -> Build, Excution, Deployment -> change the build configuration
In my case my CMake option CMAKE_BUILD_TYPE was already set to DEBUG on CMake Settings. However, it was the command set(CMAKE_BUILD_TYPE Release) in the CMakeLists.txt, which was merged by git pull and overrode the CMake Settings while execution. I could not figure out earlier as CMake Debug console was showing -DCMAKE_BUILD_TYPE=Debug
When I changed it to set(CMAKE_BUILD_TYPE Debug) breakpoints were hit again.
In case this helps someone else:
In my case I had to set the -DCMAKE_BUILD_TYPE option to Debug explicitly in Settings -> Build, Execution, Deployment -> CMake
I had a different issue that caused my breakpoints not to be hit. I develop both embedded apps and native MacOS console apps with CLion. For the embedded work, GDB needs to be set for your selected Preferences/Toolchains.
For debugging console apps LLDB needs to be selected in Preferences/Toolchains. If it is left on GDB, my breakpoints don't work. Set to LLDB here:
I had a comma in my project path. Removing the comma fixed the problem for me.
In 2019.3, it turns out to be CLion/Preference/Build,Execution,Deployment/CMake/Build type/Debug.
My problem was with the -ffile-prefix-map flag. Once I removed it, everything worked fine.
See https://youtrack.jetbrains.com/issue/CPP-23159 and https://youtrack.jetbrains.com/issue/CPP-15850
I had the same issue. I noticed that every time I click the debug option, the "Antimalware Service Executable" process starts. I created an exclusion for MinGW folder in windows Defender and it worked fine...
Just like minecrawler said in github, if your os is linux, your should set：
file/Settings/Build,Execution,Deployment/Tllochains/Debugger from Bundled GEB or gdb to Bundled LLDB.
I tried and it worded！
In my case (Linux / Ubuntu) the problem was somehow related to mounted directory.
The project was initially opened in CLion from /media/username/ssd/repo/git/projectname. The breakpoints were always disabled with message No executable code is associated with this line.
Then I opened the same project from a symlinked directory
~/git -> /media/username/ssd/repo/git and the breakpoints began to work fine.
In my case I had to edit the file so that everything was compiled again instead of using cache.
In my case, the problem is forget to comment out optimize option add_definitions(-O3) in cmakelists. which let compiler go release.
in the case of "the platform is currently not connected" of CLION for RUST, it turns out there is an authorization step which is not enabled on CLION 2022.2 version.
download the correct version solves the problem
My UWP apps were running flawlessly on debug but instant crash on release, I've uploaded the package to app store twice and they tell me that my app doesn't work too. Unticking that .NET Native stuff helps but I'm not sure it will work on other users' pc and I have no idea what that does, I think something goes wrong.
My other projects can run Release build flawlessly, I've tried clean up everything and re-build but I get the same error.
Thank you
edit: tried running on my laptop, stuck at splashscreen then got the same error, I even tried removing anything on MainPage constructor and OnNavigatedTo.
Running flawlessly on debug but instant crash on release:
Unticking this helps:
I found the solution, I think this is a bug where Visual Studio passes command line to compiler which I suspect they forgot to put quote "" to cover the path.
Project with spaces in path
Project without spaces in path
Be aware that spaces must not exist neither in the path to the project file nor in the Assembly name.
Your app should be able to run on .NET Native because it will be compiled that way in the store (before users are able to install it).
Release builds do have code optimizations enabled, which will make it harder to debug. If you want to debug .NET Native, you should disable the optimizations.
For the full guide on debugging .NET Native, check the msdn article. I hope this helps in hunting down the actual problem (which can be plenty).
Using Qt Creator 3.0.1, Qt 5.2.1, MinGW 4.8 32bit on Windows 8.1 64bit, I am able to build an application but not run it.
When trying to debug the application (new clean project), the output tells me
This application failed to start because it could not find or load the
Qt platfor plugin "windows". Available platform plugins are: minimal,
offscreen. Reinstalling the application may fix this problem.
follow by a
Runtime Error!
Program C:\Qt\Qt5.2.1\test\debug\test.exe
This application requested the runtime to terminate in an unusual way
etc...
I tried adding the qwindows.dll's under my /debug/platforms/*.dll but no difference there.
Is my problem due to my Windows installation?
EDIT: After trying out #paulm's solution, putting the windows dll's inside plugins instead, nothing changes.
Dependancy Walker tells me that I miss
API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLL
API-MS-WIN-CORE-PRIVATEPROFILE-L1-1-1.DLL
API-MS-WIN-SERVICE-PRIVATE-L1-1-1.DLL
EDIT2
After adding these DLL's (had to download them from here) and seing I had to change the name of one of the DLL's I downloaded from this site, I now get the new error
This application failed to start because it could not find or load the
Qt platform plugin "windows".
Available platform plugins are: minimal, offscreen
And not the following runtime error.
Since I had to go to external sources to get the Microsoft DLL's, doesn't this really points to something faulty with the Windows 8.1 DLL's?
EDIT3:
To clarify, in my \platforms I have
qminimal.dll
qmoffscreen.dll
qwindows.dll
whilst in my \plugins I copied the same DLL's.
All required steps are described on this page of the documentation. Check especially the "plugandpaint" example under "Creating the application package".
My guess is that you are missing the second one:
myapp.exe
platform/qwindows.dll
Qt5Core.dll
Qt5Gui.dll
Qt5Widgets.dll
And yes, dependency management on Windows is a pain. It should be part of the OS, instead, it's not, and you have to take care of everything yourself.
I upgraded to xcode 5.0 today. I then pressed play to run my project in the iOS simulator. This initially worked. Then I decided that I wanted to run the profiler. When I did that, I got the message:
Xcode cannot run using the selected device.
Choose a destination with a supported architecture in order to run on this device.
I looked at a couple past posts on this problem and decided to do a Clean and Build. Now I can no longer run in the profiler or the simulator. I consistently get the message:
Xcode cannot run using the selected device.
Choose a destination with a supported architecture in order to run on this device.
How can I resolve this?
Here are various settings:
My Deployment Target is 6.1
I have also tried changing the deployment target to 7.0, but that did not work either
It appears that the problem is not related to the architecture in the build settings as the error might suggest. Rather, I found that the problem seems to be related to the Build Options Compiler for C/C++/Objective C. I was using a gcc compiler (com.apple.compilers.llvmgcc42) and Xcode 5 has marked this as unsupported.
If I change the compiler to apple's default Apple LLVM 5.0, the project builds and it can now run in the simulator. The downside is that I have a lot of compiler warnings from code related to cocos2D v1.0 source code. But, at least I have a way forward.
Please follow below step
1>Go to Project Build setting
2>Change compiler for c/c++/objective c as Default compiler(Apple LLVM 5.0) (see in below image)
I had to change compiler for Default compiler (Apple LLVM 5.0) at two places:
Build Settings > Build Options > Compiler for C/C++/Objective-C (change to LLVM)
Build Rules > Files *.mc using GCC (change to LLVM)
Hard to find because code compiles even if Build Rules point to an undefined compiler.
After inspecting all the build settings for 15 minutes, this worked for me (Xcode 5.0.2):
Quit and restart Xcode
Check that the Executable File (also known as CFBundleExecutable) in the Info.plist file is set to ${EXECUTABLE_NAME} as opposed to any hardcoded value. This will ensure that even if you change your project name or target name or scheme name, that it still works.
This issue often occurs after duplicating targets on older projects.
Set the following in your Info.plist for the target:
Bundle Name = ${PRODUCT_NAME}
Bundle Display Name = ${PRODUCT_NAME}
Executable file = ${EXECUTABLE_NAME}
Build and run with these settings, after a successful build they can be changed to anything you want.
This works for me: "Quit and restart Xcode". I recently updated something and the testing device on Xcode said: 'iDevice' not iPhone or iPod. So I restarted then my iPhone came back to the target list.
I had this error when I changed the value of the "Bundle name"-key in the Target Properties. Changing it back to "%{PRODUCT_NAME}" solved the problem for me.
I just started using Xcode to program a C++ openCV project.
The project is set up with an external makefile, /usr/bin/gnumake as build tool, and the program compiles and runs fine.
However, breakpoints gets skipped no matter what i do.
I have tried making a new project, selecting between gdb and LLDB, restarting Xcode++
There are numerous threads about this issue, but most talk about "Load Symbols Lazily", but as far as I know, this is not an issue in Xcode 4.5.2.
It is probably my limited Xcode knowledge that causes the error.
Help is greatly appreciated.
I could resolve my similar problem by disabling "Link-Time Optimization" for the Debug build settings.
Make sure that any kind of code optimization is disabled in your debug build settings (code stripping, optimization, etc). Then check that you really run the debug build and not the release version.
It would be great if XCode could automatically warn you when you have build settings that possible break the debugger...