New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 134574 link

Starred by 5 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jul 2012
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Cloud Print Connector crashes on sandbox process code

Project Member Reported by, Jun 25 2012

Issue description

Chrome Version       : 22.0.1187.0 (Developer Build 143914 Windows)
Other browsers tested: Tried to test on Chrome 22.0.1186.0 Canary, but a sign-in bug prevented me from trying it.

What steps will reproduce the problem?
1. Register the printers on your Cloud Print Connector
2. Print something to one of the registered printers

What is the expected result?
Document printing.

What happens instead?
Connector crashed, restart? message.

Please provide any additional information below. Attach a screenshot if possible.

Seems to be access violation reading a null pointer (virtual method? not sure) at:
sandbox::TargetPolicy* policy = g_broker_services->CreatePolicy();

0:004> kb
ChildEBP RetAddr  Args to Child              
0efcf524 0a7778f0 0efcf704 0f614f60 0efcf598 content!sandbox::StartProcessWithAccess+0x8ba [c:\users\mniknami\work2\src\content\common\ @ 695]
0efcf534 045d19e0 0efcf704 0f614f60 bff6d024 content!content::StartProcessWithAccess+0x10 [c:\users\mniknami\work2\src\content\common\ @ 855]
0efcf598 045d174e 0efcf704 00000000 0f614f60 chrome_2500000!ServiceUtilityProcessHost::Launch+0xc0 [c:\users\mniknami\work2\src\chrome\service\ @ 140]
0efcf798 045d0fa4 00000000 0f614f60 bff6d240 chrome_2500000!ServiceUtilityProcessHost::StartProcess+0x30e [c:\users\mniknami\work2\src\chrome\service\ @ 123]
0efcf7fc 03a75e54 0f60007c 0efcf83c 0f6000b0 chrome_2500000!ServiceUtilityProcessHost::StartRenderPDFPagesToMetafile+0x124 [c:\users\mniknami\work2\src\chrome\service\ @ 67]
0efcf934 03a7b774 0f60007c 0f60009c 00000258 chrome_2500000!cloud_print::PrintSystemWin::JobSpoolerWin::Core::RenderPDFPagesInSandbox+0x264 [c:\users\mniknami\work2\src\chrome\service\cloud_print\ @ 581]
0efcf958 03a7b5b7 0f62f5e8 0f60007c 0f60009c chrome_2500000!base::internal::RunnableAdapter<void (__thiscall cloud_print::PrintSystemWin::JobSpoolerWin::Core::*)(FilePath const &,gfx::Rect const &,int,std::vector<printing::PageRange,std::allocator<printing::PageRange> > const &,scoped_refptr<base::MessageLoopProxy> const &)>::Run+0x64 [c:\users\mniknami\work2\src\base\bind_internal.h @ 450]
0efcf98c 03a7b298 025150cd 00000000 0f600078 chrome_2500000!base::internal::InvokeHelper<0,void,base::internal::RunnableAdapter<void (__thiscall cloud_print::PrintSystemWin::JobSpoolerWin::Core::*)(FilePath const &,gfx::Rect const &,int,std::vector<printing::PageRange,std::allocator<printing::PageRange> > const &,scoped_refptr<base::MessageLoopProxy> const &)>,void __cdecl(cloud_print::PrintSystemWin::JobSpoolerWin::Core * const &,FilePath const &,gfx::Rect const &,int const &,std::vector<printing::PageRange,std::allocator<printing::PageRange> > const &,base::MessageLoopProxy *)>::MakeItSo+0x97 [c:\users\mniknami\work2\src\base\bind_internal.h @ 1028]
0efcf9d8 1005adef 0f600060 0efcfbd0 0256ec13 chrome_2500000!base::internal::Invoker<6,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall cloud_print::PrintSystemWin::JobSpoolerWin::Core::*)(FilePath const &,gfx::Rect const &,int,std::vector<printing::PageRange,std::allocator<printing::PageRange> > const &,scoped_refptr<base::MessageLoopProxy> const &)>,void __cdecl(cloud_print::PrintSystemWin::JobSpoolerWin::Core *,FilePath const &,gfx::Rect const &,int,std::vector<printing::PageRange,std::allocator<printing::PageRange> > const &,scoped_refptr<base::MessageLoopProxy> const &),void __cdecl(cloud_print::PrintSystemWin::JobSpoolerWin::Core *,FilePath,gfx::Rect,int,std::vector<printing::PageRange,std::allocator<printing::PageRange> >,scoped_refptr<base::MessageLoopProxy>)>,void __cdecl(cloud_print::PrintSystemWin::JobSpoolerWin::Core *,FilePath const &,gfx::Rect const &,int,std::vector<printing::PageRange,std::allocator<printing::PageRange> > const &,scoped_refptr<base::MessageLoopProxy> const &)>::Run+0xf8 [c:\users\mniknami\work2\src\base\bind_internal.h @ 2127]
0efcf9f0 100d61f9 bf9a59cb 0efcfbbc 0efcfbd0 base!base::Callback<void __cdecl(void)>::Run+0x2f [c:\users\mniknami\work2\src\base\callback.h @ 272]
0efcfb48 100d6483 0efcfb7c 0efcfe40 0efcfbc8 base!MessageLoop::RunTask+0x249 [c:\users\mniknami\work2\src\base\ @ 457]
0efcfb58 100d7303 0efcfb7c bf9a594b 0efcfd08 base!MessageLoop::DeferOrRunPendingTask+0x33 [c:\users\mniknami\work2\src\base\ @ 470]
0efcfbc8 100ec292 0efcfbe8 0e194a18 00cccccc base!MessageLoop::DoWork+0x103 [c:\users\mniknami\work2\src\base\ @ 643]
0efcfbe0 100e9fb2 0efcfc30 00000001 00000000 base!base::MessagePumpForIO::DoRunLoop+0x32 [c:\users\mniknami\work2\src\base\ @ 497]
0efcfc10 1002604c 0efcfe40 00000000 0e194f10 base!base::MessagePumpWin::RunWithDispatcher+0x82 [c:\users\mniknami\work2\src\base\ @ 64]
0efcfc24 100d5de9 0efcfe40 bf9a5f97 0efcff64 base!base::MessagePumpWin::Run+0x1c [c:\users\mniknami\work2\src\base\message_pump_win.h @ 48]
0efcfd14 100d5b3b 0efcfe40 0efcfd58 100d4e40 base!MessageLoop::RunInternal+0x139 [c:\users\mniknami\work2\src\base\ @ 414]
0efcfd20 100d4e40 bf9a5fdb cccccccc 00000001 base!MessageLoop::RunHandler+0x2b [c:\users\mniknami\work2\src\base\ @ 388]
0efcfd58 101b0676 0e194880 0efcff70 101b0897 base!MessageLoop::Run+0x60 [c:\users\mniknami\work2\src\base\ @ 298]
0efcfd64 101b0897 0efcfe40 bf9a5df3 00000000 base!base::Thread::Run+0x16 [c:\users\mniknami\work2\src\base\threading\ @ 134]

Labels: -Area-Undefined Area-Internals Feature-CloudPrint
jschuh/jam: Looks like cloud print may have fallen off the 'content API' train. Any ideas what call(s) are missing?

Comment 4 by, Jun 27 2012

Not a clue. If broker services don't initialize it's pretty much a catastrophic failure in the browser/broker process.
I found a fix, but I'm not sure if it's the correct fix:

Changing the condition on this 'if' statement such that it actually executes solves the problem:
Labels: -Pri-2 Pri-1 ReleaseBlock-Beta
It looks like this is breaking the connector pretty seriously.  It seems to fail in dev and canary whenever there is a job to print.

I'm bumping up the priority and marking this as a release block.
Status: Started
I am already working on this.
In response to comment #5, removing the condition on that "if" completely disables the sandbox. So, what exactly are you trying to do here? Are you trying to start a --type=service process as a sandbox broker process? If so, you just need to make InitializeSandbox aware of that. Otherwise, you will always crash on failing to initialize the sandbox broker (because it doesn't think you're a broker).
I'm guessing you meant #6 (since that's the one about the 'if')?

If so... I was doing was just: chrome.exe --type=service
At the crash site, it seemed like g_broker_services wasn't initialized correctly (and hence its method pointer was null or something like that).
After tracing it down I found that if you make that 'if' statement execute, then broker_services is initialized, which in turn seems to initialize g_broker_services correctly. (I didn't see g_broker_services being initialized /at all/ before modifying the 'if', which would explain the problem. Except that for some reason MSVS 2010 was telling me g_broker_services itself wasn't NULL, so I'm not sure what was going on there. Possibly a problem with the debugger.)
Broker is not initialized. I can easily reproduce that on my machine. 
It happens after
in response to #9, connector (--type=service) tries to start subprocess in sandbox and crash on g_broker_services null pointer  
Ah, I see. You were manually initializing broker_services in the old code:

The new code isn't doing that. So, like I said, in my previous comment, you need to make content::InitializeSandbox know that it needs to initialize broker_services for the service process.
Project Member

Comment 14 by, Jul 3 2012

The following revision refers to this bug:

r145335 | | Tue Jul 03 11:24:20 PDT 2012

Changed paths:

Restored missing broker initialization.

BUG= 134574 

Review URL:
Status: Fixed
Labels: Mstone-21 Merge-Requested
Crash reports show this is happening in Beta channel. A lot.  I also think it's the root cause of  issue 137962 .

It's no longer happening in dev/canary after Vitaly's fix.
 Issue 137962  has been merged into this issue.

Comment 18 by, Jul 21 2012

Labels: -Merge-Requested Merge-Approved
please go ahead. thank you!!
Project Member

Comment 19 by, Jul 21 2012

Labels: -Merge-Approved merge-merged-1180
The following revision refers to this bug:

r147807 | | 2012-07-21T23:26:09.495770Z

Changed paths:

Merge 145335 - Restored missing broker initialization.

BUG= 134574 

Review URL:
Review URL:
Project Member

Comment 20 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 21 by, Mar 10 2013

Labels: -Area-Internals -Feature-CloudPrint -Mstone-21 M-21 Cr-Internals Cr-Services-CloudPrint
Project Member

Comment 22 by, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment