exception from javaCall but no StackTraceElements

[Christian Thalinger]

On May 14, 2014, at 3:57 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> We are seeing an occasional failure on one of our hsail junit tests, I will describe here...
> 
> There is a flag, UseHSAILSafepoints and one effect of that is that if a kernel is executing and sees that the VM is desiring a safepoint, then new workitems will not get started.  This occurs even if the hsail code in the kernel itself has no "compiler safepoints".
> 
> The workitems that do not start as mentioned above are marked as never-rans and are then after all the workitems finish each never-ran is run as a javaCall to the underlying java method.  All of this is done in "thread-in-VM" mode.
> 
> This particular test is set up to have 589824 workitems and the very last workitem is designed to cause an ArrayOutOfBoundsException.  A try block surrounding the kernel call and we catch any exceptions and compare the first frame of the stack trace of the exception with the first frame that occurred when the kernel was run in pure java mode.
> 
> We always get an exception thrown from the last javaCall but occasionally the exception has no stackTraceElements so our comparison fails in that case.
> 
> I assume an exception in a javaCall is recorded in the thread and then when the thread returns from VM mode to Java mode.
> 
> Does anyone know why the exception would sometimes have no stackTraceElements?

Not sure if I’m following correctly but the “empty” exception is coming from running Java code on the CPU, correct?  It might be related to OmitStackTraceInFastThrow.  Try to turn it off.

> 
> -- Tom
> 
>