gflags检测程序heap问题

经常遇到一很郁闷的事情:发布给外部客户使用的程序crash了,把dump文件丢过来,对上pdb之后发现显示的调用栈莫名奇妙,或者是一个stl::vector的push_back调用,要么是在一个malloc分配内存或者new创建对象,甚至可能是一个字符串赋值;这些从代码上看怎么看都不应该导致程序crash的,这时候一般就是程序写内存越界,堆被破坏,导致显示的调用栈异常了。怎样才能确定导致程序异常的实际代码行呢? 用windows的debug... Read More | Share it now!

chromium进程间通信

因为chromium是多进程的架构,因此需要一种可靠的进程间通信机制。chromium在Windows上的进程间通信是基于命名管道实现的。异步的命名管道通信模式确保不会阻塞通信的双方。 browser中的IPC 在browser进程中,与renderers进程通信是在独立的I/O线程里。跟views的来往消息会通过主线程的ChannelProxy。这种架构的优势是资源请求等性能要求较高的消息会直接在I/O线程里处理了,不会导致UI的阻塞。 renderer中的IPC 每个renderer进程的主线程管理消息通信,大多数消息会调度到renderer线程去处理。 消息的类型 Chromium处理进程间通信类似于MFC/WTL的那套消息映射机制。一个进程创建一个IPC消息,然后打包上参数,发送到接收的进程。这里有两种类型的IPC消息,routed消息和control消息。两者的差别是发送routed的消息的时候需要一个routing_id参数,通过这个routing_id才能发送到正确的接收方。一般跟view或者frame概念相关的类才有routing_id。 举个例子,我要从主进程发送一个ViewMsg_ClosePage消息到渲染进程,通知它关闭某个网页。往往一个渲染进程里面存在多个RenderView对象,到底该哪个对象来处理ViewMsg_ClosePage消息呢。这种情况下需要用routed消息的routing_id参数来控制将消息传递到正确的RenderView里面。 control消息不带有routing_id参数,并不意味着RenderView、RenderFrame这样的类不能处理control消息。消息都可以自定义参数,你完全可以把routing_id加到control消息里面。但是通常的做法是routed消息是跟网页有关的,其他的情况则用control消息。 从另一个角度来看,IPC消息又可以分为同步消息跟异步消息。使用同步消息的时候应当特别注意,这可能会导致浏览器阻塞。应当尽量避免使用同步消息,事实上Chromium里面使用到同步消息的场景也很少。 声明消息 我们可以在各种*_messages.h的头文件看到IPC消息的定义。通过IPC_MESSAGE_ROUTED*、IPC_MESSAGE_CONTROL*这类的宏来定义异步消息。比如处理0个参数的消息,定义成IPC_MESSAGE_*0,处理2个参数的消息定义成IPC_MESSAGE_*2。 一些简单的参数类型,可以直接的打包到消息里面,比如: Chromium内部已经可以支持直接序列化GURL、base::FilePath、base::Time等类型了。更多支持直接序列化的类型,可以从ipc_message_utils.h文件中看到。只要某个类型T有sruct... Read More | Share it now!

熟悉chromium代码目录结构

很多项目结构都已发生了改变,可能与最新的项目结构不一致。 高层次概述 chromium可以分为三大部分:浏览器,渲染器,webkit。浏览器是主进程,代表着所有的UI和I/O。渲染器(通常)是每个标签对应一个子进程,被浏览器驱动着。它嵌入webkit用来布局和渲染。 sln文件的快速入门 chrome.sln 启动代码在... Read More | Share it now!

Chromium显示网页

原文链接:http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-chrome 概念应用层 每个框代表一个概念应用层。没有一层需要知道或者依赖他的上层。 WebKit:渲染引擎。Port是一个集成平台相关的系统服务的部分,比如资源加载和图像。 Glue:转换webkit类型到chromium类型。 Renderer... Read More | Share it now!