Report generation can hang if reading stack memory fails

[anevilyak]

Currently, RetrieveMemoryBlockJob doesn't notify the block's listener if reading the requested block fails for whatever reason. Consequently, if this occurs while generating a crash report, it will wait forever for the job to complete and never write the report out.

[anevilyak]

Come to think of it, this would be a more general problem with all the UserInterfaceListener requests, as currently all of them only call the requesting listener on success/event completion. While this works well enough for the GUI, in the case of the report generator this is a bit problematic as it has to do things synchronously, and consequently needs to know that the job finished, regardless of success or failure. Currently this isn't possible since only TeamDebugger finds out about it via the JobFailed() hook, at which point there isn't really enough information to know whom to potentially notify of the failure.

I'm not sure about a clean way to handle this though, since the current design is almost entirely async. One possibility that comes to mind is adding a parameter to all the listener hooks to indicate a result code. This could be passed to the corresponding Notify() function and passed along to the listeners, which could then check that to determine if their request succeeded/failed. Consequently, though, that'd require changes to quite a lot of code since all the places that currently implement said listener hooks assume that they'd only be called in the success case. Any alternative ideas?

[bonefish]

Why not just add a listener hook for the error case? E.g. in case of the TeamMemoryBlock::Listener a MemoryBlockRetrievalFailed(). If a particular listener isn't interested in the error case, it doesn't have to override the hook.

[anevilyak]

That would work too, just need to investigate what other places might need similar failure hooks.

[anevilyak]

Fixed in hrev45526.