一个有意思的bug fix，能够体现出对代码熟悉的程度与水平
这个是访问一个网站直接crash。
IntPoint.h:80 IntPoint
RenderLayerCompositor.cpp:695 WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer*, WTF::HashMap
RenderLayerCompositor.cpp:835 WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer, WTF::HashMap
RenderLayerCompositor.cpp:835 WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer, WTF::HashMap
RenderLayerCompositor.cpp:315 WebCore::RenderLayerCompositor::updateCompositingLayers(WebCore::CompositingUpdateType, WebCore::RenderLayer)
FrameView.cpp:590 WebCore::FrameView::updateCompositingLayers()
FrameView.cpp:991 (discriminator 6)WebCore::FrameView::layout(bool)
Document.cpp:2180 WebCore::Document::implicitClose()
FrameLoader.cpp:877 WebCore::FrameLoader::checkCompleted()
Timer.h:100 (discriminator 3) WebCore::TimerWebCore::HTMLMediaElement::fired()
ThreadTimers.cpp:109 (discriminator 3)WebCore::ThreadTimers::sharedTimerFiredInternal()
JavaBridge.cpp:374 android::JavaBridge::SharedTimerFired(_JNIEnv*, _jobject*)
CallEABI.S:258 dvmPlatformInvoke
Jni.cpp:1159 dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)
CheckJni.cpp:145 dvmCheckCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)
InterpAsm-armv7-a-neon.S:16314dalvik_mterp
Mterp.cpp:105 dvmMterpStd(Thread*)
Interp.cpp:1961 dvmInterpret(Thread*, Method const*, JValue*)
Stack.cpp:526 dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)
Stack.cpp:429 dvmCallMethod(Thread*, Method const*, Object*, JValue*, …)
Thread.cpp:1542 interpThreadStart
pthread_create.cpp:105 __thread_entry
pthread_create.cpp:224 pthread_create
其实要多说一句，有的时候，由于deadline的存在，对不熟悉的code 提交patch的优劣程度是研究的时间来决定的。如果时间充足，把出问题部分的代码上下文debug清楚，对于patch的质量肯定是有提高的，但是如果时间不够充足，只能采用时间范围内能够找到的最优方案。
webkit是一个庞大的代码库，即使我在工作中经常读到或者debug到的code也不会超过10%，比较熟悉的部分不会超过5%。
下面是面对一个crash之后的两次分析。
Update zorder list when renderlayer is destroyed In some cases, renderlayerlayer is destroyed or removed from parent,but the parents’ zorder list is not update. In compositing operations,invalid renderlayer is used and cause crash.
RenderLayer* RenderLayer::removeFromZorderList(RenderLayer* layer){
RenderLayer* parent = layer->parent();
while (parent) {
if (parent->m_posZOrderList) {
for (unsigned i = 0; i < parent->m_posZOrderList->size(); ++i) {
if (parent->m_posZOrderList->at(i) == layer) {
parent->m_posZOrderList->remove(i); break;
}
}
}
if (parent->m_negZOrderList) {
for (unsigned i = 0; i < parent->m_negZOrderList->size(); ++i) {
if (parent->m_negZOrderList->at(i) == layer) {
parent->m_negZOrderList->remove(i); break;
}
}
}
parent = parent->parent();
}
return 0;
}
问题解决了，也没什么问题，但是，这个是最好的solution么？其实，再深入的debug，把这个函数如何被调用起来的上下文彻底搞清楚才会找到root cause，找到root cause才能找到最优的solution.
When the style of an element changes it might mean that a layer becomes a stacking context, which it was not before. It is then important that the zorder lists of the previous stacking context are updated.
void RenderObject::styleWillChange(StyleDifference diff, const RenderStyle* newStyle) {
if (m_style) {
// If our z-index changes value or our visibility changes,
// we need to dirty our stacking context’s z-order list.
if (newStyle) {
#if ENABLE(COMPOSITED_FIXED_ELEMENTS)
RenderLayer* layer = hasLayer() ? enclosingLayer() : 0;
if (layer && m_style->position() != newStyle->position() && (m_style->position() == FixedPosition || newStyle->position() == FixedPosition)) {
layer->dirtyZOrderLists(); layer->dirtyStackingContextZOrderLists();
}
#endif