Is defensive programming out?

Cdh · 2010-06-27 20:42:18

Hi,

I wondered if I am a naturally talented software tester, because on trying some random software I easily find ways to make it segfault.
Two examples from today include rosegarden and kazehakase.

rosegarden, default configuration:
Start it, doubleclick on the first measure, choose menu "segment" -> "new layer", click the undo button, enjoy segfault.

kazehakase, default configuration:
Start it, choose menu "view" -> "ui level" -> "medium" or "expert", choose menu "view" -> "view page source" while no tab is open (as it is with default config on first start), enjoy segfault.

So first kazehakase: Yes, I know it is a very early version. But I can live with missing functionality like "view page source" doing nothing. The problem is crashing on issueing such command. Without looking at the code I bet this is a null pointer (because there is no page displayed) of which the developer thought "oh, this probably won't ever be null".

Next is rosegarden which wants to be "professional".
I believe this bug with "undo" to be similar to the one in kolourpaint (start kolourpaint, choose text tool and write a letter, press strg+a, strg+z, this should be fixed, but at least now not in the repos.). Maybe it's a problem in qt in general or a problem with implementing "undo" in general. I don't care.
When implementing an undo function I would be EXTREMELY careful to what happens in this functions.
You have to be ready to undo ANYTHING that the user can possibly do in your program which is hell of a lot.

In these programs people apparently didn't use defensive programming: I can see the programmer sitting there and think about how to undo several things but not how to handle something coming into his undo function that it cannot undo.
I also believe plasma from KDE to crash so much instead of displaying an error message because of that.

The question I ask myself is: Why do I see so many segfaults and so few error messages?
Is it time for a kernel API to inform the application that it segfaulted and give it a chance to recover, maybe even with user intervention?

Last edited by Cdh (2010-06-27 20:43:51)

ngoonee · 2010-06-27 22:43:50

You seem to know your way around, why not ask on those project's mailing lists for some pointers into which section of code you should examine and maybe fix?

Themaister · 2010-06-28 03:44:42

It is possible for application to catch SIGSEGV, and log out where this happened. MPlayer uses this to report crashes afaik.

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>

void sighandle(int sig)
{
   puts("Hai guise! I just segfaulted in main. :)");
   exit(1);
}

int main(void)
{
   signal(SIGSEGV, sighandle);

   *(int*)NULL = 0;

   return 0;
}

I'm generally a fan of defensive programming. Edge cases _always_ occur at some point.

Last edited by Themaister (2010-06-28 03:53:01)

bernarcher · 2010-06-28 05:31:39

I think defensive programming, even "simple" exception handling, never was widely used. It is by no means trivial and tends to bloat the code, esp. in languages with no exception handling mechanisms built in, like C for instance.

Even using languages which do provide fairly good mechanisms for exception handling (like e.g. Eiffel, or D) it is difficult to catch edge cases in a meaningful way (other than simply finishing program execution). More often than not exceptions do not occur locally to the program part which really needs to handle the situation. And if they do they lead to more or less combinatorial explosion if not thoroughly planned. Thus, making a programm foolproof from start as "defensive programming" mandates is a tremendous effort (and not overly exciting to do).

Even if you try to handle system signals, things tend to be involved and complicated. Just have a look at theSignal Concepts in the Open Group Base Specification. Or have a look at man signal and related man pages.

This is not to state defensive programming to be fruitless. But the efforts in time (and money) are most often not taken. You can't easily show built-in defenses. Being able to get a program "just running" and showing some effects appears far more exciting.

It is like thorough testing (beyond running a unit test suite), and documenting (both software and user sides) - most desirable, but not many want to really do the works.

Cdh · 2010-06-28 08:30:53

bernarcher wrote:

It is by no means trivial and tends to bloat the code, esp. in languages with no exception handling mechanisms built in, like C for instance.

You could use the famous "simply return zero and hope it keeps going" technique.

I didn't say it is not hard but recently I have seen so many segfaults and crashing it's not funny anymore...
At least for error prone functions like "undo" you should do it.

@Themaister
Great, but not many people use it I guess.

@ngoonee
I'm a beginner at c and don't have too much time.

Ari'osika · 2010-06-28 08:52:28

bernarcher wrote:

I think defensive programming, even "simple" exception handling, never was widely used. It is by no means trivial and tends to bloat the code, esp. in languages with no exception handling mechanisms built in, like C for instance.
Even using languages which do provide fairly good mechanisms for exception handling (like e.g. Eiffel, or D) it is difficult to catch edge cases in a meaningful way (other than simply finishing program execution). More often than not exceptions do not occur locally to the program part which really needs to handle the situation. And if they do they lead to more or less combinatorial explosion if not thoroughly planned. Thus, making a programm foolproof from start as "defensive programming" mandates is a tremendous effort (and not overly exciting to do).
Even if you try to handle system signals, things tend to be involved and complicated. Just have a look at theSignal Concepts in the Open Group Base Specification. Or have a look at man signal and related man pages.
This is not to state defensive programming to be fruitless. But the efforts in time (and money) are most often not taken. You can't easily show built-in defenses. Being able to get a program "just running" and showing some effects appears far more exciting.
It is like thorough testing (beyond running a unit test suite), and documenting (both software and user sides) - most desirable, but not many want to really do the works.

Well said. I can't really elaborate on this but I'd have to wholeheartedly agree.

(Sorry I can't elaborate I whenever i'm coding something thats one of the few things I try to look out for).

Last edited by Ari'osika (2010-06-28 09:49:05)

Trent · 2010-06-28 12:22:14

A real problem with catching things like that is that it's not always possible. C doesn't initialize automatic variables, and pointers can have arbitrary values (even hard-coded ones). For some things, this is necessary (boot loaders, say, or certain device drivers). A program could have any number of reasons for dereferencing a pointer that it didn't get from malloc(), malicious or benign. Some of those dereferences are legal. Some are spurious. Some are just accidents. But there's no universal way to tell. Not all of the mistakes will result in segfaults, either. Recovering from segfaults is only half a solution.

Besides, after trampling on memory your program doesn't own, your program has undefined behavior. Better to validate your pointers before using them than try to clean up afterwards with demons flying out of your nose.

Bralkein · 2010-06-28 12:38:34

I agree with what bernarcher said and I would add that for some FOSS projects the addition of features and a rush to release something can both take higher priority over stability and completeness. Many free software projects rely almost exclusively on volunteer programmers, so it's necessary to get something released and into the hands of users so that the project can find interested people and build momentum. I doubt many people start a project with the intention of letting documentation and stability fall by the wayside, it's just that being a perfectionist can be a good way to stall a fledgling open source project. Not everyone can be Donald Knuth. Having said that, I do think you could take the idea too far and end up making an unfixably broken piece of junk so just be careful

Last edited by Bralkein (2010-06-28 13:20:05)

Arch Linux

#1 2010-06-27 20:42:18

Is defensive programming out?

#2 2010-06-27 22:43:50

Re: Is defensive programming out?

#3 2010-06-28 03:44:42

Re: Is defensive programming out?

#4 2010-06-28 05:31:39

Re: Is defensive programming out?

#5 2010-06-28 08:30:53

Re: Is defensive programming out?

#6 2010-06-28 08:52:28

Re: Is defensive programming out?

#7 2010-06-28 12:22:14

Re: Is defensive programming out?

#8 2010-06-28 12:38:34

Re: Is defensive programming out?

Board footer