RE: Stack level in 4DDebugLog.txt

2017-12-14 Thread Timothy Penner via 4D_Tech
How do you know the 3rd party component is not nesting the calls 200+ deep 
before returning back to your code?

> So, what could be the reason the debug logger misses returns from method 
> calls from within the component?

I think the debug logs should explain exactly what is happening;
Please either post the logs publicly or open a case and submit the logs that 
you have collected.

-Tim


**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

Re: Stack level in 4DDebugLog.txt

2017-12-13 Thread Timothy Penner via 4D_Tech
Do you have code that can reproduce this?

If so, what does the call chain look like in the debugger if you trace it? Does 
it show 30 calls deep or 2 calls deep?

Can you supply the code and or debug logs that show this?

-Tim


Sent from my Verizon, Samsung Galaxy smartphone




 Original message 
From: Piotr Chabot Stadhouders <p.stadhoud...@timeff.com>
Date: 12/13/17 12:23 AM (GMT-08:00)
To: 4D iNug Technical <4d_tech@lists.4d.com>, Chip Scheide 
<4d_o...@pghrepository.org>, Timothy Penner <tpen...@4d.com>
Subject: RE: Stack level in 4DDebugLog.txt

Hi Chip, Tim,

Could there be some other weird reason why the stack level increases and 
doesn't decrease?
Maybe calling plugin commands, or maybe EXECUTE METHOD?
Maybe a bug in the debug log?
Maybe something in Windows 10?

I know nearly for sure that there is no recursion, and still the stack level 
increases
At some point I am in a method I know it is stack level 2 (for example), but 
the debug level tells me I am in level 30. How is this possible?

Gr,

Piotr

> -Oorspronkelijk bericht-
> Van: Chip Scheide [mailto:4d_o...@pghrepository.org]
> Verzonden: maandag 11 december 2017 19:21
> Aan: 4D iNug Technical <4d_tech@lists.4d.com>
> Onderwerp: RE: Stack level in 4DDebugLog.txt
>
> Piotr,
> don't forget the possibility of indirect recursion too.
> Method_A call Method_B which calls Method_C which calls Method_A
>
>
> On Mon, 11 Dec 2017 18:11:32 +, Timothy Penner via 4D_Tech wrote:
> > It could be recursion. The debug logs should help you determine
> > exactly what is being called.
> >
> > If method1 calls method1 which calls method1 again (and again and
> > again and again), it would increase the stack level each time it
> > calls itself.
> >
> > -Tim
> >
> >
> >
> >
> >
> 
> **
> > 4D Internet Users Group (4D iNUG)
> > FAQ:  http://lists.4d.com/faqnug.html
> > Archive:  http://lists.4d.com/archives.html
> > Options: http://lists.4d.com/mailman/options/4d_tech
> > Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> >
> 
> **
> ---
> Gas is for washing parts
> Alcohol is for drinkin'
> Nitromethane is for racing

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Stack level in 4DDebugLog.txt

2017-12-13 Thread Piotr Chabot Stadhouders via 4D_Tech
Hi Chip, Tim,

Could there be some other weird reason why the stack level increases and 
doesn't decrease?
Maybe calling plugin commands, or maybe EXECUTE METHOD?
Maybe a bug in the debug log?
Maybe something in Windows 10?

I know nearly for sure that there is no recursion, and still the stack level 
increases
At some point I am in a method I know it is stack level 2 (for example), but 
the debug level tells me I am in level 30. How is this possible?

Gr,

Piotr

> -Oorspronkelijk bericht-
> Van: Chip Scheide [mailto:4d_o...@pghrepository.org]
> Verzonden: maandag 11 december 2017 19:21
> Aan: 4D iNug Technical <4d_tech@lists.4d.com>
> Onderwerp: RE: Stack level in 4DDebugLog.txt
> 
> Piotr,
> don't forget the possibility of indirect recursion too.
> Method_A call Method_B which calls Method_C which calls Method_A
> 
> 
> On Mon, 11 Dec 2017 18:11:32 +, Timothy Penner via 4D_Tech wrote:
> > It could be recursion. The debug logs should help you determine
> > exactly what is being called.
> >
> > If method1 calls method1 which calls method1 again (and again and
> > again and again), it would increase the stack level each time it
> > calls itself.
> >
> > -Tim
> >
> >
> >
> >
> >
> 
> **
> > 4D Internet Users Group (4D iNUG)
> > FAQ:  http://lists.4d.com/faqnug.html
> > Archive:  http://lists.4d.com/archives.html
> > Options: http://lists.4d.com/mailman/options/4d_tech
> > Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> >
> 
> **
> ---
> Gas is for washing parts
> Alcohol is for drinkin'
> Nitromethane is for racing

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Stack level in 4DDebugLog.txt

2017-12-11 Thread Chip Scheide via 4D_Tech
Piotr, 
don't forget the possibility of indirect recursion too.
Method_A call Method_B which calls Method_C which calls Method_A


On Mon, 11 Dec 2017 18:11:32 +, Timothy Penner via 4D_Tech wrote:
> It could be recursion. The debug logs should help you determine 
> exactly what is being called.
> 
> If method1 calls method1 which calls method1 again (and again and 
> again and again), it would increase the stack level each time it 
> calls itself.
> 
> -Tim
> 
> 
> 
> 
> **
> 4D Internet Users Group (4D iNUG)
> FAQ:  http://lists.4d.com/faqnug.html
> Archive:  http://lists.4d.com/archives.html
> Options: http://lists.4d.com/mailman/options/4d_tech
> Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
> **
---
Gas is for washing parts
Alcohol is for drinkin'
Nitromethane is for racing 
**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Stack level in 4DDebugLog.txt

2017-12-11 Thread Timothy Penner via 4D_Tech
It could be recursion. The debug logs should help you determine exactly what is 
being called.

If method1 calls method1 which calls method1 again (and again and again and 
again), it would increase the stack level each time it calls itself.

-Tim




**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Stack level in 4DDebugLog.txt

2017-12-11 Thread Piotr Chabot Stadhouders via 4D_Tech
Hi Tim,

Thanks again for your answer.
I already thought so, however, in my case the stack level increases over time
It starts with zero
I see it decrease some times, but after 1000 log lines it already is at 262

So I guess this smells like a nesting problem?
I have to find out where and why

Or could there be another reason?

Gr,

Piotr


> -Oorspronkelijk bericht-
> Van: Timothy Penner [mailto:tpen...@4d.com]
> Verzonden: maandag 11 december 2017 18:31
> Aan: 4D iNug Technical <4d_tech@lists.4d.com>
> CC: Piotr Chabot Stadhouders <p.stadhoud...@timeff.com>
> Onderwerp: RE: Stack level in 4DDebugLog.txt
> 
> The stack level is how far down the call chain you are. When one method calls
> another you increase the stack level, if that method then calls another method
> you increase the stack level again. As methods complete the stack level
> decreases.
> 
> The following description on Wikipedia for Call Stack may help further explain
> the concept:
> https://en.wikipedia.org/wiki/Call_stack
> {
> A call stack is used for several related purposes, but the main reason for 
> having
> one is to keep track of the point to which each active subroutine should 
> return
> control when it finishes executing. An active subroutine is one that has been
> called but is yet to complete execution after which control should be handed
> back to the point of call. Such activations of subroutines may be nested to 
> any
> level (recursive as a special case), hence the stack structure. If, for 
> example, a
> subroutine DrawSquare calls a subroutine DrawLine from four different places,
> DrawLine must know where to return when its execution completes. To
> accomplish this, the address following the call instruction, the return 
> address, is
> pushed onto the call stack with each call.
> }
> 
> 
> -Tim
> 
> 
> Timothy Penner
> Senior Technical Services Engineer
> 
> 4D Inc
> 95 S. Market Street, Suite #240
> CA 95113 San Jose
> United States
> 
> Telephone : +1-408-557-4600
> Standard :  +1-408-557-4600
> Fax :   +1-408-271-5080
> Email : tpen...@4d.com
> Web :   www.4D.com
> 

**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**

RE: Stack level in 4DDebugLog.txt

2017-12-11 Thread Timothy Penner via 4D_Tech
The stack level is how far down the call chain you are. When one method calls 
another you increase the stack level, if that method then calls another method 
you increase the stack level again. As methods complete the stack level 
decreases.

The following description on Wikipedia for Call Stack may help further explain 
the concept:
https://en.wikipedia.org/wiki/Call_stack
{
A call stack is used for several related purposes, but the main reason for 
having one is to keep track of the point to which each active subroutine should 
return control when it finishes executing. An active subroutine is one that has 
been called but is yet to complete execution after which control should be 
handed back to the point of call. Such activations of subroutines may be nested 
to any level (recursive as a special case), hence the stack structure. If, for 
example, a subroutine DrawSquare calls a subroutine DrawLine from four 
different places, DrawLine must know where to return when its execution 
completes. To accomplish this, the address following the call instruction, the 
return address, is pushed onto the call stack with each call.
}


-Tim



**
4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4d_tech-unsubscr...@lists.4d.com
**