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

Issue 30880 link

Starred by 16 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Jun 2010
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug
M-6

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

CUPS "add printer" crashes tab

Reported by donaldca...@gmail.com, Dec 20 2009

Issue description

Chrome Version       : <4.0.277.0 (35070)>
URLs (if applicable) :http://localhost:631/admin (with cups installed)
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
  Firefox 3.x:Works fine.
IE 7:
IE 8:

What steps will reproduce the problem?
1.With cups installed, go to the above URL and click 'add printer'. 
2.
3.

What is the expected result?
Get to the admin page to add a printer.

What happens instead?
I get the "Ah, snap" error page consistently. 

Please provide any additional information below. Attach a screenshot if
possible.
I am running the google/chromium beta on an up-to-date Arch Linux system. 
Hardware is dual-core 64-bit AMD, 2 Gb memory, 320 Gb disk. In addition to 
the 'add printer' failure, I've seen this same symptom with other cups 
operations that work correctly with Firefox. I had one instance of trying 
to make this work with Chromium that killed X, but I can't tell you how to 
reproduce it.
 

Comment 1 by maste...@gmail.com, Feb 12 2010

sadly happens the same with chrome 5.0.307.7 (linux) and cups 1.4.2 in the 
administration page by example when you want to add a new printer or modify a existing 
printer

regards

Hernan
Labels: -Area-Undefined Area-WebKit autoclass
Using an automated filter to classify this issue into an area...gulp
Labels: -autoclass -Area-WebKit Area-Undefined

Comment 4 by Deleted ...@, Mar 26 2010

A ugly workaround for this is to enable the "remote administration" of cups. I can add 
new printers and manage its properties flawlessly.

Comment 5 by Deleted ...@, May 10 2010

I encountered the very same bug when after upgrading from 8.04 to 10.04.
I was following this guide (by josephitaly): http://ubuntuforums.org/showpost.php?
p=5881525&postcount=5 
I could not "Add Printer": clicked the button but nothing happened; I solved the 
empasse by starting Firefox and adding the printer via CUPS on FF.

Information about my system:
Ubuntu Linux 10.04 (lucid lynx) release
GNOME: 2.30.0 (Ubuntu 2010-03-31)
Kernel version: 2.6.32-22-generic
CUPS Version: 1.4.3
Chromium Version: 5.0.391.0 (45775) Ubuntu

Regards.
Giancarlo

Comment 6 by torki...@gmail.com, May 14 2010

i can confirm bug on Fedora 12 64bit.- here is how to trigger bug
http://localhost:631/
Adding Printers and Classes
Add printer
(root - root password)
it crashes
But if you on previous windows click "Edit Configuration File" and Save Changes, it 
wont crash

Comment 7 by evan@chromium.org, May 14 2010

Labels: -Pri-2 -Area-Undefined Pri-1 OS-Linux Crash
Status: Untriaged
Summary: CUPS "add printer" crashes tab
Tony, this is something about multipart.  I thought you fixed this recently?  I hear 
it's still broken.

This happens on all platforms but people don't really care about it except on Linux.

Comment 8 by evan@chromium.org, May 14 2010

 Issue 36267  has been merged into this issue.

Comment 9 by evan@chromium.org, May 14 2010

The bug I dup'd in has a stack trace.

(I bring this up because people here are telling me it still crashes.)

Comment 10 by tony@chromium.org, May 14 2010

I will investigate on Monday.

Comment 11 by tony@chromium.org, May 14 2010

Comment 12 by tony@chromium.org, May 14 2010

Status: Assigned
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=47599 

------------------------------------------------------------------------
r47599 | tony@chromium.org | 2010-05-18 17:03:27 -0700 (Tue, 18 May 2010) | 14 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/multipart_response_delegate.cc?r1=47599&r2=47598
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/multipart_response_delegate_unittest.cc?r1=47599&r2=47598

Work around a multipart crash caused by sending
a response header immediately after sending data.

The work around is to be more aggressive about sending
multipart data before we have a response header.  We used
to buffer a response until we had the full frame.

This avoids a crash in webcore by behaving more like
CFNetwork.  It also makes us behave more like Gecko,
which is probably good for compat.

BUG= 30880 

Review URL: http://codereview.chromium.org/2070007
------------------------------------------------------------------------

Comment 14 by tony@chromium.org, May 19 2010

Status: Fixed

Comment 15 by torki...@gmail.com, May 19 2010

Just to confirm its fixed: It now works for me on revision: 6.0.409.0 (47624). Thx

Status: Verified
I can still experiment the crash on Ubuntu Lucid, chromium-browser 5.0.375.55~r47796-
0ubuntu1~ucd1~lucid

Attached you can find the corresponding stack trace
gdb-chromium.txt
29.6 KB View Download

Comment 18 by tony@chromium.org, May 27 2010

marianoaliaga: The fix is not in 5.0.x, you need to be on the dev channel to get this fix.

Maybe FTA wants to cherry pick this change into chromium-browser?
Ah, ok. Thought revision 47599 was included in the package. Sorry for the noise.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48551 

------------------------------------------------------------------------
r48551 | mal@chromium.org | 2010-05-28 19:33:01 -0700 (Fri, 28 May 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/multipart_response_delegate.cc?r1=48551&r2=48550
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/multipart_response_delegate_unittest.cc?r1=48551&r2=48550

Revert r47599 because it breaks PDF viewing on windows.

BUG=  44595 ,  30880 
TEST=  http://www.ich.org/LOB/media/MEDIA3917.pdf doesn't hang the browser.
TBR= tony
Review URL: http://codereview.chromium.org/2320006
------------------------------------------------------------------------

Comment 21 by mal@google.com, May 29 2010

Labels: Mstone-6
Status: Assigned
Re-opening

Comment 22 by tony@chromium.org, Jun 1 2010

I do plan on fixing this (without regressing plugin loading), but I need to get a windows environment up and 
running first.  It may be a week or two.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=49355 

------------------------------------------------------------------------
r49355 | tony@chromium.org | 2010-06-09 18:22:47 -0700 (Wed, 09 Jun 2010) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/multipart_response_delegate.cc?r1=49355&r2=49354
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/multipart_response_delegate_unittest.cc?r1=49355&r2=49354
   M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/plugins/webplugin_impl.cc?r1=49355&r2=49354

Take 2 at working around a multipart crash

The work around is to be more aggressive about sending
multipart data before we have a response header.  We used
to buffer a response until we had the full frame.

This avoids a crash in webcore by behaving more like
CFNetwork.  It also makes us behave more like Gecko,
which is probably good for compat.

The original patch (r47599) broke plugins on Windows because
it was depending on the assumption that we would send data
as one big chunk.  Now that we send data as multiple chunks,
we need to update the data offset being sent to the plugin.

BUG= 30880 

Review URL: http://codereview.chromium.org/2787002
------------------------------------------------------------------------

Comment 24 by tony@chromium.org, Jun 10 2010

Status: Fixed
Labels: -Crash bulkmove Stability-Crash
Chrome Version       : &lt;4.0.277.0 (35070)&gt;
URLs (if applicable) :http://localhost:631/admin (with cups installed)
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
  Firefox 3.x:Works fine.
IE 7:
IE 8:

What steps will reproduce the problem?
1.With cups installed, go to the above URL and click 'add printer'. 
2.
3.

What is the expected result?
Get to the admin page to add a printer.

What happens instead?
I get the &quot;Ah, snap&quot; error page consistently. 

Please provide any additional information below. Attach a screenshot if
possible.
I am running the google/chromium beta on an up-to-date Arch Linux system. 
Hardware is dual-core 64-bit AMD, 2 Gb memory, 320 Gb disk. In addition to 
the 'add printer' failure, I've seen this same symptom with other cups 
operations that work correctly with Firefox. I had one instance of trying 
to make this work with Chromium that killed X, but I can't tell you how to 
reproduce it.
Project Member

Comment 26 by bugdroid1@chromium.org, 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 27 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Mstone-6 M-6
Project Member

Comment 28 by bugdroid1@chromium.org, Mar 13 2013

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

Sign in to add a comment