One Of Those Days
(Posted on behalf of Pardis Beikzadeh)
<>As I’ve heard after talking to my friends and colleagues, it often happens in the life of a programmer that they come across a bug somewhere least expected and they spend big amounts of time trying to find it and fix it. It once happened to me at god knows how many hours past midnight in my first year in university of Toronto. For the first time in our academic career we were given someone else’s code and were asked to fix it. I remember how everyone hated that assignment wholeheartedly. After hours of going through their code I figured if I set the value of some flag called blahlblah to something it fixes the problems. Although, after a few hours of trying to figure out why it wasn’t in fact fixing the problems I was still as lost as ever. I remember my last desperate attempt to fix the error was that I copied the line where they were setting the value of the variable and pasted it where I wanted and then changed the value to what I wanted. To my surprise it fixed my problem. So it turns out if I was using a different font I would have realized that the variable name was in fact blah1blah and not blahlblah.Today I spent my whole day trying to fix an error in UTest and was getting more and more frustrated. I still don’t know why it happened but at least now I have a lot of information about the conditions under which it happens. UTest wants the user to upload their code as a tar ball, so I created some simple Java file and made it into a tar ball and always used the same tar ball to run the program to see how it runs in the GUI. However yesterday afternoon I realized that after I give Utest my tar ball it goes into oblivion and never comes back with any sort of error or non error message. So I spent most of my day today figuring out which bit of code I changed that caused this malfunction in the program.
First I used Eclipse to compare the files that were different on my local machine to the last revision from repository. Most of the differences where print statements here and there that I had added to help me see keep track of the flow of data in code, and the ones that were more than a simple print statement I commented out. Yet the problem persisted. So I rolled back to the revision from repository. Still the problem wasn’t fixed. So I started running second part of Utest on my local computer instead of the virtual machine that I use as a sandbox environment. This did not provide me with any more error messages to my disappointment and did not change anything with respect to the problem. I deleted and recreated all the files and folders needed by Utest to run just to realize that they had no effect on the problem either. At this point I was very frustrated and angry. Again as a last desperate attempt I used another tar ball that I had made for a different part of the program. To my surprise the program responded. Even though this tar ball did not contain a normal Java class file and contained a junit class file, the program worked and all it did was complain about compile errors it had come across while trying to compile the JUnit file.
I was one step closer to solving the problem. Although I still couldn’t understand why one of the tar balls worked and the other one didn’t. As far as the program was concerned I needed a tar ball with some Java files in it. After trying to open the tar ball and the Java file inside it by hand I got complaints from the editor saying that it cannot recognize the encoding of the file. It turns out sometime during creating the tar ball I typed
tar -cvvf A1.java a1solutions.tar. Happy that I had found the problem I rewrote a small Java class and saved it in
A1.java that was still open in Eclipse thinking that I overwrote the previous bad file. After seeing that this did not fix my problem I decided to compare the two tar files in all aspects.
ls -l showed that
A1.java was 10250 bytes whereas the other Java file that I put in my other tar ball was only about 250 bytes. Apparently editing an open file is no good way of overwriting it. So I deleted the file and created a whole new file with the contents that I wanted and voila—problem solved.
Now I’m trying to understand why this happened. Greg and Martin and I all think that if a Java file contains non-ASCII characters the Java compiler should come back with an error the same way that it comes back with errors if I type in code with bad syntax. Like I said earlier the program does work in such cases. It prints the compiler errors to the browser used by the user. However it should behave in a different way if there are non-ASCII characters in the file because it causes my program to behave differently. I tried getting the same effect again. So I used tar to create a tar file and then renamed it to a .java file. To my disappointment Utests didn’t stop responding, instead it crashed with an error that was obviously caused because the previous part of the program hadn’t completed the way it should have. Another
ls -l showed that the new Java file wasn’t as big as the old one that cause my program to stop responding. So I confirmed that my problem was a mixture of having non-ASCII characters and having a big file. The weird part is that no matter how big the file, if I compile it outside of my program the compiler does come back with some error messages instead of just sitting there. The weirder part is that I added a
> /tmp/errlog to the end of the Ant command that ran
javac on the Java files given in Utest source and now even if I use bad Java files with non ASCII characters in them or big bad Java files the program doesn’t crash and it comes back with compiler errors just like it does in case of bad syntax!
I will dig in for more symptoms and write more on the subject if I figured out what exactly caused it.