Have you ever had to debug a Qt program running on a different computer?  There are a few special things that you must do in Qt Creator in order to properly get all of the debug information out from the device.

In my case, I’m debugging a Qt program running on an ARM processor, while debugging through my x86 computer.

First of all, you will need a root filesystem on your local computer that matches what is installed on your board.  See my guide on cross-compling Qt for ARM for information on how to use qemu-debootstrap to create a new rootfilesystem.  Alternatively, this should also work with any other filesystem that you create(e.g. through yocto).

Now that you have your root filesystem, here’s how to setup Qt Creator correctly:

1. (optional) install the qt sources.  On Debian, you can easily do this with:

   $ apt-get source qt5-default

2. (optional) Once you have the Qt sources, go to Tools -> Options -> Debugger and click ‘Add Qt sources’ at the bottom and add the source path for Qt.  The source path should be /var/tmp/qt-src, the target path should be the directory in which you executed the apt-get source line above, for example it may be /home/username/qt/qtbase-opensource-src-5.3.2+dfsg/src
3. Under Tools -> Options -> Debugger, go to the GDB tab and add these additional startup commands:

   set sysroot /path/to/rootfs
   set debug-file-directory /path/to/rootfs/usr/lib/debug

4. Install the debug symbols in your rootfs:

   $ sudo chroot /path/to/rootfs
   # apt-get install qtbase5-dbg

5. Go to Window -> Views -> Debugger log.  This will open up a new panel in Qt Creator that gives you the output from GDB.
6. Run the program with GDB through Qt Creator as you would normally.
7. When you hit a breakpoint or encounter an exception in the program, send the command ‘sharedlibrary’ to GDB.  This will load the shared libraries, but it will not update your stack trace immediately.  Either switch threads, or through the program for the stack trace to be updated in the GDB view.

You should now have a fully functioning remote debugging system.

I’d like to take a moment to talk to you today about sequel escalation.  In general, this is when the next movie in a series has an even worse bad guy than the previous one.

(This is not limited to only movies though)

I was thinking about this as I watched the Fast and Furious franchise, although this also happens in the new Bond films.  I know that it is in someways inevitable; after all, if the new bad guy was easier to defeat, that would make for a bit of a dull movie, right?  But that is in some ways the problem.  There can only be so many international terrorists and criminal masterminds.  Once you get rid of one of them, a new one does not magically appear.

There has to be some kind of limit here.

But that never seems to happen.

Anyway, just some random thoughts.

I don’t know anything about hacking.  It’s true.

I know the basic theory behind some of the attacks, but in-depth knowledge is beyond me.  I went to school for almost five years to learn how to program, and I can’t even tell you how to hack into a computer.

I like to think that the software that I write is immune to being hacked, but I don’t know for sure without having somebody else look for vulnerabilities.  At this point, if I were to try to hack something, I would be a script kiddie.  And that’s not something that you want to be.

At least there are a few guides on how to not become a script kiddie.

Alright, that’s a confusing title.

Anyway, the point of this is to show you how to setup Tomcat 8 on Debian 8 (Jessie), and to have it bind to port 80.  This uses just the default packages from Debian, so if you are using a version of Tomcat that you downloaded directly from their website you may be out of luck.

First, install the needed packages(note: this causes Tomcat to start automatically):

$ apt-get install tomcat8 authbind

Now, we need to change the configuration settings for Tomcat and authbind to make sure that they work properly.

1. Edit /etc/default/tomcat8.  At the very end, there should be a line that says AUTHBIND=no.  Change this to say AUTHBIND=yes
2. Edit /etc/tomcat8/server.xml.  In this file, there is an XML tag that starts out with <Connector port=”8080″ ….  Change this to be 80.  There are two sections that you want to change this.
3. Go to /etc/authbind/byport.  Do the following(note: this assumes that tomcat is running as the tomcat8 user, which it will do if you installed it through apt)

   $ cd /etc/authbind/byport
   $ touch 80
   $ chown tomcat8 80
   $ chmod 744 80
   

4. Restart Tomcat

   $ systemctl restart tomcat8
   

You should now be able to access Tomcat on port 80.

I had an interesting dream the other night.  In my dream, I was explaining to a person a dream that I had had two nights before.  Also, for some reason, we were standing on a bed.

It seemed very Inception-like, talking about a dream within a dream.  Once I woke up, I was also a little confused about how I remembered a previous dream in another dream, as generally your dreams don’t stay with you when you wake up.

Anyway, that was kinda interesting.  Just a random thought.

Have you ever had to use a QUdpSocket to send data from a specific port?  I had to do this earlier, and I figured out how to do it(although not using Qt-only APIs).

My problem was as follows: I need to be able to receive on a specific port.  The device that I am talking to listens on this port and then responds back on that same port, no matter what my source port is.  So to keep things clean, I figured that it would be best to use just one single socket to send and receive data packets.

The general consensus that I saw after searching Google was that it is not possible to do this.  It is possible, but it doesn’t seem possible using Qt-only APIs.  I knew that it was possible, as I have done this before.  This is the code that I came up with:

    int optval = 1;
    int fd;
    struct sockaddr_in socket_config;

    memset( &socket_config, 0, sizeof( struct sockaddr_in ) );

    fd = socket( AF_INET, SOCK_DGRAM, 0 );
    if( fd < 0 ){
        // error handling goes here
    }

    socket_config.sin_port = htons( port );
    if( bind( fd, (struct sockaddr*)&socket_config, sizeof( struct sockaddr_in ) ) < 0 ){
        // error handling goes here
    }

    if( setsockopt( fd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof( optval ) ) < 0 ){ // error handling goes here } 

    udp_socket = new QUdpSocket(); 
    udp_socket->setSocketDescriptor( fd );

This allows us to still re-use the proper port, but use the socket in a Qt-like way.

So I just spent the last few hours attempting to get Java RMI working.  This was not easy.  However, the good news is that now you can benefit from it!  Link at the end, but first my story…

Last night, I was wondering how you would connect two Java applications together.  The reason for this is because I want to try and have an embedded Tomcat server inside of an application, but also have the capability of developing the webapp separately, since developing both the embedded server and the webapp in the same project did not seem to work very well.  I figured that I could use something like DBus-Java to do this, however I wanted it easily cross-platform.

As it turns out, Java already has something like that built-in!  In the form of RMI, or Remote Method Invocation.  However, the example that they give in the Java Tutorials is not particularly clear.  It also seems to be out of date, although if it actually is I am not sure.  There are several important parts that the tutorial does not go over.  Other documentation talking about what you need to do does not appear to be up to date either, much if it appears to date from Java 6 and before.

Since this was such a hard thing to figure out, I’ve made a standalone Maven project that goes and sets up an RMI client and server.  Hopefully it will help somebody else in the future.

Check out the code on GitHub!

A moo-tiny.

*ba-dum tissh*