Warning(13) task stack computation for Main indeterminate

[wwwoholic]

I have a simple class wrapping reading from analog inputs. Recently I added a subclass and immediately got this in compiler output:
Warning(13): task stack computation for "Main" is indeterminate

Now, I understand that it might be tricky to calculate stack if there are different possible subclasses used. However this still seems strange for 3 reasons:

a) I wrote a lot of OOP code before with much more complex processing in overrides and never before seen this warning;

b) New class is not used anywhere in the program. I just wrote it, hit compile and got a warning. I would rather expect the class disappear from intermediate C output altogether as I've seen many times happening to unused code.

c) And most important - the only method in the new class does not have any local variables and invokes only couple system functions. It should be easy to determine stack size usage for this.

[dkinzer]

I have a simple class wrapping reading from analog inputs. Recently I added a subclass and immediately got this in compiler output:

Thanks for providing the sample code. I had to change pin to p to get it to compile. Incorporating it into a full application, however, does not yield the warning that you described (using v4.1.5 of the compiler). There were some changes made in the recent past to the stack usage analysis code related to derived classes.

Could you put together a complete compilable/linkable test case that exhibits the issue and specify which version of the compiler you're using?

[wwwoholic]

I am using 4.1.5

[dkinzer]

Thanks for the example. With it, we were able to determine what was causing the unnecessary warning and derive a solution for it. A new version of the compiler, v4.1.7, with the correction is available on the Downloads page. The new version also corrects the missing initialization reported in another thread.

[wwwoholic]

As a follow up note, I received a call from customer who used 4.1.5 with new version of a program (without subclass causing warning but with some new code added) and the result is drastic - at the end of upload a typical zbasic greeting message gets repeated three times and then program hangs.

For any controller with shared code/data memory I would say this is likely memory/stack problem. For AVR I do not know what to think. When compiled with 4.0.2 same program works flawlessly.

[dkinzer]

When compiled with 4.0.2 same program works flawlessly.

If you could send me the application, I can compile it with both and check for differences in the generated code. It is possible that the problem is related to the "initialized static variable" problem that you reported in another thread.

[wwwoholic]

I wish I could but technically it's a property of my customer. I'll ask them to try new compiler and see if it works.

[dkinzer]

I wish I could but technically it's a property of my customer.

I'm willing to sign a NDA in order to have access to the source code. Absent a reduced test case that exhibits the same symptoms it's the only practical way to attack the problem.

[wwwoholic]

Hit the same problem again in completely different and very simple code. Started new thread but then realized we already discussed it here.

Basically, calling _parent method prevents correct calculation of main task stack. Calling _parent.Create in the same class compiles just fine. It is my understanding that when it comes to C code there is no difference between constructor and regular method, they all become just static functions somewhere.

Using most recent compiler available. Do you need the code or is this known problem?

[dkinzer]

Do you need the code or is this known problem?

It would be best if you could provide a (stripped down) test case that exhibits the problem. That way we can get right to working on the analysis.

[wwwoholic]

It can be as simple as this

Code: Select all

option TargetDevice ZX24s
option Objects

dim S as B

class A
	public function Read() as integer
		Read = 0
	end function
end class

class B extends A
	public function Read() as integer
		Read = _parent.Read()
	end function
end class

public sub Main()
	dim ps as integer
	ps = S.Read()
end sub

[dkinzer]

Thanks for the test case. The source of the problem has been located and corrected. There is a compiler update on the Downloads Page that contains the correction.

[wwwoholic]

Thanks! That was fast... I wonder how this slipped through, seems to be very basic functionality.

Update: Something strange going on. I changed the code to use _parent from the function BEFORE taking new compiler. And the warning is not there! It looks like some changes I made in between to other parts of code affected this behavior.