Time-Shift: Veritas liberabit vos
The truth shall set you free

Posts Tagged ‘C++’

Fixing bugs the right way: Be a scientist

Thursday, April 9th, 2015

So lately a though started to form in my mind that has been there for quite some time but due to environment has become more and more dominant in my head. A lot of times when I see people dealing with bugs, their first reaction is “This can’t be a problem with my code!”. Though understandable to some point, this is of course bad for the project (and for the team moral). Before long you have bugs floating from one to another, being closed, reopened again and start that nasty circle all over. Most of you will probably know what kind of bugs I’m talking about. So what to do about this? The answer is simple: Be what most of you have been trained to be! Be a scientist! I’ve come about this very intriguing graphic a few days ago:



Though technically oriented towards medical students this pictures pretty clearly what evidence you can trust easily and what might be a bit fishy. The first thing that catches the eye is that expert opinions are lowest in the list of trustworthy evidence. In other words: The phrase “This can’t be a problem with my code!” said by no matter how much of an expert is basically worthless when it comes to fixing bugs using the scientific approach. Event a hint where the problem may lay is to be regarded as such.. a hint and no more. Especially if you tell yourself that you can not be the origin of that bug always remind yourself that you can’t be sure unless proven right.

The next step on the list is an experimental approach. This is what you’ll see most in code debugging and bug hunting. Changing values or code and see how it reacts to that changes and then extrapolate from that reaction. Though most people would guess this to be a good approach it really is not. Because this way all you get is more data and most of the times more puzzles instead of solutions.There are a million things that can go wrong using this approach. The code might be time critical and only fail if run without stopping by the debugger. Values might be different using a debugging approach. And last but not least: you might simply run your debugging code on different hardware then the real thing.

The next three steps are basically only good for data collection and finding clues as to where the bug may lay. Sometimes this gives you a really good insight and helps you track the problem faster. But normally this would be the job of the QA department. They are responsible to find a way to reproduce the bug and include that report in their bug report. In 90% of the cases we will be writing deterministic software. Meaning: even if we use some kind of weak random generation using predefined seed, the software will always behave the same way when run on the same hardware and giving the same input. If it doesn’t (and believe me thats really hard to prove) then your hardware is broken. So as long as you have not proven your hardware broken and you are sure your program is deterministic, there is always a way to find reproduction steps. And once you have those you’re on a good path.

Which leaves the last two possibilities. The first one being randomized tests (which is might or might not be possible depending on your software and the way you input data) and the last one being a scientific approached review of the code.

Randomized tests are a good subject to be done automatically by your build servers. They can find bugs and you’ll always have the input data that generated those bugs (which makes finding reproduction steps pretty easy). Depending on your program this might be pretty hard to achieve, however you should at least plan in some automated testing before you even begin to write code. In an optimum case you even have the whole continuous deployment pipeline ready to use before you even start to write a single class.

After you’ve done all this and moved through all the fact finding steps you should have a pretty fair idea where your bug is hiding. If not. Start from the beginning. After all: science means that you are looking for the truth and not “your idea of the truth”. So don’t start bug hunting trying to prove it is not your code that is broken. Start bug hunting trying to prove what code is broken. If it turns out it wasn’t your stuff, all the better. Comment the bug and send it along to the code owner. And if it turned out that you did some really bad stuff: Thank god you found it. Every truth is god. And if you learn from your (or from others) mistake it will not happen again.

So once you have all the information and know where to look, start reviewing your code. I like to do this by stepping through it with a debugger and look at what I’ve really got. More often then not the data I see is not what I expected and I can find the problem really quickly. Sometimes its hard to track where that data is coming from. But at least now you know whats causing the symptoms. If you have proven that its not your code that causes the problem, but the data that comes in from somewhere else, its ok to collect all the infos in the bug report and pass it on to the person you think knows that code the best. After all he might be able to given an expert opinion :-P.

Bachelor Thesis online

Monday, August 29th, 2011

Since I’ve got my Bachelor diploma I’ve released my bachelor thesis and the practical solution as binary and source code here. Please be aware that the source code is released under GPL, but the written thesis may only be used for personal education. If you want to publish my thesis in any way please contact me first. The thesis handles displacement mapping in Direct X 11 using hull and domain shader. It makes use of almost every new Direct X 11 feature (Tessellation, Compute Shader). If you have any questions concerning my work please don’t hesitate to contact me or leave a comment. I’ll be happy to explain or help with you work if I can.

Tessellation Demo

Tessellation Demo

Tessellation Demo low tessellation

Tessellation Demo low tessellation

Tessellation Demo wireframe mode

Tessellation Demo wireframe mode

Tessellation Demo low tessellation wireframe

Tessellation Demo low tessellation wireframe

To Game or not to Game

Monday, May 9th, 2011

Finally my childhood dream has come true. I’m a professional game developer ;). Ok… ok I’m a game development intern… but hey.. I’m going there step by step. My first week as intern at EA Phenomic has come and passed and I’m loving every second of it. I can now do what every (crazy) child is dreaming of. I create the games that we love so much and have so much fun playing. What better job there is ;)?

Making Games Talents and beyond

Sunday, October 17th, 2010

Yesterday I “Making Games Talents” finally was held in my area (at least near enough to attend it) and the company set that was presenting itself contained all the company’s I ever wanted to work for: Related Designs, Crytek and Spellbound. First of all I’d like to thank Game Star (and IDG) and especially Heiko Klinge for making this event possible. It means a lot to us crazy devs, designers and artists to have the possibility to actually shake some hands instead of just writing one application after another and get ignored. This way we can show the company’s why we matter and why we stick out of the crowd. It was a quite rainy day yesterday and the first hard thing was to find the place ;o). Honestly guys.. next time a better description would be nice (or was this the first test?). However during my search I met some people who where also looking for the right place and so we made a team effort out of it. We sticked together for a while and met again later on. What will become out of this group is uncertain, but we exchanged e-mail addresses and you might here from us again (On this blog or maybe even on a bigger scale) ;o).  I first attended some lectures. After that I tried to get started with shaking hands. Getting to someone wasn’t really the easy part. Because the company’s like Crytek, Related Designs and Spellbound where all but overrun. I took my place in the line and finally had the chance to shake the hand of the CEO from Related Designs (if that isn’t already something ;o) ). Sadly though they don’t have a position open for a junior programmer at the moment. He took my portfolio and wrote some infos down. To bad. I’d really enjoyed working for them! The Crytek booth was badly crowded, but I tried my luck. When I was finally in front of the booth I met Cortney. He’s talent manager at Crytek. He took the time to look at the game I developed together with the GDIG at FH-Trier and listen to my explanations. I found him to be quite patient and friendly (considering what he had to all day). Last but not least I went to the Spellbound booth to present my case. They also where very patient (considering my notebook crashed before I could start the game and they had to wait on it for quite some time) and especially very friendly. All in all my hopes have somewhat risen (concerning GamesCom they have rocketed). Now comes the hardest part: wait and see. In the meantime I’ll look for more opportunities to get into the gaming industry. Keep your thumbs crossed!

KWatchman – An Idea given Birth

Tuesday, October 12th, 2010

First of all: Thank you everyone for you comments and suggestions. They really got me on the road and showed my that there indeed is interest enough to do some more serious work. So I sat down and made myself a little planing and even some (small) coding today. Here’s what I got so far:

The project will consist of mainly 3 Parts:

  1. Part one being the kwatchman-service (in what manner I’ll realize this I’m not sure yet). Its basically just an empty rack to manage and run part 2 (maybe this will even be a daemon so it can run under higher privileges).
  2. Part two being Plug-ins that can be loaded by kwatchman-service. There will be (for now) 4 kinds of Plug-ins:
    • Sensor Plug-ins (they collect the data from a specific source e.g. libsensors-plugin, hddtemp-plugin, nvclock-plugin, etc.. )
    • Interface Plug-ins (they provide interfaces for all apps that like to access the collected data e.g. dbus-plugin, network-plugin, nagios-plugin?, etc… )
    • Database Plug-ins (they provide storage for long term data collection e.g. mysql-plugin, postgresql-plugin, nepomuk-plugin?, etc… )
    • Alert Plug-ins (they do something in case an alert is issued by crossing some threshold e.g. knotify-plugin, phonon-lugin, log-plugin, shell-plugin, etc… )

Apart from the database Plug-ins all Plug-ins can be used or not used at will. So the user can ultimately decide what gets refresh and which alert is being send if a threshold is crossed. Concerning the Database Plug-ins I guess its much easier if only one is allowed at a time. All other use cases can be handled by Interface Plug-ins (e.g. if you want nepomuk as your db but want to access the data via php on a webserver a php friendly interface Plug-in would be the solution).

  1. The last part are GUI’s that access the data and configure the Plug-ins via the interface Plug-ins. Those can be a very wide variety of apps and applets ( e.g. native KDE4 apps, plasmoids, KCModules etc.). Im not completely sure how the initial configuration of the service should be made so that at least the correct interface Plug-in for your favorite App is activated.

The first implementation will (most likely) contain:

  • The kwatchman-service (whatever it will be)
  • A lm_sensors sensor Plug-in
  • A nepomuk or MySQL database Plug-in (not sure yet)
  • A native (ksensors like) KDE4 app
  • A interface Plug-in for the native app (maybe via dbus?)
  • A knotify Alert Plug-in

As soon as I’ve got those components in working order I’ll concentrate on more sensors and Alert Plug-ins. After I that database Plug-ins will be my attention and finally I’ll write some more apps and Interface Plug-ins.

As for now I’ve got a (very rudimentary) cmake concept for detecting libs and deciding what gets compiled, a (also rudimentary) file structure for the code and some template for the KDE4 App.

So.. now to it: What do you think about THAT concept? Crazy? To big? Super? If you have any supplementary suggestions to the concept don’t hesitate to comment!

The King is dead, long live the king!

Monday, October 11th, 2010

Have you ever wondered what became out of KSensors? I did. Many times. Well the sad but inevitable fact is: its dead :-(. And as far as I can tell there are no real successors standing in the doorstep. All the sensor apps available for KDE4 are hardly replacements. Most of them are plasmoids and I’d rather consider them toys then the real deal. Because of this I decided to bring in KWatchman (hope the name isn’t taken. Couldn’t find anything though). Essentially KWatchman aims to be a full replacement for KSensors. Showing sensor data on a dashboard, in KDE4 sys tray and ringing “the bell” if something is wrong. As of now the only thing that exists for this project is the idea, an (empty) git repository (http://gitorious.org/watchman) and an (mostly empty) IRC channel (#kwatchman @ freenode ). Before I begin on writing any code however I’d like to ask YOU about this ;-). So: What do you think about this idea and more important what do you think should be changed / made better as with KSensors? As this will not be a fork of KSensors but a complete rewrite I’d like to hear any Idea about this. Just drop me an E-Mail, write me in IRC or post a comment to this blog entry. I’m happy about any comment. Thx.

Are we there yet?

Thursday, August 12th, 2010

What I hear a lot from users lately if I’m talking about my current projects for Amarok: “Are we there yet?”. I’m mainly working on three things at the moment: A spectrum analyzer applet, a visualization applet and song fingerprinting. Today I’m happy I can say to at least one of this projects (and maybe even a second one) the answer is: “YES we are!”. I’ve just pushed my last changes to my spectrum analyzer applet. Sadly it won’t go into trunk as of now because bugs in then xine and vlc backend are preventing it from working correctly. If you want to try it out anyhow have a look at my gitorious repository (Be warned! The applet currently only shows data if you are using the xine backend and with that you WILL get crashes as soon as you stop or end the current song in any way!). The second project I might give a positive report about is my fingerprinting code. It works. Suffers from the same problems as the analyzer though (use of xine backend will crash, use of vlc will give no data). If you’re feeling adventurous you can also find this code in my repository. If you find any bugs or stuff that bother you (or just want to say how you like it) don’t hesitate to contact me. As a little appetizer I’ve made some nice pictures of the analyzer (this time with real music input):

KDE Multimedia Sprint

Monday, May 17th, 2010

Soon its time for fun, relaxation, good air, good code and mountains ( which of course means a lot of rock climbing 😉 ). Why that you might ask? Simple:

KDE Multimedia Sprint Badge

I’m very exited to meet all my coding friends in real life. I’ve been looking forward to this for a long time now. Sadly enough this week is crazy like hell. filled with a lot of work for study and all surrounding stuff. I don’t really have the time to look forward and be happy. All the more a good reason for a long earned vacation! See ya all in Randa Fellows!

Amarok Spectrum Analyzer

Friday, April 9th, 2010

I’m currently working on a Spectrum Analyzer applet for Amarok. The applet will benefit from my OpenGL applet template I made a few days ago (see this Post). This way it will also have all the nice functionality the template has (like switching between fullscreen, windowed and widget mode). I’ve already made some nice pictures with fake audio data (since the real audio data currently is hard to get via phonon). Enjoy!

Plasma Applets and OpenGL

Friday, April 9th, 2010

I lately tried to implement an Plasma Amarok Applet that has an OpenGL Widget inside of it. One would think this is a rather easy task since all this new and fancy KDE Plasma stuff smells a lot like OpenGL. Sadly not by a long shot. Implementing an OpenGL Plasma widget normally works this way: create a widget, set the Viewport of the Graphics view to an new QGLWidget and you got it. This approach has 2 Downsides though: first of all if you Viewport is an QGLWidget all you drawing will be rendered via OpenGL. And not only on this applet but on all Applets that share this widget. One might think this is no Problem. But OpenGL handles a lot of stuff quite different then the Qt Implementations of the Graphics Objects. For starters colors. The same color values won’t give you the same output if one is rendered by OpenGL and the others by Qt. So you get strange colors all over the place (and not only in this particular applet but in all the others, because all Amarok Applets share one Viewport). The second problem with this approach is that it will make rendering of non OpenGL stuff and OpenGL stuff at the same time quite hard. You’ve got to watch out for what you’re painting when and in what order and a lot of OpenGL functionality will have to be left untouched because it would mess with you Non OpenGL windows etc. As you might have guessed this was not an acceptable solution. All other approaches I made (render into the QGLWidget and get the Framebuffer from there for example) ended in either an empty Widget or a separate window for my OpenGL stuff. Googleing my ass of and tyrannizing a lot of nice people on IRC finally got me the “right” answer to my problem: I had to render all the OpenGL stuff into a QGLPixelBuffer and then paint this buffer onto the Widget with all the other Graphics Objects. Insane? Definitely! But it works like a charm. And know what? Its quite fast and reliable. I even got it to paint either to a separate Window, the Widget or even fullscreen just by clicking a button. Looks like we’re living in an insane world after all :-P.