locked
Any improvements on debugging asynchronous tasks?

    Question

  • I posted this question some weeks ago, and now that the Release Preview is out, I'm wondering if any improvements have been made on this front. I'm still finding debugging asynchronous exceptions to be, frankly, painful. What's the status on this?

    Software Engineer, Brainium Studios LLC

    Friday, June 15, 2012 6:34 PM

Answers

  • Brent,

    There are no changes in the Release Preview that help with this, but we have added something since that could help a bit which will be available in the next public release. We store the instruction in user code where a task is created - points to an instruction right after either the task constructor, or create_task, (or create_async). When that particular task encounters an exception, the stored IP is transferred to the exception holder objects that the tasks runtime creates. The exception holder object can be viewed in the debugger and the address can be used to trace back to the line of source where the task that first encountered the exception was created. (This holds even if the exception is rethrown in a .get() several tasks down in the continuation chain)

    The timing of this was such that we couldn't make wider ranging changes - such as capturing full stack and local variable information.

    Monday, June 18, 2012 5:41 PM

All replies

  • Hello,

     

    Thanks for your feedback, I will involve more experts to investigate it.

     

    Best regards,

    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us

    Monday, June 18, 2012 12:14 PM
  • Brent,

    There are no changes in the Release Preview that help with this, but we have added something since that could help a bit which will be available in the next public release. We store the instruction in user code where a task is created - points to an instruction right after either the task constructor, or create_task, (or create_async). When that particular task encounters an exception, the stored IP is transferred to the exception holder objects that the tasks runtime creates. The exception holder object can be viewed in the debugger and the address can be used to trace back to the line of source where the task that first encountered the exception was created. (This holds even if the exception is rethrown in a .get() several tasks down in the continuation chain)

    The timing of this was such that we couldn't make wider ranging changes - such as capturing full stack and local variable information.

    Monday, June 18, 2012 5:41 PM
  • Great to hear. Thank you for the detailed reply! :)

    Software Engineer, Brainium Studios LLC

    Tuesday, June 19, 2012 4:55 AM