Opened 8 years ago

Closed 8 years ago

#9684 closed bug (fixed)

Report generation can hang if reading stack memory fails

Reported by: anevilyak Owned by: anevilyak
Priority: normal Milestone: R1
Component: Applications/Debugger Version: R1/Development
Keywords: Cc: bonefish
Blocked By: Blocking:
Platform: All


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.

Change History (5)

comment:1 by anevilyak, 8 years ago

Cc: bonefish added

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?

comment:2 by bonefish, 8 years ago

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.

comment:3 by anevilyak, 8 years ago

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

comment:4 by anevilyak, 8 years ago

Status: newin-progress

comment:5 by anevilyak, 8 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in hrev45526.

Note: See TracTickets for help on using tickets.