Make Everyday Count

人如果没有梦想, 那和咸鱼有什么分别

先看这篇帖子: http://www.linuxproblem.org/art_9.html 其中的最下面的 note 要注意: Depending on your version of SSH you might also have to do the following changes: Put the public key in .ssh/authorized_keys2 Change the permissions of .ssh to 700 Change the permissions of .ssh/authorized_keys2 to 640 如果还是提示要密码. 尝试看看 log sudo grep -ir ssh /var/log/* 我的机器上遇到这个 error: /var/log/secure:Jun 20 19:07:54 CT53-64-BASE sshd[28890]: \...

最近在写一个 chrome 的扩展, 但发现有问题, 行为和文档表述的不一样, 所以想调试一下 chromium 看问题出在哪里. 所以在 mac 下试着编译了一下 chromium. 首先是把代码弄下来. 我按照文档的建议, 下载了一个 tar 包, 解压之后用 gclient 更新代码到最新的 green revision (也就是没有编译错误 基本上没有问题的版本) gclient config http://src.chromium.org/svn/trunk/src http://chromium-status.appspot.com/lkgr gclient sync gclient sync 可能花了将近 1 个小时的时间. 然后就是编译. 之前看文档说 xcode 似乎会创建多个 ld 进程进行链接从而导致整个机器都没有响应. 所以我也按照文档的建议用了一个脚本来限制 ld 的数量 (因为我的 mbp 是 4 核, 所以限制为...

这几天一直在忙着调试 crash 的问题。周末两天都在加班。 周日更是从早上8：00 到晚上 12：50 一直没离开过办公室. 加上这个项目对我们整个开发组以及 EM 都很重要，不容有失，这不禁让我想起了微软 NT 开发组开发 NT 的情形，所以有了这个标题. 这次是在 android 上，但不是 arm，而是 x86 atom。我们的程序是从 windows 上移植到 android 上的, 一个 C++ 写的底层库作为 service，UI 是 java 写的。 因为是在 android 2.2 上，java 也是唯一的写 UI 的选择。 java 通过 aidl/jni 与底层 service/c++ 代码交互。这样的架构让调试很悲剧。 之前一直抱怨 xcode 调试多么不给力，而现在在 android 上的调试已经原始到通过 log...

最近我把机器的 system locale 切换成英文. 运行 Connect® 的时候遇到了一些以前没有遇到过的问题. 比如这个 子类化和unicode 之间的联系问题.

RSA 的相关操作 创建密钥 D:\Temp>openssl genrsa -out pri.pem 1024 Loading 'screen' into random state - done Generating RSA private key, 1024 bit long modulus ..................++++++ ...........................++++++ e is 65537 (0x10001) D:\Temp>type pri.pem -----BEGIN RSA PRIVATE KEY----- MIICXAIBAAKBgQDK7TIBRai7Xq6dwU9IxbmvIh47nt6VPZ+OwSJv32xTieGNS5TS FPF6q5piSkuqCalJPoyWn39+AzvgKRFLi+rCgeByLu8ijPX/VgujLkKp/VPCaXx5 Okf36HxxUbu6ODw0H8z8ARlnoXz+L2dT5XdhC/7PDsodawCFCohbTjzmEwIDAQAB AoGAA03HUaP7sklBWIosK0gk1Mgea+QTRaTCM0XLtLyTe+yzwmQnoR/8Kn4evljt UHBl1C5zhYRFRBzzXZvtjyhRAyBBLMI+Jwmju0oPPLlXJzURQZxP2+5ivwxwUu/I iCSoWCbr9IAcUOPJHGSG275kJ9IQCa9lSWlCiUjmCyZn1MECQQDxPZpzPHEx184J xxqaXtykZz1ju98i/I4zcl1sxJ6mAnvGzBZ2fmyW5kzOWWDisstesO7PzEuJCGAG DWClBBQhAkEA11eAx7cvIGREisMGo8EfG98pPBpGidDya4htmcGfPp1VrLYtvju6 9P7HDy4IyLrv1iAcXP0lfEDzfRV6rFhzswJAaysMxAij2JqgI2PaA54EstxSP04k sGw119EEg99NAz6zMftUN0uufdLNaBX4nn0DL4u2a4W8QKIB1m528pe/QQJBAKt5 GCjwK2ylqxa7uZvH+ledWh5r5eN0KLWMC4o17fJUIpbG8qHaukLAZg4mYARHJxfg tfUt9x18MudVpTt7q5UCQH53YfdJ1OON7RnFYVrlXKY5CK+PqJ/E1zykWSzRE12j IkngPoZV3MkAuA9UU+vsUn6b9YYvqyT2ETKM1orRp+k= -----END RSA...

手头有这么一个 bug，当启用 application verifier 之后，用键盘 navigate 菜单时会 crash。我在自己的机器上没能重现。 今天终于找到机会登陆到 qa 的机器上查这个问题。不错，在她的机器上能够很稳定的重现。 先把 pdb 下载下来添加到本地 symbol server, 在 qa 的机器上设置好 _NT_SYMBOL_PATH 环境变量。直接把 windbg 打开，开始调试。 这是 crash 的时候的调用栈等信息： apMenu!CSkinMenu::GetCurSel+0x4: 22ec57df ff761c push dword ptr [esi+1Ch] ds:0023:28b7afc4=???????? 0:000> kL ChildEBP RetAddr 0012f224 22ec6772 apMenu!CSkinMenu::GetCurSel+0x4 0012f2d4 22ec9154 apMenu!CSkinMenu::WindowProc+0x282 0012f304 76e11a10 apMenu!CSubclassWnd::HookWndProc+0x90 0012f330 76e11ae8 USER32!InternalCallWinProc+0x23...

bug 描述是这样的: client crashed when user tries to start it. 一启动程序就 crash. 这个 bug 有些奇怪, 只在 chellon 一台机器上出现, freq 100%. 用 windbg 查看 crash 生成的 dump 文件. 0:000> k *** Stack trace for last set context - .thread/.cxr resets it ChildEBP RetAddr 0012f504 77d8867b apSMD!ObjectMap+0x30 0012f56c 77d8961e user32!UserCallWinProcCheckWow+0x150 0012f5c0 77d8e331...

At the very beginning, as I mentioned in the bug comments: ‘dump reveals that crash occurred when try to allocate memory. it’s a indication of heap corruption. Enable the heap option in application verifier, reproduce this bug, crash occurs earlier. I found that the CWclManager object gets deallocated when handling...

你拿到了一个 crash dump 文件, 之前你部署了你自己的 symstore, 所以, 你可以轻而易举的看到完美的调用栈. 如果只是一个简单的访问违例, 你看到调用栈的时候基本上问题就已经解决了. 但是, 更多的时候问题不是这么简单. 你不得不查看底层的调用栈来查看每个参数是如何传进来的. 但这时, 你也发现要查看每一个调用的参数并不是那么简单. 为什么会出现这种情况呢? 原因在于优化. 在调试中遇到的比较烦的优化包括 inline, FPO 等, 这里我要说的是 this 指针丢失. 教科书里说 C++ 传递 this 指针一般是作为最后一个参数. 压栈传到 callee 中. 但现实生活中更多的是用 ecx 来传递 this 指针, 这样就有一个问题. ecx 每次会调用时都会被覆盖. 就像这样: DemoFunc: mov ecx, pOneObj call OneMemberFunc ... OneMemberFunc: mov...