This project is read-only.

(unknown location) exception

Jan 14, 2011 at 12:49 PM

I have some test code which creates 16 tasks which repeatedly wait on a mutex for access to a single JavascriptContext.  When they obtain the mutex they run a simple script to compute a fibonnacci sequence and then release the mutex.  This will run correctly but more often than not it will fail with an (unknown location) exception.  This always occurs on the first attempt by a task to run the test script regardless as to whether other tasks have already run several cycles successfully. 

This exception apparently indicates that the original exception was thrown without an error message.  Does anyone have any idea what it might indicate?  Is it supposed to be OK to call Run() from a task other than that which created the context?

 

Thanks,

Andy

Jan 17, 2011 at 10:22 AM

I have now simplified the test case and submitted this as an issue as it is now clear that this is intended to be a legitimate mode of operation.

 

Andy 

Jan 18, 2011 at 12:00 AM

Have you call SetResourceConstraints to set the stack limit in each thread?  See my pos from 22 Sep 2010.

Jan 18, 2011 at 10:49 AM

After reading your post it seemed clear that this was the problem but unfortunately the fix did not work.  In fact, the behaviour of my test program is completely unchanged.  This strikes me as somewhat odd since I, presumably, should be suffering from the stack overflow fault that you mention.  I will investigate further.

In any case it would seem prudent to add the code to prevent the stack overflow exception to the current release.

 

Thanks,

Andy

Jan 18, 2011 at 11:02 AM

Of course, this is the problem.  I am using only one JavascriptContext and so the stack limit will be set for the thread that creates it.  Unfortunately creating a context per thread will not work because JavascriptContext leaks; see my previous post Fatal error in CALL_AND_RETRY_2 (out of memory) 

I guess the solution might be to set the stack limit on Run().

Jan 18, 2011 at 11:54 AM

And indeed it is.  Setting the stack limit on each call to Run() fixes the problem completely.