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

Issue 13226 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Email to this user bounced
Closed: Jun 2009
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

https crashes

Reported by flystart...@gmail.com, Jun 3 2009

Issue description

Chrome Version       : <Copy from: 'about:version'>
URLs (if applicable) :
https://www.grao.bg/elections/secure/personal/home.asp
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 4:
  Firefox 3.x: OK
IE 7:
         IE 8: OK

What steps will reproduce the problem?
1. Just open the URL provided

What is the expected result?

To open the web page

What happens instead?

Chrome crashes

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

 
Sorry, the exact procedure to reproduce the crash is to open 
http://www.grao.bg/elections/#query and then click on any of the two bottom links of 
the left navigation:

Личен Достъп
Служебен Достъп
Google Chrome version 3.0.182.3

Comment 3 by tony@chromium.org, Jun 4 2009

Status: Assigned
Looks like all https is crashing us now.  Stacktrace:

#0  0x092bd50c in GetCertChainInfo (cert_list=0x0, verify_result=0xf17e3b88)
    at net/base/x509_certificate_nss.cc:159
#1  0x092bd908 in net::X509Certificate::Verify (this=0xf17e6cd0, 
    hostname=@0xf17e3b54, rev_checking_enabled=false, 
    verify_result=0xf17e3b88) at net/base/x509_certificate_nss.cc:474
#2  0x0935173d in net::CertVerifier::Request::DoVerify (this=0xf17e3b48)
    at net/base/cert_verifier.cc:42
#3  0x0935133e in DispatchToMethod<net::CertVerifier::Request, void
(net::CertVerifier::Request::*)()> (obj=0xf17e3b48, 
    method=0x93516fc <net::CertVerifier::Request::DoVerify()>, 
    arg=@0xf17db764) at ./base/tuple.h:412
#4  0x09351379 in RunnableMethod<net::CertVerifier::Request, void
(net::CertVerifier::Request::*)(), Tuple0>::Run (this=0xf17db748) at ./base/task.h:307
#5  0x093dcaa6 in ThreadMain (this=0xf1761828) at base/worker_pool_linux.cc:78
#6  0x08efb2b6 in ThreadFunc (closure=0xf1761828)
    at base/platform_thread_posix.cc:26
#7  0xf77154fb in start_thread () from /lib32/libpthread.so.0
#8  0xf73d309e in clone () from /lib32/libc.so.6

Comment 4 by tony@chromium.org, Jun 4 2009

Labels: -Pri-2 -OS-All -Area-Misc Pri-1 OS-Linux Area-BrowserBackend
Summary: https crashes

Comment 5 by marky...@gmail.com, Jun 5 2009

works here on linux r17763

Comment 6 by tony@chromium.org, Jun 5 2009

The above link works for me on linux too.  However, the following crashes:

1) go to www.google.com
2) click on "About Google"

I think get the crash in comment 3.

Comment 7 by wtc@chromium.org, Jun 5 2009

goo...@kolko.bg: I can't reproduce this crash.  Could you paste the output of the
following commands?

  uname -a
  ident /usr/lib32/libnss3.so
  ident /usr/lib/libnss3.so

What Linux distribution are you using?

Comment 8 by tony@chromium.org, Jun 5 2009

Status: Invalid
Per wtc's suggestion, I re-ran build/install-build-deps.sh and it installed a new 
libnss on my machine:
Installed libnss3-1d-ia32_3.12.0.3-0ubuntu0.8.04.4gg2_amd64.deb

Now everything works fine.

Closing the bug as invalid.  goo...@kolko.bg: If you still have a problem with a newer 
libnss, can you comment and I will reopen the bug.

Comment 9 by pall...@gmail.com, Jun 6 2009

I can reproduce the crash on Windows XP with Chrome 3.0.183.1:

1. Go to http://www.grao.bg/elections/
2. Click on the Личен Достъп link
3. Confirm the security exception
4. Click on the back button then the forward button

Comment 10 by pall...@gmail.com, Jun 6 2009

Crash dump attached
Chrome-last.dmp
48.3 KB Download
I am using the Google Chrome browser under widnows XP so not much I can do about new 
libs, etc.

Comment 12 by wtc@chromium.org, Jun 8 2009

Labels: -Pri-1 -OS-Linux -Area-BrowserBackend Pri-2 OS-Windows Area-Misc
Status: Unconfirmed
OK, there was a confusion about what this bug is.
Everyone, please ignore comments 3-8, which are about
a crash on Linux.  That crash was in a piece of code
used only on Linux, so it is unrelated to the original
crash reported by goo...@kolko.bg and the crash reported
by pallosp in comments 9-10, both on Windows XP.

Comment 13 by wtc@chromium.org, Jun 8 2009

Labels: -Area-Misc Area-BrowserBackend
Status: Assigned
I can reproduce the crash on Windows following pallosp's
instructions in comment 9.

In a debug build, there are two DCHECK (assertion) failures
in HttpNetworkTransaction::DoWriteHeaders() and
SSLClientSocketWin::DoPayloadEncrypt() (because we are trying
to write 0 bytes of data incorrectly) after I clicked the
"Proceed anyway" button.

Both the DCHECK failures and the crash have to do with our
handling of SSL renegotiation when the server certificate
has errors.

The call stack of the crash is:

 	chrome.dll!DebugUtil::BreakDebugger()  Line 253	C++
 	chrome.dll!logging::LogMessage::~LogMessage()  Line 522	C++
>	chrome.dll!net::HttpCache::Transaction::OnNetworkInfoAvailable(int result=-
202)  Line 922	C++
 	chrome.dll!DispatchToMethod<net::HttpCache::Transaction,void (__thiscall 
net::HttpCache::Transaction::*)(int),int>(net::HttpCache::Transaction * 
obj=0x0419f480, void (int)* method=0x644c89d0, const Tuple1<int> & arg={...})  Line 
422 + 0x11 bytes	C++
 	chrome.dll!CallbackImpl<net::HttpCache::Transaction,void (__thiscall 
net::HttpCache::Transaction::*)(int),Tuple1<int> >::RunWithParams(const Tuple1<int> & 
params={...})  Line 571 + 0x1b bytes	C++
 	chrome.dll!CallbackRunner<Tuple1<int> >::Run<int>(const int & a=-202)  Line 
536 + 0x1c bytes	C++
 	chrome.dll!net::HttpNetworkTransaction::DoCallback(int rv=-202)  Line 397	
C++
 	chrome.dll!net::HttpNetworkTransaction::OnIOComplete(int result=-202)  Line 
403	C++
 	chrome.dll!DispatchToMethod<net::HttpNetworkTransaction,void (__thiscall 
net::HttpNetworkTransaction::*)(int),int>(net::HttpNetworkTransaction * 
obj=0x07306000, void (int)* method=0x64523070, const Tuple1<int> & arg={...})  Line 
422 + 0xe bytes	C++
 	chrome.dll!CallbackImpl<net::HttpNetworkTransaction,void (__thiscall 
net::HttpNetworkTransaction::*)(int),Tuple1<int> >::RunWithParams(const Tuple1<int> & 
params={...})  Line 571 + 0x17 bytes	C++
 	chrome.dll!CallbackRunner<Tuple1<int> >::Run<int>(const int & a=-202)  Line 
536 + 0x1c bytes	C++
 	chrome.dll!net::SSLClientSocketWin::DoCallback(int rv=-202)  Line 432	C++
 	chrome.dll!net::SSLClientSocketWin::OnIOComplete(int result=-202)  Line 438	
C++
 	chrome.dll!DispatchToMethod<net::SSLClientSocketWin,void (__thiscall 
net::SSLClientSocketWin::*)(int),int>(net::SSLClientSocketWin * obj=0x041894b0, void 
(int)* method=0x645522d0, const Tuple1<int> & arg={...})  Line 422 + 0xe bytes	C++
 	chrome.dll!CallbackImpl<net::SSLClientSocketWin,void (__thiscall 
net::SSLClientSocketWin::*)(int),Tuple1<int> >::RunWithParams(const Tuple1<int> & 
params={...})  Line 571 + 0x17 bytes	C++
 	chrome.dll!CallbackRunner<Tuple1<int> >::Run<int>(const int & a=-202)  Line 
536 + 0x1c bytes	C++
 	chrome.dll!net::CertVerifier::Request::DoCallback()  Line 85	C++
 	chrome.dll!DispatchToMethod<net::CertVerifier::Request,void (__thiscall 
net::CertVerifier::Request::*)(void)>(net::CertVerifier::Request * obj=0x075c2080, 
void (void)* method=0x645743e0, const Tuple0 & arg={...})  Line 412 + 0x8 bytes	C++
 	chrome.dll!RunnableMethod<net::CertVerifier::Request,void (__thiscall 
net::CertVerifier::Request::*)(void),Tuple0>::Run()  Line 307 + 0x1a bytes	C++
 	chrome.dll!MessageLoop::RunTask(Task * task=0x072ee060)  Line 309 + 0xf bytes	
C++
 	chrome.dll!MessageLoop::DeferOrRunPendingTask(const MessageLoop::PendingTask 
& pending_task={...})  Line 320	C++
 	chrome.dll!MessageLoop::DoWork()  Line 423 + 0xc bytes	C++
 	chrome.dll!base::MessagePumpForIO::DoRunLoop()  Line 446 + 0x19 bytes	C++
 	
chrome.dll!base::MessagePumpWin::RunWithDispatcher(base::MessagePump::Delegate * 
delegate=0x03eefb0c, base::MessagePumpWin::Dispatcher * dispatcher=0x00000000)  Line 
52 + 0xf bytes	C++
 	chrome.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * 
delegate=0x03eefb0c)  Line 78 + 0x1c bytes	C++
 	chrome.dll!MessageLoop::RunInternal()  Line 198 + 0x2a bytes	C++
 	chrome.dll!MessageLoop::RunHandler()  Line 182	C++
 	chrome.dll!MessageLoop::Run()  Line 156	C++
 	chrome.dll!base::Thread::ThreadMain()  Line 159	C++
 	chrome.dll!`anonymous namespace'::ThreadFunc(void * closure=0x01ef3140)  Line 
26 + 0xf bytes	C++
 	kernel32.dll!7685816c() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for 
kernel32.dll]	
 	ntdll.dll!76f82404() 	
 	ntdll.dll!76f82618() 	

This crash could be the same as the "reappeared" crash that laforge mentioned
in  issue 11646  (comments 9-10).
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=17919 

------------------------------------------------------------------------
r17919 | wtc@chromium.org | 2009-06-08 18:37:27 -0700 (Mon, 08 Jun 2009) | 14 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=17919&r2=17918
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.cc?r1=17919&r2=17918
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ssl_client_socket_win.h?r1=17919&r2=17918
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=17919&r2=17918

We don't handle certificate errors during SSL renegotiation.
In the common case, the server sends the same certificate during
renegotiation.  Since the certificate has been verified, we can
assume the certificate is good or has been accepted by the user.
If the server sends a different certificate that has an error,
we need to return an error code that won't trigger our
certificate error handling code, which doesn't handle this case
correctly.  Add the ERR_CERT_ERROR_IN_SSL_RENEGOTIATION error
for this purpose.

R=rvargas
BUG= http://crbug.com/13226 
TEST=See  http://crbug.com/13226  comment 9
Review URL: http://codereview.chromium.org/118410
------------------------------------------------------------------------

Comment 15 by wtc@chromium.org, Jun 10 2009

Status: Fixed
goo...@kolko.bg, pallosp:

Could you please verify my fix?

Please download build 17920 or later from
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/

Download chrome-win32.zip, extract all files, and run the chrome.exe file inside the 
chrome-win32 directory.

Thanks!
Yes, works as expected for me, thanks.

Comment 17 by wtc@chromium.org, Jun 10 2009

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

------------------------------------------------------------------------
r18171 | laforge@chromium.org | 2009-06-11 10:27:09 -0700 (Thu, 11 Jun 2009) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/172/src/net/base/net_error_list.h?r1=18171&r2=18170
   M http://src.chromium.org/viewvc/chrome/branches/172/src/net/base/ssl_client_socket_win.cc?r1=18171&r2=18170
   M http://src.chromium.org/viewvc/chrome/branches/172/src/net/base/ssl_client_socket_win.h?r1=18171&r2=18170
   M http://src.chromium.org/viewvc/chrome/branches/172/src/net/http/http_network_transaction.cc?r1=18171&r2=18170

Merge 17919 - We don't handle certificate errors during SSL renegotiation.
In the common case, the server sends the same certificate during
renegotiation.  Since the certificate has been verified, we can
assume the certificate is good or has been accepted by the user.
If the server sends a different certificate that has an error,
we need to return an error code that won't trigger our
certificate error handling code, which doesn't handle this case
correctly.  Add the ERR_CERT_ERROR_IN_SSL_RENEGOTIATION error
for this purpose.

R=rvargas
BUG= http://crbug.com/13226 
TEST=See  http://crbug.com/13226  comment 9
Review URL: http://codereview.chromium.org/118410

TBR=wtc@chromium.org

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

Works fine with Google Chrome 2.0.172.33 (Official Build )
Labels: -Area-BrowserBackend Area-Internals
Project Member

Comment 21 by bugdroid1@chromium.org, Mar 30 2011

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

------------------------------------------------------------------------
r79907 | derat@chromium.org | Wed Mar 30 15:38:18 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/chromeos/audio_mixer_alsa.cc?r1=79907&r2=79906&pathrev=79907

chromeos: Retry ALSA mixer initialization on failure.

There's a race at boot where Chrome can attempt to use ALSA
before its kernel modules have been loaded.  We previously
wouldn't retry the initialization in this case, resulting in
the volume keys not working until Chrome was restarted.

This change makes the mixer code retry on failure once per
second, up to twenty times.  I've typically seen the modules
get loaded 5-6 seconds after we start Chrome (although we
don't make it until this code until a bit later; I see one or
two failures before we succeed).

It would be good to also load the modules earlier, if we can
do so without impacting boot time -- if the volume keys are
pressed before the modules are loaded now, the "muted"
bubble still comes up.

BUG=chromium-os:13162
TEST=booted with my change from  issue 13226  and checked that the volume keys start working after a few seconds, and also that this doesn't block the UI (it's happening on its own thread)

Review URL: http://codereview.chromium.org/6760014
------------------------------------------------------------------------
Project Member

Comment 22 by bugdroid1@chromium.org, Oct 12 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 23 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Sign in to add a comment