!locks not working

[Bruce Dawson]

Is it known that !locks is not working on crash dumps? I was investigating crbug.com/757398 which was a classic deadlock and a bug that could have been resolved in two minutes with !locks but instead it took quite a bit of poking about. When I tried !locks it said:

!locks

NTSDEXTS: Unable to read _RTL_CRITICAL_SECTION_DEBUG::CriticalSection at 0000000077812088

Stopped scanning because of problem reading critical section debug info

Scanned 0 critical sections

I thought that crashpad had the necessary magic to record all critical sections. The old breakpad minidump recording code did, I'm pretty sure.

I can file a bug but I thought I'd check on what was expected first.

[Mark Mentovai]

We know how to grab the lock information to make !locks work, but when it was enabled, we experienced test timeouts. Fearful that we may also be timing out while generating minidumps for Chrome “in the wild,” we disabled lock collection at 1f3ced1846f3.

If you’ve got a better (faster) way to do this, or if you know of a way to quickly pluck out “interesting” locks, let us know. I’d love to turn this back on.

--
You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev+unsubscribe@chromium.org.
To post to this group, send email to crashp...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/CAE5mQiOYXutnb7R2zwVJ1ERdN9s_LRrPF-Eq3VvX%3D2-vvT3B0Q%40mail.gmail.com.

[Scott Graham]

Sorry, unfortunately not.

Breakpad didn't have logic to capture locks. MiniDumpWriteDump() maybe has a better way of doing so that we could investigate.

There used to be code in Crashpad that attempted to capture all the locks. See e.g. https://cs.chromium.org/search/?q=InitializeCriticalSectionWithDebugInfoIfPossible&sq=package:chromium&type=cs and https://cs.chromium.org/chromium/src/third_party/crashpad/crashpad/snapshot/win/process_snapshot_win.cc?rcl=486117c99eecdc289f682644e296fb7a5bc03d32&l=443 and https://codereview.chromium.org/1392093003.

[Bruce Dawson]

That explains why I thought we had support. I don't know any magic ways to do this. I wonder why there were test timeouts? Did that get investigated?

I don't know how frequently this feature would be used. I assume it would have been awesome for this particular bug, but ???

[Mark Mentovai]

My link should have been 1f3ced1846f3. Scott said that there were hundreds of thousands of locks. That’s a pretty serious linked list to read from another process.

--
You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev+unsubscribe@chromium.org.
To post to this group, send email to crashp...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/CAE5mQiNmMPCAEt8d4%2B6d6C%2Bz67WQEcuX83h4yEfa1kLZSZ0vhA%40mail.gmail.com.

[Bruce Dawson]

That's bizarre that there were hundreds of thousands of locks. If nothing else that represents many MB of memory. Circular list maybe?

[Scott Graham]

Yeah, I think it would be useful for certain bugs.

It's kind of far back in my goldfish-quality memory now, but I believe the RTL_CRITICAL_SECTION_FLAG_FORCE_DEBUG_INFO flag that is used to get the CSs to be linked doesn't work on all OSs either. (I think maybe it did on 7 but didn't on 8? Or did on Vista but didn't on 7? Unfortunately I don't remember which.) So I felt like we needed a better approach as well (ideally being able to get the address of ntdll!RtlCriticalSectionList somehow).

On Mon, Oct 2, 2017 at 2:14 PM, Mark Mentovai <ma...@chromium.org> wrote:

[Mark Mentovai]

Scott Graham wrote:

Yeah, I think it would be useful for certain bugs.

It's kind of far back in my goldfish-quality memory now, but I believe the RTL_CRITICAL_SECTION_FLAG_FORCE_DEBUG_INFO flag that is used to get the CSs to be linked doesn't work on all OSs either. (I think maybe it did on 7 but didn't on 8? Or did on Vista but didn't on 7? Unfortunately I don't remember which.) So I felt like we needed a better approach as well (ideally being able to get the address of ntdll!RtlCriticalSectionList somehow).

Good thing you captured it in our collective external brain: end_to_end_test.py says that it didn’t work on Windows 7.

[Scott Graham]

I believe the very large list and the not-working on some OSs are related -- deleted CSs were being kept around so they could be tracked, and some usage patterns very quickly create and delete _a lot_ of CSs.

This wass (of course) a leak, so the flag stopped being honoured. But clearly I'm talking vaguely here, and we'd have to do more investigation to be sure either way.