log with crash id
ivan@laptop$ google-chrome 
--2011-09-16 20:47:02--  https://clients2.google.com/cr/report
Resolving clients2.google.com... 209.85.169.101, 209.85.169.138, 209.85.169.113, ...
Connecting to clients2.google.com|209.85.169.101|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `/dev/fd/3'

    [ <=>                                                                                                                           ] 16          --.-K/s   in 0s      
Crash dump id: 

b01f339e4c7add21
2011-09-16 20:47:04 (413 KB/s) - `/dev/fd/3' saved [16]

Segmentation fault

upgraded to 14.0.835.163-r101024 still got a crashes

I've been receiving similar error messages and it looks like mine is working at the moment.

I received:
ERROR:nss_ocsp.cc(581)] No URLRequestContext for OCSP handler.

Try running: google-chrome www.google.com

I found that after running google-chrome www.google.com, it worked normally without any parameters and didn't segfault as it was doing before.

During my troubleshooting of another error message, I encountered the No URLRequestContext error.  I noted my troubleshooting steps in this thread:  http://www.google.com/support/forum/p/Chrome/thread?tid=3a8d80ce9606e959&hl=en

From that crash id (b01f339e4c7add21), it looks like the crash is happening inside tcmalloc during a DNS resolution. 

@willchan/agl: does this look familiar to you? Crash is happening inside __gethostbyname2_r:


0x099382c3	 [chrome	 - third_party/tcmalloc/chromium/src/central_freelist.cc:249]	tcmalloc::CentralFreeList::FetchFromSpans
0x099385e1	 [chrome	 - third_party/tcmalloc/chromium/src/central_freelist.cc:234]	tcmalloc::CentralFreeList::FetchFromSpansSafe
0x0993865d	 [chrome	 - third_party/tcmalloc/chromium/src/central_freelist.cc:214]	tcmalloc::CentralFreeList::RemoveRange
0x0993518a	 [chrome	 - third_party/tcmalloc/chromium/src/thread_cache.cc:149]	tcmalloc::ThreadCache::FetchFromCentralCache
0x09dcb587	 [chrome	 - third_party/tcmalloc/chromium/src/thread_cache.h:346]	tc_malloc
0x0733e806	 [libnss_hoof.so.2	 + 0x00000806]	
0x011af5b1	 [libc-2.13.so	 - ../nss/getXXbyYY_r.c:256]	__gethostbyname2_r
0x01170078	 [libc-2.13.so	 - ../sysdeps/posix/getaddrinfo.c:531]	gaih_inet
0x0117084a	 [libc-2.13.so	 - ../sysdeps/posix/getaddrinfo.c:2161]	getaddrinfo
0x0939c1cd	 [chrome	 - net/base/host_resolver_proc.cc:199]	net::SystemHostResolverProc
0x09395bb2	 [chrome	 - net/base/host_resolver_impl.cc:174]	net::ResolveAddrInfo
0x09395c02	 [chrome	 - net/base/host_resolver_impl.cc:544]	net::HostResolverImpl::Job::DoLookup
0x09395880	 [chrome	 - ./base/tuple.h:558]	RunnableMethod<net::HostResolverImpl::Job, void (net::HostResolverImpl::Job::*)(const base::TimeTicks&, uint32), Tuple2<base::TimeTicks, unsigned int> >::Run
0x098965c7	 [chrome	 - base/threading/worker_pool_posix.cc:80]	base::::WorkerThread::ThreadMain
0x09894bab	 [chrome	 - base/threading/platform_thread_posix.cc:51]	base::::ThreadFunc
0x0025ee98	 [libpthread-2.13.so	 - pthread_create.c:304]	start_thread
0x0119773d	 [libc-2.13.so	 + 0x000d073d]

The path for libnss here looks unusual, perhaps this specific version of NSS could be the problem:

/home/XXXXX/.rvm/gems/ruby-1.9.2-p180/gems/hoof-0.0.7/ext/libnss_hoof.so.2

The only other issue I am aware of if stack overflows in getaddrinfo() when using large rules in /etc/hosts, but doesn't look like that is the issue here.

The bug looks like memory corruption, hence the crash in TCMalloc =/

Closing the bug for now due to inactivity. Please feel free to raise a new bug, if encountered with similar issue again.
Thank you!