How can I find the location of a "List index out of bounds" error in Delphi

views:

1570

answers:

+2 Q:

How can I find the location of a "List index out of bounds" error in Delphi

Any hints what your application's doing when this occurs? A long loop? A button click?

When the application halts and you look at the call stack debug window, can you trace the call back to the last call from your code? The call stack won't tell you all of the conditions, but can narrow down the location.

Once you narrow down the call, a logging tool like CodeSite can be really useful. For instance, I often log loop control variables to figure out which iteration occurs last before the error, then it's a matter of identifying likely suspects.

Argalatyr 2009-07-28 02:49:36

I know it's an out-of-bounds error in one of the many TLists that either my program or a component in my program is using. I'm surprised that bounds-checking doesn't catch this.The application doesn't halt. It continues on after I press the OK button, but with some functionality missing.If I could find the call, then I'll know where the error is. But it is finding the call that is difficult.

lkessler 2009-07-28 03:22:31

Bounds checking wouldn't catch it because bounds checking applies to arithmetic operations (overflow). You mean range checking, but range checking *can't* catch it because that only applies to arrays, not classes. The error message you're seeing is a result of the list class's own "range checking."

Rob Kennedy 2009-07-28 03:58:46

Could you add a button and attached method that displays a value from each of your TLists? Perhaps that one that doesn't show is the one that died? Would this narrow it down? I agree that it may ultimately be less work to get familiar with the JCL debug tool, madExcept, or EurekaLog because the right tool finds many uses...

Argalatyr 2009-07-28 04:09:47

A correction to my previous comment. Delphi doesn't have anything officially known as *bounds* checking; I was thinking of *overflow* checking. Inasmuch as range checking and bounds checking are synonyms, you were right to call it bounds checking. The bottom line is that no compiler option could control detection of this problem because it involves a list class, not an array.

Rob Kennedy 2009-07-28 05:49:30

+8 A:

madExcept (free) or EurekaLog (paid) may help. You can set them up to show/email a stack trace when an error occurs. I use EurekaLog in all my projects and it is invaluable for fixing these kinds of things.

SeanX 2009-07-28 03:12:09

FYI madExcept is only free for non-commercial use.

Conor Boyd 2009-07-28 03:26:18

I presume either of those programs (I've never tried them) will work. But they are a bit overkill if I don't want to add enhanced error reporting into my distributable package. I may go with one of them (any recommendations as to which is better?), but I was really hoping for a simpler solution.

lkessler 2009-07-28 03:43:59

The JCL has a similar offering and really is free.

Rob Kennedy 2009-07-28 03:59:32

I used madExcept, but now prefer EurekaLog. I haven't tried the jcl alternative.They are reasonable non invasive, you get a larger exe but that is about all. It is quite easy to toggle them on/off if you don't want to include them in your distribution. I recommend that you do though, you will find bugs you never knew about.

SeanX 2009-07-28 04:23:45

@SeanX: JCl can also use external debug information so you don't need to have a larger exe. I asume the other alternatives have the same option.

Lars Truijens 2009-07-28 08:56:38

I have used madExcept for many years now. nothing forces you to DEPLOY using it. You can use it just for your internal builds, then easily turn off the add-in for your production builds. If you use a build system (final builder) adding madExcept to your project is an extra step anyway.

skamradt 2009-07-28 15:28:28

+7 A:

Do you have "Stop on Delphi Exceptions" turned on? (Tools\Debugger Options\Language Exceptions [Delphi7]) Otherwise it won't break in your sourcecode.

Also make sure that EListError is not in your "Exception Types to Ignore" list. This list is also found at Tools\Debugger Options\Language Exceptions (Delphi 7).

The_Fox 2009-07-28 06:34:43

This is another (came after Alexander's) version of the simple answer I was looking for. I'll check it when I get home later today.

lkessler 2009-07-28 13:43:58

According to SO, I answered an hour earlier ;) and I didn't see Alexanders answer when I posted mine. So, I was first :P

The_Fox 2009-07-28 14:17:36

Interesting. Must be a time zone thing that SO gets wrong. It says you answered 14 hrs ago and Alexander answered 13 hrs ago. But when I sort oldest first, yours does come ahead, so you indeed must have been first.

lkessler 2009-07-28 21:15:17

In Delphi 2009, it is actually under Tools\Options\Language Exceptions. "Notify on language exceptions" was checked by default, so that was okay. But EListError was in the ignore list. Unchecking that, and Delphi now trapped the error. I can break on it and get the call stack. Thanks. That's what I was looking for.

lkessler 2009-07-28 21:51:13

Indeed, when I first saw The_Fox's answer and upvoted it, Alexander's had not yet been posted.

Argalatyr 2009-07-28 22:40:22

+1 A:

As this is an RTL/VCL error, you often end up with better breaking/callstack behaviour if you enable Debug DCU's (and rebuild).

Paul-Jan 2009-07-28 06:39:47

Didn't need to try it (see solution above), but thanks for the idea.

lkessler 2009-07-28 22:09:41

+7 A:

Hey, you don't need any additional tools to track this! :)

Just run your application under debugger and make sure that "Stop on Delphi Exceptions" (or whatever it is called in your Delphi's version) is turned ON.

When exception occurs - there will be a notification from debugger. Press "Ok"/"Debug" button and just view the call stack. Call stack window is shown automatically in recent Delphi's version. If you can not see it - go to "View"/"Debug Windows"/"Call stack".

That's all. The call stack will point you at the exact location of the problem. No additional tool needed.

Those tools (EurekaLog, JCL or madExcept) are needed if you distribute your program among users and want to gather bug-reports about problems on client side. I.e. there is no debugger to check the problem.

Alexander 2009-07-28 07:26:27

I also see a strange non-standard word in caption: "Behold" ;)

Alexander 2009-07-28 07:27:33

Hopefully, "Behold" will soon be a standard. :-)

lkessler 2009-07-28 13:38:34

This is one version of the simple answer I was looking for. I'll check it when I get home later today.

lkessler 2009-07-28 13:44:41

"Hopefully, "Behold" will soon be a standard" - actually, I just mean that you can try to locate this string in your sources and may be there will be some hint. That's all :D

Alexander 2009-07-28 14:57:28

Behold is the name of my program. My program uses the standard convention (e.g. as Notepad does) of setting the caption of the main form to the name of the open file followed by a dash followed by the program name. The caption of that popup box seems to have inherited the caption from the main form of my program. So it wouldn't have helped me find the error - but that was a good possible idea. ... And that's why I say I hope "Behold" will soon be a standard.

lkessler 2009-07-28 22:00:49

ansaurus

tags:

views:

answers:

How can I find the location of a "List index out of bounds" error in Delphi

related questions