Results 1 to 6 of 6

Thread: better error messages?

  1. #1

    better error messages?

    when I try to use a null object I get the error SIGSEVD
    is there a way of getting a more descriptive error message? such as 'object is nil'

  2. #2
    Not really

    You can get call traces by using the -gl compiler switch, and including sysutils somewhere. That way unhandled exceptions will print where it happened. You then have to figure out what happened. Segmentation faults can be hard to debug

    The best way of handling such faults is to write proper OOP code
    Peregrinus, expectavi pedes meos in cymbalis
    Nullus norvegicorum sole urinat

  3. #3
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Segmentation faults can be hard to debug
    In my experience not can be but are extremely hard to solve... Its on the top 10 'I hate it when...' list. Put it this way: If I have a 2000 line program and I chose a program line at random there is around a 0.05% chance of it being the problematic one and it could take 2000 readln() statements or step-through commands to find it. Just imagine pressing <enter> 2,000 times to find the bug for each cycle of the program.

    The last time it occurred to me like that I spent 1 hour debugging; The bug happened 35 seconds into a 40 cycle/sec program. As it turned out I finally fixed it by disabling some functions with my debug 'layer'. Basically, all functions have a Dbg_Off boolean variable. If its true, nothing occurs and return a preset value. If false (default) it does what its supposed to. It might take slightly longer to write but that approach gave me a 10min fix. And guess what: as it happened I didn't initialize Sdl or Ttf... Isn't life nice sometimes.
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  4. #4
    I've found that "separation" is the key to attack these errors. You have to make sure that the buggy code can be tested separately. If its a hard bug to solve, you can write a new program with the sole purpose of testing a single class/module of your original program.
    Coders rule nr 1: Face ur bugz.. dont cage them with code, kill'em with ur cursor.

  5. #5
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25
    I've spent many an hour or event whole day stepping through my code to find those elusive memory segment errors. Clean and organized code will help, such as making all your objects and values easily accessible and keeping your arrays and lists organized in a similar fashion. (ie. try not to have similar arrays starting with both 1 and 0 if possible)

    The only sure way to figure out one of these is to find the point in your program where the crash occurs, find this location in your code by adding break points to see if it crashes before it gets to the break point then step through your code until you find where your code and your stored values starts break down on your the way to intended your program to function. This can be an easy process or a difficult one depending on how you coded it.

    Ultimately you should need your break points and evaluation tool for checking the value of your variables and other data.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  6. #6
    how do I add breakpoints?

    when I get the breakpoint menu in lazarus 'source' is greyed out

    freepascal only talks about the default IDE:http://www.freepascal.org/docs-html/user/usersu54.html

    and the lazarus breakpoint doesnt mention my problem:http://wiki.lazarus.freepascal.org/I...:_Break_Points

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •