Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#9510 closed enhancement (fixed)

Include area list in the debug report

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

Description

Extra points if the image areas aren't listed twice.

Another thing to think about would be to include the stack traces of all threads, not just the crashed one. I mean space isn't really an issue, is it?

Attachments (1)

Debugger-34522-debug-05-04-2013-20-49-08.report (9.5 KB ) - added by anevilyak 7 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 by anevilyak, 7 years ago

So it's not forgotten, from further discussion information about the crashed team's semaphores would also be nice to have.

comment:2 by anevilyak, 7 years ago

Status: newin-progress

comment:3 by anevilyak, 7 years ago

Resolution: fixed
Status: in-progressclosed

Implemented in hrev45441 and hrev45442. Feedback on the output format welcome.

comment:4 by phoudoin, 7 years ago

Nice addition. Would it be costly to dump AreaInfo's lock and protection flags in a user friendly way, not only a hex value?

in reply to:  4 comment:5 by anevilyak, 7 years ago

Replying to phoudoin:

Nice addition. Would it be costly to dump AreaInfo's lock and protection flags in a user friendly way, not only a hex value?

That'd certainly be doable, would just need to write a corresponding formatter. Will add to my TODO list.

in reply to:  4 comment:6 by anevilyak, 7 years ago

Replying to phoudoin:

Would it be costly to dump AreaInfo's lock and protection flags in a user friendly way, not only a hex value?

A sample:

Areas:
        runtime_loader_seg0ro (556770) Base: 0x100000, Size: 61440, RAM Size: 0, Locking: B_FULL_LOCK, Protection: B_READ_AREA|B_EXECUTE_AREA
        runtime_loader_seg1rw (556771) Base: 0x10f000, Size: 4096, RAM Size: 4096, Locking: B_FULL_LOCK, Protection: B_READ_AREA|B_WRITE_AREA
        rld heap (556772) Base: 0x110000, Size: 65536, RAM Size: 49152, Locking: B_FULL_LOCK, Protection: B_READ_AREA|B_WRITE_AREA|B_KERNEL_READ_AREA|B_KERNEL_WRITE_AREA
        _rld_debug_ (556773) Base: 0x120000, Size: 4096, RAM Size: 4096, Locking: B_FULL_LOCK, Protection: B_READ_AREA|B_WRITE_AREA|B_KERNEL_READ_AREA|B_KERNEL_WRITE_AREA|B_SHARED_AREA

Only problem is this gets a bit long for areas with lots of flags, any suggestions as far as ways to shorten it but still have the meaning be clear?

Last edited 7 years ago by anevilyak (previous) (diff)

comment:7 by axeld, 7 years ago

Some suggestions:

  • "full", "lazy", and "none" instead of B_FULL_LOCK, etc.
  • "r+w" for B_READ_READ|B_WRITE_AREA
  • "kernel r+w" for B_KERNEL_READ_READ|B_KERNEL_WRITE_AREA
  • "shared" for B_SHARED_AREA
  • Leave out kernel if user r/w is given, because the latter implies the former

An example could then look like this: Locking: full, Protection: r, kernel r+w

in reply to:  7 comment:8 by anevilyak, 7 years ago

Replying to axeld:

Some suggestions:

  • "full", "lazy", and "none" instead of B_FULL_LOCK, etc.

Done.

  • "r+w" for B_READ_READ|B_WRITE_AREA
  • "kernel r+w" for B_KERNEL_READ_READ|B_KERNEL_WRITE_AREA
  • "shared" for B_SHARED_AREA
  • Leave out kernel if user r/w is given, because the latter implies the former

Did something similar, see attachment:Debugger-34522-debug-05-04-2013-20-49-08.report

A clarifying question though: do all of the user flags imply their kernel equivalent? i.e. do B_EXECUTE_AREA and B_STACK_AREA also imply their B_KERNEL_ equivalents? My current code assumes so, but I'm not completely certain as to where to look to ascertain that.

Note: See TracTickets for help on using tickets.