Nodes captured or added to a graph can fail due to captured variables going out of scope

[Bensuo]

Because of the delayed submission of the lambda functions passed to the sycl::queue in either mode of graph construction it is possible for a situation to arise where the lambda captures variables which are alive at time of submission to the queue but out of scope at time of graph execution, which causes undefined behaviour and errors when executing a graph. For example:

void run_some_kernel(sycl::queue q, int* data){
  // data is captured by ref here but will have gone out of scope when the 
  // CGF is later run when the graph is executed.
  q.submit([&](sycl::handler& h){
    // Call some kernel which uses data here
  });
}
int main(){

sycl::queue q;

int* someUsmAllocatedPtr;
q.begin_recording();
run_some_kernel(q, someUsmAllocatedPtr);
q.end_recording();
}

This scenario is potentially more common with record and replay but not improbable with the explicit API.

[Bensuo]

When investigating using record and replay with oneDNN this problem can also be seen. Where kernels are actually submitted within oneDNN, in this code, many variables are captured and used in the CGF which will go out of scope before graph execution time.

In some cases this can be avoided by capturing everything by value but for example in this case the kernel_arg_list_t type explicitly cannot be copied so even this doesn't help. This is mostly mentioned as an interesting note because obviously it is not desirable to change the lambda capture to by value in most cases.

[EwanC]

Closing as fixed in #87