Quasar C++ API: precise origin of Quasar errors

Q&ACategory: Feature requestQuasar C++ API: precise origin of Quasar errors
Frank Vernaillen asked 2 years ago

The essence of the Quasar C++ API is the ability to call Quasar functions. This is done via quasar::Function::operator()(...). If an error occurs during execution of the Quasar function, a C++ exception of type exception_t will be thrown. While this class has source, message and stack_trace fields to help figure out the origin of the error, these fields are typically rather vague.
For example, recently I ran into the problem where quasar::Function::operator()(...) threw an exception_t with the following information:


source: 
Quasar.Runtime 

message: 
CUDA_launch returned an error: CUDA Error ErrorMissingConfiguration: __global__ function call is not configured 

stack_trace:
 at Quasar.Interpreter.DirectInterpreter.OnError(Exception innerException, String msg, LineNumberRange lineNumber, Object[] args)
 at Quasar.Interpreter.DirectInterpreter.Run()
 at Quasar.Interpreter.DirectInterpreter.UserFunctionCall(FunctionDescriptor fd, QTypedObject closureVars, QValue[] vals)
 at Quasar.Interpreter.DirectInterpreter.EvaluateIndirectFunctionCall(QValue function, QValue[] args) at Quasar.NativeInterface.FunctionCallIndirect(IntPtr functionHandle, IntPtr ptrArgsIn, Int32 nArgsIn, IntPtr ptrArgsOut, Int32 nArgsOut) 

It turned out that the error was really an out-of-memory condition caused by a call to zeros(4000, 4000, 10) from within the Quasar function that was called.
I wonder if it would be possible to provide more accurate feedback in exception_t on the precise location of errors that occur while calling a Quasar function from the C++ API. Obtaining the Quasar source file name and line number would be ideal.
In this particular case, the error message itself (__global__ function call is not configured) is not informative either, but I may need to complain to NVidia about that 🙂

1 Answers
bgoossen Staff answered 2 years ago

OK. Thanks for the feedback! Line number information has been added now to the `exception_t::message`. Note that this is only applicable when loading source modules (.q files). For .qlib files, the line number information is lost. For the moment, I did not make any new fields in exception_t to get programmatic access to the line number/module name. In case that would be necessary let me know.