I have been trying for days to debug into the c code of the sample hello-jni, with no success. I have installed all the requirements and followed many blog posts (repeating the process each time) to try to get this working.
I am using
Windows 7 64bit
Eclipse Juno with CDT 8.0.2
Android NDK r8b
Android SDK 20.0.3
the latest cygwin with make, gcc-core and gcc-g++ installed (altho I think NDK r8b doesn't need this?)
I have followed this
http://developer.android.com/tools/sdk/ndk/index.html
to set up and build the apk. It builds and installs fine and I can debug java code if launched as an Android Application
I followed this article about the NDK plugin
http://tools.android.com/recent/usingthendkplugin
but when launching as an Android Native Application with a breakpoint in the c code, the app launches and runs as normal with no breakpoint being hit and no error messages!
Any help would be greatly appreciated.
Thanks!
EDIT:
Here's some errors that appear in the console for half a second before being cleared
warning: while parsing target library list (at line 2): No segment defined for /system/bin/linker
warning: Could not load shared library symbols for 52 libraries, e.g. /system/bin/linker.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.
Quit (expect signal SIGINT when the program is resumed)
Turns out the above guides I used were all I needed and everything was working.
The warning messages were just... warnings and so debugging of the native code worked all along.
My problem was the native function call where I had my breakpoint was being called immediately - before the gdb could attach. I put the JNI function call into an onClick and found my breakpoint was being hit after all.
I hope the above links and this answer can help someone.
Thanks...
According to NDK documentation..
"At the moment 'ndk-gdb' requires a Unix shell to run. This means that
Cygwin is required to run it on Windows. We hope to get rid of this
limitation in a future NDK release."
JeffG are you able to debug native code on windows without cygwin?
Related
I am trying to make a C++ application with wxWidgets for raspberry on Visual studio.
I created a blink project from the templates and I only added the library wx.h in order to test the code and when I try to compile it fails because it doesn't find the library.
By the way, the blink project itself works fine. It only fails when I add the wx.h library.
#include <wx-3.1\wx\wx.h>
It's odd, because whe I open the file it has the right path.
Even intellisense detects the path correctly.
But I can't figure out what is causing the error.
I configured a remote connection to the raspberry:
And these are the errors displayed:
There is not enough information to answer your question, e.g. you don't explain how do you build your project at all (e.g. do you use CMake?), but a couple of observations that may be helpful:
wxWidgets headers are included as <wx/wx.h>, you definitely should not have the wx-3.1 component and you must use slashes and not backslashes.
You have to provide the compiler with the appropriate options, which usually happens by running wx-config --cxxflags under Unix systems (which may be hidden from you if you use CMake FindwxWidgets module which uses wx-config internally).
we made one application on Visual Studio 2008 , it about to release. but now we are getting the crash while launching the application . could you please any give a suggestion how do i debug on this particular issue
You can run the Release build in the debugger, too. Turn on debug-info settings in both the compiler and linker tabs (I think that was not the default in vs2008 and there were two distinct places to set) but don't change any optimization options or other setting.
Then launch the program from the debugger. If the resulting EXE shows the crash when run normally but not when started via the debugger, there are more things to make the situations work the same (and that shows clues as to what is wrong, too). So let us know if that still doesn't reproduce.
There could be a lot of reasons for your application's Release is crashing.
Did you link proper Release libraries with your application in Visual Studio project configuration ?
Check your code for some missing Release specific code.
My best guess is you are not linking to proper libraries for the Release version of your application.
Also, one reason could be that your application may be trying to load some file that may not exist. This happens with me sometimes when my Release build of application does not find file that it needs (Eg: OpenGL application trying to load a shader file that is missing); and you don't check for errors.
I am trying to write some mex code but it is painful to debug it on the console with gbd. Is it possible to use Eclipse or the GUI of Matlab? If these are not feasible methods, what is the best way of writing mex code that provides good debug capabilities?
Debugging C/C++ MEX files in gdb is already comprehensively covered in the official documentation, so my suggestion is to try and integrate gdb with Eclipse CDT.
There's plenty of information out there about how to do it properly, so I'm not going to repeat everything here. The best tutorial I know is IBM's two-part guide, "Interfacing with the CDT debugger":
Part 1: Understand the C/C++ debugger interface - covers the high-level basics.
Part 2: Accessing gdb with the Eclipse CDT and MI - explains how to make Eclipse work with gdb.
I think part 2 is what you really need. Basically, you have to install a plug-in and configure it in Eclipse.
There are also quite a few related questions about this even here on StackOverflow:
How do I use GDB in Eclipse for C/C++ Debugging?
How to install GDB debugger to Eclipse CDT
Debugging with Eclipse CDT and GDB
How can I enter commands to a gdb prompt while debugging with Eclipse CDT?
I haven't tried it out yet, so I hope this works.
On Windows platform:
The best way (to my experience) to debug a mex code is to use Visual studio.
Here's a link on how to do it.
Other platforms (Linux/Mac):
I'm afraid I haven't find any good way to do so apart from gdb (which is not fun at all).
Update (2018):
Recently, Mathworks released a blog post describing how to use Visual Studio Code to debug mex code.
I haven't tried it myself, but it seems like a nice cross-platform solution for debugging mex files.
Here is my solution which works in Ubuntu 12.04, Matlab R2012b, and Eclipse IDE for C/C++ Developers Kepler Release.
In Eclipse open "Debug Configurations" from the run tab. Then make a new "C/C++ Application".
In the "Main"-tab write the correct path to the matlab executable in the "C/C++ Application" (mine is "/usr/local/MATLAB/R2012b/bin/glnxa64/MATLAB" NOTE: not MATLABPATH/bin/matlab).
In the "Arguments"-tab add "-nojvm" as program arguments.
In the "Environment"-tab add variable "MATLAB_DEBUG" with value "gdb"
Press "Apply" and "Debug"
A "Matlab console" will open in the "Console" view.
Write "dbmex on" in this console. This enables debugging.
Run the mex file! (Matlab will stop at loading of each new mex file)
Have fun debugging! :-)
I wanted to write c++ desktop application with fine UI, so I did it in QT Creator.
Then I decided to add some UI features, and I moved to QML(QT Quick Application).
I installed QML Desktop Components according to here instructions, used import Qt.labs.components 0.1 and it worked well.but now I have to deploy my application, and I noticed that the application runs only on Debug mode, and not on Release mode. I checked, and saw that I have just the styleplugind.dll, and not the styleplugin.dll. Shortly, I have only the debug dll, and not the release one. I installed the components again,for release, and I really got the styleplugin.dll. but when I'm running my application(I remembered adding CONFIG+=release to my .pro file),I'm getting this error:
loaded for module "Qt.labs.components": The plugin 'C:/QtSDK/Desktop/Qt/4.7.4/mingw/imports/Qt/labs/components/plugin/styleplugin.dll' uses incompatible Qt library. Expected build key "Windows mingw release full-config", got "Windows mingw debug full-config"
import Qt.labs.components 0.1
^
I don't understand why I'm getting that: I have the right .dll file, and everything seems okay.
(BTW, I'm on Windows7)
What should I do??
The problem is, as the error output states, that your styleplugin.dll is still build against an incompatible Qt build (debug, expected is release).
I have a Visual C++ 6 project that is creating a COM DLL. This is an old project that I have not used in years but I came back to it recently to update some functionality of the DLL. The issue I am having is that when I try to manually register the DLL (using regsvr32) that is created by the project, I get no response whatsoever. It does not say it succeeds and it does not say it fails. I have verified that the DLL is not being added to the registry. I have never seen a situation with regsvr32 when it would not show any confirmation message.
Also, the DLL is set to self-register in the project and when it attempts to do this, it also does not show a message.
I have not touched this project in a long time, but the last time I did touch it, it worked without issue. Now I come back to it, and all of the sudden I am having this problem. It is as if the DLL being created by the Visual C++ project is not compatible with the current version of Windows. I have updated the development software to SP6 but it has not changed the situation.
I ran Depends on regsvr32 when it was pointing to the created DLL, and it shows this message:
LoadLibraryExW("C:\Source32\BIS\Projects\ALFA\DigiPixSvc\DigiPixObj\Debug\DigiPixObj", 0x00000000, LOAD_WITH_ALTERED_SEARCH_PATH) returned NULL. Error: The operating system cannot run %1 (182).
Can anyone please tell me why this is happening and what I can do to correct it?
Disclaimer: since I don't have VS 6.0 installed anymore, I'll have to use some Google searches to give you the exact steps for the VC 6.0 dialogs - so some of this information may be inaccurate. I believe it's correct - it's really what you'd do in the current IDE, just for VC 6.0.
Before you go through the trouble of debugging your DLL, make sure you run it through Dependency Walker to verify that all your dependencies are on your machine. Don't run Dependency Walker on regsvr32 - what matters is whether your DLL has its dependencies. If they're missing, regsvr32 won't be able to load the DLL.
To see if your DLL is getting loaded by regsvr32 when you try to register it, you need to debug through the DLLRegisterServer() function and see what happens there - this is one of the 4 entry points a COM DLL must have and regsvr32 calls this function when the DLL is about to be registered. In order to do this, you'll have to set regsvr32 as the startup program of your project and pass the full path to your debug-built DLL as a command-line parameter to regsvr32.
Bring up Project Properties for your project.
Go to the Debug tab.
Make sure the General category is selected.
Enter the full path to regsvr32 in the Executable for debug session textbox.
Enter the full path to the debug version of your DLL in the Program arguments textbox. Make sure you have a PDB file for your DLL so you can see symbol information during debugging.
Put a breakpoint on the first line in DLLRegisterServer(). The code in this function may be long or short, depending on how it was created: generated by a wizard, written by a developer, etc.
Start debugging.
Your breakpoint should be hit and you should be able to step through the registration code and see at which point it fails.