[+chromium-dev] Ok this email reminded me that http://sites.google.com/a/chromium.org/dev/developers/how-tos/debugging really needed an overhaul. It cleaned it up and removed any reference to --debug-children. This flag should not be used (and should be removed). --wait-for-debugger-children should be favored instead, when needed. It's not an issue when not debugging a startup bug, read the reference to the .NET macro for more info. Yes, .NET. This is frightening but it won't hurt too much. I also added a reference to the symbols server.
As Amit said, windbg -o always works. M-A On Tue, Mar 3, 2009 at 6:03 AM, Amit Joshi <[email protected]> wrote: > try debugging with windbg -o > - Show quoted text - > > On Tue, Mar 3, 2009 at 2:12 AM, David Moore <davemoore@ chromium.org > wrote: >> >> I discovered that --debug-children breaks handle sharing under Visual >> Studio, at least on Vista32. But --renderer-startup-dialog works, as long as >> you also specify --no-sandbox so that the MessageBox can be displayed. >> Dave >> >> On Mon, Mar 2, 2009 at 6:03 PM, David Moore <[email protected]> wrote: >>> >>> I'm trying to track down something that only happens in multi-process. >>> When I run under the debugger with --debug-children I get a debug break. I >>> traced it down to a DuplicateHandle() failing with an access error. It's the >>> handle that's created in BrowserRenderProcessHost::InitVisitedLinks(), >>> sharing to the renderer. I'm running on Vista. Is this a config that's known >>> not to work? >>> Dave --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
