🚀 go-pugleaf

Hi  Scott,

If you've got 32000 lines of code, should be able to determine which line is 
causing you problem in 15 or less debugging sessions, by using a kind of 
binary chop with break points. (As Math.pow(2,15)=32768)

Set a break point roughly halfway through your code and debug. If you don't 
get a stack overflow before the break point, then you know the problem is in 
the second half of your code. You can then set another break point about 3/4 
of the way though you code and narrow it down. If you get the stack overflow 
in the first part of your program, leave your original breakpoint in place, 
but add another breakpoint 1/4 through your code and re-debug.

I use this approach in conjunction with Alexey's method of displaying unique 
messages to quickly track down the problem areas of code.

Arth


"scott" <spowell@rpsweb.com> wrote in message 
news:42978357@newsgroups.borland.com...
>
> Alexei,
>
> Thanks for the suggestion.
>
> I've commented out all of the logger calls and the app runs
> without getting the Stack Overflow.
>
> So let's say the problem is in the logger.
>
> There are 4000+ requirements and probably 32,000 total calls to
> the logger methods.  It could take a lot of "step over" clicks
> to wait for the logger to blow up.
>
> Dummy print statements seem problematic since that's basically
> what the logger does: writes to System.out.
>
> Can you suggest anything else?
>
> Could you see the hashtables growing large enough that they're
> causing the problem?
>
> I think stack overflows are typically recursion related, but I don't 
> really see any chance for that in this code.  Maybe I'm missing something.
>
> Scott
>
>
>
> "Alexey N. Solofnenko" <trelony@mail.ru> wrote:
>>Please try running the program in debugger or add dummy print statements
>>through out your code to see where stack overflow happens.
>>
>>- Alexey.
>>
>>-- 
>>Alexey N. Solofnenko {trelony at gmail.com}
>>home: http://trelony.cjb.net/
>