I can't get debugging to work.
I'm using the 2.1.0 version of REDHAWK and I'm trying to create custom components.
I can get release version to run and to work.
Here's what I do, I have created a very basic custom component that takes input, multiplies it by two and pushes it to the output stream, super simple. Now I try to run this component in debug mode in sandbox, instant crash. The only this I can see is the last entry of the callstack, which is
boost::shared_ptr<rh_logger::Logger>::operator->() at shared_ptr.hpp:653
If I choose to run my component without debugging, everything works. It even does the multiplication.
I have no idea what goes on, apparently this smart pointer class does a assert check to validate the pointer that it returns and ends up crashing because it's zero. Being the -> operator, this seems quite dangerous. SIGSEGV is the error being throw, I wonder if BOOST_ASSERT causes that on failure?
Operating system is CentOS 7 64 bit and it's running on regular desktop intel processor, can't remember which.
I installed REDHAWK by downloading the repository as instructed in 2.2 part of the REDHAWK manual.
The new component was created with the REDHAWK IDE (eclipse based), I selected C++ as the Program language. It seems to be a shared library and when I run it, a process called ComponentHost is started.
I'm trying to start the component in the sandbox via right-clicking the component in the Project menu and selecting Debug as - Component in the Sandbox. Running the component in the Release mode this way works.
I'm able to debug a component via the Python sandbox, so just a couple of variables to help narrow it down, with my test system in []:
Which operating system? [CentOS 7]
REDHAWK installed from source or RPM? [RPM]
Is this a new C++ shared library-based component (entry point type is "SharedLibrary") or executable ("Executable")? [both]
How are you launching the component? Via the Python sandbox, with with "debugger='gdb'" as an argument to launch? Any other launch arguments?
Another possible debugging approach is to launch the component normally, then attach GDB from another terminal window.
First, find the component process:
If it's a shared library:
ps -o pid,comm -C ComponentHost
If it's an executable (where "" is the component executable's name):
ps -o pid,cmd -C <name>
Hopefully, it's clear which process is your target component. If you're running multiple shared library components from the same sandbox, they will all be part of the same ComponentHost instance.
Then, attach to the process with GDB:
gdb -p <pid>
This is essentially how the sandbox attaches GDB; however, running it independently allows you to set the flow up to your liking first before attaching the debugger.
Related
After getting out of a mode of procastinating, I've finally gotten to the item on the projects todo-list that says "Run on virtual device to see why it crashes".
My project is a libgdx application that I plan on porting to various platforms, the two most important ones being desktop and android.
During development I've exclusively used the desktop launcher, as it's a lot easier to fire up when just checking minor things.
I did build an .apk at one point just to see if it'd run out of the box, but it didn't. Now that I've tried via the virtual device, this is what the log says:
com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load file: rifleman.png
The same goes for any other assets that my game uses. The files are all placed in projectname/android/assets, as I remember learning way back that this was the way to go.
The virtual device I tried with is the stock Nexus 5, but I tried running the .apk by uploading it to my actual phone with a crash right after start, and I assume the problem is the same and is therefore unrelated to the test-platform.
I am currently not using an assetmanager, as implementing this is scheduled for after getting the basic core mechanics up and running. In the mean time I'm loading them as such: new Pixmap(new FileHandle("rifleman.png"));
Using android-studio 2.2 on Linux Mint 17 Cinnamon.
Please comment if more info is needed.
Use Gdx.files.internal() instead of FileHandle().
From filehandle(string) method info
Creates a new absolute FileHandle for the file name. Use this for
tools on the desktop that don't need any of the backends.
Do not use this constructor in case you write something cross-platform.
This may be a noob question, but I have been stuck trying to work out how to statically build my qt project on linux. I tried doing what it said on http://doc.qt.io/qt-5/linux-deployment.html , but I do not understand the 1st step. When I cd to the location of my qt project and run
cd /path/to/Qt
./configure -static -prefix /path/to/Qt <otherparameters>
make
it says no such file or directory. Am I misunderstanding what paths I need to use? I want to make my qt project a stand alone executable which doesnt require the computer it is on to have qt. I have read about dynamically linking the libraries, but I dont really know what to do with that either. The deploy option is greyed out in qtcreator, is there a way to use this?
Thanks
/path/to/Qt should be the path to Qt's sources, not your project's. That section of the documentation is about building Qt statically, which you must do before trying to statically link your application to Qt. For example, if you downloaded/cloned the sources to /home/jxb458/qt5, then you'd replace /path/to/Qt with that:
cd /home/jxb458/qt5
./configure -static -prefix /home/jxb458/qt5/qtbase
make
Static linking is great when it works, but it can be an effort - I have found especially when using GUI. As Mitch said you need to actually re-build the Qt source code
I made some notes back when I was building statically quite a bit here: Notes on static building (derived from many sources) they should at least point you in the right direction - you can probably ignore the part about installing Ubuntu - the notes assume a new install.
However I have more recently returned to the dynamic linking deployment since I feel this is a better way to deploy now. You don't need to install Qt on the target machine you just need to collect the qt dlls and copy them with your application (using ldd executable-name which produces a list of dlls you need - but just take the Qt ones not the system/generic ones). For plugins you need to do a bit more (but its fairly simple). I even wrote a bash script to do this automatically (i'll send it to you if you need it), in windows there is a qt script called windeployqt (not sure why there is not a linux variant).
If I where to start again looking into deployment I would go for dynamic linking. Maybe try with a simple project to start with (like a hello world proj).
I'm trying to create a Linux application to run on my Zynq7020. However I don't understand how the Xilinx SDK generate the executable file.
When I create a hello world, for instance, it creates one .elf file and under the debug it creates one object (.o) and one dependency (.d). I want to run it under the Linux that is running on my board, how do I do it?
Thank you very much.
I want to run it under the Linux that is running on my board, how do I do it?
Most likely, you just need to copy/download the .elf file to your target board and run it.
If that doesn't work, try editing your question to supply more info. In particular, what commands "create a hello world" actually executes?
When creating the project in the Xilinx SDK, select that it runs on linux rather than standalone. See this official tutorial for an in-depth explanation.
When I try to use the AudioSink component design by Axios which can be downloaded from: https://github.com/Axios-Engineering/audio-components
and used as a component is not working outside of the sandbox chalkboard.
I created a SCA Waveform Project with the AudioSink as a component and when I try to launch it with the Device Manager it doesn't launch it because it can't initiate an instance of the AudioSink component.
You can create a simple waveform using 2 components: AudioTestSource and connect this one to the AudioSink and it will not let the Device manager launch the component.
Some help please.
I have tested the components running within the DomainManager in the manner you suggested and they work for me. It will be difficult to isolate the problem without some additional information about your system and the errors you are experiencing.
Here are a few things to check first.
Have you installed the components into the SDRROOT? This can be done by either dragging
the component project in the IDE over to the Target SDR or by running "make install" in
the components folder. You can confirm that they have been installed to doing ls
$SDRROOT\dom\components. In that folder you should see AudioTestSource and AudioSink.
When you attempt to launch the waveform; can you provide the error printout that the
DomainMananger and DeviceManager produced?
I have developed a Java ME application for CLDC platform. It works fine when executed in an emulator. But when i deploy it to my N70 phone the application doesn't start at all in the phone. In my application there are some 14 classes and am creating an instance of each and putting them in the vector on application start. The classes just have one variable and 2 methods. Can this creating of lot of instances be the reason for its crashing?
Is there any way I can find out the reason why the application is not able to start in the phone?
Update:
Its running fine on emulator. And one more thing I would like to mention is that- The code stops executing only at the point where am creating those 14 instances and adding them to the vector. Till that point the code executes fine.
It might depend on where in the code you are creating those instances. If you are creating them in your MIDlet constructor or the startApp method try moving the initialization into the run method of your application.
One way of debugging J2ME applications that don't start on the phone is by adding "printf" style debug messages in your code to be written in the record store system and adding another MIDlet to your application to read from RMS and display those messages.
Or you could just comment bits of code and see if it works.
You can debug on device. If the emulator you are using is part of the Nokia SDK then there should be facilities elsewhere to carry out on-device testing and debugging. (I'd post more detail on this but I've only done this with Sony Ericsson phones recently.)
Another option is to use the Nokia tools that allow you to view the standard output and error for your application when it is running on your device (via Bluetooth for example).
The probability that your application is actually crashing the Java Virtual Machine bytecode interpreter thread and terminating the whole native process is very small.
It has happened before but you need to eliminate several other potential issues before being convinced of an actual crash.
It is more likely that either:
Your MIDlet is not created or not started because the MIDP runtime decides it is not correct.
or
Your MIDlet simply throws an exception that you don't catch, which can make it look like it was brutally terminated.
Since the MIDlet installer is supposed to prevent you from installing a bad MIDlet, the uncaught exception issue is more likely.
How to find an uncaught exception:
Start with the simplest HelloWorld MIDlet, using a Form so you can easily insert more StringItems at the top of the screen.
Create and start a new Thread in MIDlet.startApp()
In your override of Thread.run(), add a try{}catch(Throwable){} block.
Inside that block, do whatever your original MIDlet did.
Use the form as your standard output for debugging.
You can use Form logging to make sure you don't enter an infinite loop, to display exception classes and messages, to flag logical milestones, to display variable values...
That's the first step to figuring out what is going on.
I also faced a similar problem and when I recompiled my MIDLET as Midlet 1.0 then it worked fine. It seems like N70 is not able to run the new version of MIDLET. I think you downgrade and re-test your midlet.
Regards
Junaid