[chromium-dev] WebKit Sheriff swap: 12/26-29 ?
I am currently scheduled to be on WebKit Sheriff duty 12/26 and 12/29, but will be on vacation from 12/21. Anyone able to swap? Thanks, ukai -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Compiling error after I did a 'gclient sync'
seems git.webkit.org/WebKit.git is out of sync? it only has r50565, but should have r50584 or later to build chromium. On Fri, Nov 6, 2009 at 11:42 AM, n179911 n179...@gmail.com wrote: On Thu, Nov 5, 2009 at 9:23 AM, Evan Martin e...@chromium.org wrote: On Wed, Nov 4, 2009 at 11:55 PM, Chase Phillips ch...@chromium.org wrote: FWIW I see the same error you see when I try to git clone the WebKit git repository again locally while git fetch on an existing repository works fine. I see you've mailed webkit-dev already, and I'm hoping someone there will be able to diagnose the problem. In the meantime, I recommend you use gclient sync to check out the WebKit source over Subversion so you're unblocked at least. Another option is to clone WebKit from some other git host. For example: git clone git://repo.or.cz/webkit.git You can then edit .git/config and change the origin URL to point at the canonical git.webkit.org, and run git fetch again, and it'll grab any newer data that didn't make it out to the mirror. Thanks. Chase, Evan. After webkit dev fixes their server problem, I try again using 'tools/sync-webkit-git.py', But I am getting a different error this time. And I have tried using 'git://repo.or.cz/webkit.git instead. That does not solve my problem either. $ tools/sync-webkit-git.py Desired revision: r50584. r50584 not available; fetching. remote: Counting objects: 948, done. remote: Compressing objects: 100% (350/350), done. remote: Total 731 (delta 469), reused 614 (delta 361) Receiving objects: 100% (731/731), 1011.18 KiB | 170 KiB/s, done. Resolving deltas: 100% (469/469), completed with 97 local objects. From git://git.webkit.org/WebKit 5af4058..968141f master - origin/master ERROR: Couldn't map r50584 to a git revision. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Change to default build architecture
On x86_64 machine, I couldn't build even if I clobber.. /usr/bin/ld: skipping incompatible /usr/local/google/home/ukai/src/chromium1/src/sconsbuild/Release/lib/libnpGoogleNaClPluginChrome.a when searching for -lnpGoogleNaClPluginChrome /usr/bin/ld: cannot find -lnpGoogleNaClPluginChrome collect2: ld returned 1 exit status Is this known issue? It is fine with GYP_DEFINES=target_arch=ia32, of course. -- ukai On Fri, Oct 16, 2009 at 9:28 AM, Michael Moss mm...@chromium.org wrote: http://codereview.chromium.org/271113 may require a clobber for Linux builds. The default build used to be 32-bit, but it will now be whatever your build host architecture is. If you are on a 64-bit machine, and haven't explicitly been setting 'target_arch' in gyp, your build will switch from 32-bit to 64-bit. If this breaks anything, clobbering or moving your existing build directory should fix it. If you want to continue building 32-bit on 64-bit hosts, you can force it by setting GYP_DEFINES=target_arch=ia32 in the environment. Michael --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
2009/6/26 Michael Nordman micha...@google.com
2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in
the webkit doc too.
Sure. I've added a diagram in webkit part.
* Does WebSocketHandle really need to be refcounted. I know
ResourceHandle is a refcounted object and this design looks modeled off of
that (which may be why you've spec'd it this way). Unless your design
actually needs refcounting on this class, you may be able to simplify things
without it. From the looks of it, WebSocketChannel 'owns' the
WebSocketHandle.
Yes. I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
Thanks.
I was suggesting that perhaps the WebSocketHandle does not need to be
refcounted.
Oh, sorry. I changed it to OwnPtr.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made
a good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a good
thing to put it in WebSocketChannel so its shared core common code goodness.
I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?
I haven't read the web sockets spec, so I don't know what the
'handshaking' entails?
It looks something similar like HTTP request/response.
see http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol more
details.
OS level socket creation/destruction and tcp connection opening/closing
needs to be per-platform. Once you have a full-duplex connection and are
sending application 'protocol' data back and forth (message framing), that
probably wants to be common code. Which camp does the 'handshaking' fall
into?
Hmm, maybe we need to move construction of request in web socket handshake,
and verification of response in web socket handshake. Updated.
Thanks!
ukai
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
Sure. Fixed.
Thanks!
ukai
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏)
u...@chromium.org wrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and
write design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
Hi, Thanks for review. 2009/6/25 Jeremy Orlow jor...@chromium.org I only skimmed, but it looks well thought out. One question though: is this going to be functional for non-Chromium browsers? Given that your design doc mentions v8 and hooks into Chromium's network stack, but no mention of JavaScriptCore or WebKit's resource loading code, I'm worried that the answer is no. I strongly recommend that your design doc include details for full integration into normal WebKit and that you offer to write the necessary code. If it's Chromium only, you'll definitely get more push back on the design and people will be less willing to review. Probably to the extent that it would have been easier to just write the code to begin with. v8 and hooks into chromium's network stack was written in chromium part only. I planed to send webkit part to webkit-dev. I've mentioned what platform code is required in WebSocketHandle in webkit part design doc. I just added JavaScript binding section. Do we need more detailed information for these part? Thanks, ukai J On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Thanks, ukai --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
Sure. I've added a diagram in webkit part.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
Yes. I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
Thanks.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any code
you want to be shared code shouldn't be slated for that class. To the extent
the 'web socket protocol framing' can be done indepedent of the 'platform'
socket handle (which it looks like it can be), it would be a good thing to
put it in WebSocketChannel so its shared core common code goodness.
I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
Sure. Fixed.
Thanks!
ukai
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏)
u...@chromium.orgwrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
Hi,
2009/6/25 Drew Wilson atwil...@google.com
BTW, I checked in with IanH - it sounds like WebSockets are also on the
Worker roadmap, so that's something to keep in mind while you iterate on
your design.
Ok, I see.
+1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
common code as possible cross-platform - I'm looking at the Chromium worker
code now, and there's a chunk of duplicated logic from the WebKit worker
implementation, which is a bit of a maintenance headache.
Sure.
--
ukai
-atw
2009/6/24 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a good
thing to put it in WebSocketChannel so its shared core common code goodness.
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
wrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and
write design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
2009/6/25 Chris Evans cev...@google.com On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Interesting feature :) It's hard to tell at first glance, because the security section is empty -- but it appears like security has been considered at least in http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17. It might be worth being more explicit about security in our WebKit doc (i.e. creating a new security section). Ok, I added the security section. Anyway, the websocket protocol doc has security considerations section, but no information there yet.. Possible tests we'll want include: - Connect a web socket to some ordinary HTTP server and confirm that the connect fails. - Connect a web socket to a real web socket server that fails to return a websocket-origin header, and validate that the connect fails (if it didn't, a simple server bug could open up responses to all origins) - Check we respect the origin sent from the server. - What about redirectors? Assuming unsupported, verify that connecting to a redirector does not cause any redirection. - URL integration: what happens if a ws:// or wss:// URL is entered into the URL bar, or any other place an URL is accepted? (img tags, script tags etc). - What about embedded newline characters in the various strings the client gets to specify (URL, resource name, protocol etc). Ensure that no lines sent to the server can be caused to be split by doing this. - Length encoding: ensure we handle excessively long length encodings, e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that happen to be negative (or very large) when assigned to int32, int64, uint32, uint64. - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted ws:// channel, if that cookie was marked Secure. Similar test for Authorization headers. Thanks for valuable test cases! We'll test these case. Thanks, ukai Cheers Chris Thanks, ukai --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
Hi,
2009/6/25 Hironori Bono (坊野 博典) hb...@chromium.org
Hi Ukai-san,
ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
ViewHostMsg_WebSocketOpen: open a new Web Socket. called by
WebSocketHandle::connect().
int request_id // idenfity WebSocket object {GURL url, std::wstring
protocol, std::wstring origin, bool secure, [...]}
ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web
Socket connection. called by WebSocketHandle::send().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection.
called by WebSocketHandle destructor.
int request_id // Identify WebSocket object
ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
ViewMsg_WebSocketConnect: New Web Socket connection is established. will
call WebSocketHandle::client()-didConnect().
int request_id // Identify WebSocket object
ViewMsg_WebSocketRecv: a frame containing data is received on the Web
Socket connection. will add data into WebSocketHandle::bufferedData().
Process all complete Web Socket frames, call
WebSocketHandle::client()-didReceive().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other
side). will call WebSocketHandle::client()-didClose().
int request_id // Identify WebSocket object
I'm a little wondering whether these messages are async messages or
sync ones. Is it possible to add notes about their message types?
Yes. I think all of these messages are routed and async messages.
Thanks for pointing it out.
--
ukai
Regards,
Hironori Bono
E-mail: hb...@chromium.org
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: HTML5 Web Socket design doc
2009/6/26 John Abd-El-Malek j...@chromium.org
2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in
the webkit doc too.
Sure. I've added a diagram in webkit part.
* Does WebSocketHandle really need to be refcounted. I know
ResourceHandle is a refcounted object and this design looks modeled off of
that (which may be why you've spec'd it this way). Unless your design
actually needs refcounting on this class, you may be able to simplify things
without it. From the looks of it, WebSocketChannel 'owns' the
WebSocketHandle.
Yes. I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
Thanks.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made
a good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a good
thing to put it in WebSocketChannel so its shared core common code goodness.
I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
The WebKit API classes still derive from WebCore, which isn't possible.
The WebKit API is an abstraction around WebCore classes, so it can't use
any WebCore types in it.
Ah, Ok. I updated WebKit API part not to use WebCore classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
hmm, I actually find WebWeb very unwieldy. I vote for
WebKit::WebSocketHandle.
Ok. will use WebKit:;WebSocketHandle.
Thanks!
ukai
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
Sure. Fixed.
Thanks!
ukai
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏)
u...@chromium.org wrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and
write design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] HTML5 Web Socket design doc
Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Thanks, ukai --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: chrome always break in debugger when run under XCode
Hi,
You should check the code just before logging::LogMessage::~LogMessage().
In this case, you hit DCHECK(!update_in_progress_) in
safe_browing_service.cc at line 466, so that DCHECK breaks here. Because of
DCHECK, I think SafeBrowsingService::UpdateStarted() expects it never called
when update_in_progress_ is true, but the assumption is failed.
--
Fumitoshi Ukai
On Sun, Jun 7, 2009 at 11:48 AM, Nathan Summer
nathan.charles.sum...@gmail.com wrote:
Hi,
I compile chrome and run under XCode.
But it breaks here, can you please tell me why? And what does BreakDebugger
do?
// static
void DebugUtil::BreakDebugger() {
#if defined(ARCH_CPU_ARM_FAMILY)
asm(bkpt 0);
#else
asm(int3);
#endif
}
Here is the stack trace:
#0 0x0058c43f in DebugUtil::BreakDebugger at debug_util_posix.cc:116
#1 0x005ad984 in logging::LogMessage::~LogMessage at logging.cc:545
#2 0x0040e751 in SafeBrowsingService::UpdateStarted at
safe_browsing_service.cc:466
#3 0x003e7c4a in SafeBrowsingProtocolManager::IssueUpdateRequest at
protocol_manager.cc:486
#4 0x003e7cc9 in SafeBrowsingProtocolManager::GetNextUpdate at
protocol_manager.cc:157
#5 0x003ed24a in DispatchToMethodSafeBrowsingProtocolManager, void
(SafeBrowsingProtocolManager::*)() at tuple.h:412
#6 0x003ed28d in base::BaseTimerSafeBrowsingProtocolManager,
false::TimerTask::Run at timer.h:160
#7 0x005b07c3 in MessageLoop::RunTask at message_loop.cc:309
#8 0x005b0b87 in MessageLoop::DeferOrRunPendingTask at message_loop.cc:317
#9 0x005b0d0a in MessageLoop::DoDelayedWork at message_loop.cc:450
#10 0x005bb154 in base::MessagePumpLibevent::Run at
message_pump_libevent.cc:228
#11 0x005b18bb in MessageLoop::RunInternal at message_loop.cc:198
#12 0x005b18d7 in MessageLoop::RunHandler at message_loop.cc:181
#13 0x005b1962 in MessageLoop::Run at message_loop.cc:155
#14 0x005f30a9 in base::Thread::ThreadMain at thread.cc:156
#15 0x005c72c4 in ThreadFunc at platform_thread_posix.cc:26
#16 0x92129155 in _pthread_start
#17 0x92129012 in thread_start
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
