fool

这次东南大学第四届嵌入式系统设计竞赛我的作品题目是嵌入式微博。这里把源代码全部释出，代码和文档均遵循Apache License。

下面是作品简介：

嵌入式微博是一个专门为嵌入式Linux设计的微博客户端，适合在小屏幕、低配置的设备上运行，系统配置要求极低。同时使用MiniGUI作为其图形库，可以适应非常广泛的设备，在低端产品实现富网络社交应用。本作品有下列特性：

1. 系统配置要求低，可用在小型低配置设备上流畅运行，同时使用MiniGUI绘图，可以确保适应绝大部分嵌入式系统。
2. 界面设计美观，全部UI均是手工精心绘制，一方面保证了作品的个性化和与同类产品的差异化，另一方面避免了大量使用丑陋古板的标准控件，同时还提升了整体界面的响应速度。
3. 专为小屏幕设备设计，考虑到小屏幕的特点而设计了专门的虚拟键盘，只要点击输入框就能调出虚拟键盘进行输入。虚拟键盘设计漂亮，功能强大，可以输入字母、标点、特殊符号，还带有一个简单但完善的全拼输入法。
4. 微博功能实现完备，支持发微博、转发消息、获取时间线、搜索话题、获取热门话题等常用微博操作，同时能完整展现富微博内容，可以完整漂亮的绘制头像、内容、转发消息、图片等，可以作为最终产品推出。
5. 微博内容绘制精美，同时做了大量的优化，可以保证在显示大量图片内容的情况下界面依然流畅。
6. 网络操作全部异步完成，在界面显示、操作流畅的同时，新开线程执行网络操作，在新的线程中下载、加载非常耗时的网络内容，让用户感觉不到网络的延迟。
7. 代码编写规范，整体模块化，可以很快适应之后的需求变更，能很快根据用户需求作出修改，开发出新产品。
8. 项目代码使用Autotools管理，非常适合Linux下开发，方便迁移至各种平台、架构下。

几张照片：

源码包：miniweibo-0.1.0.tar.gz

设计报告：嵌入式微博设计报告.doc

由于协议非常宽松，有同学想拿去用的话，请随意。也欢迎商业合作。

今天运气不错，解决了两个非常棘手的Bug，这一个是关于libcurl的。

我的程序在一个线程中执行主循环，需要从网络下载东西时，就开启另一个线程，执行curl_easy_perform。问题是，程序在执行一段时间后会自己崩溃掉，backtrack如下：

#0  0x4001e416 in __kernel_vsyscall ()
#1  0x40491941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x40494e42 in abort () at abort.c:92
#3  0x404c9305 in __libc_message (do_abort=2, 
    fmt=0x4059f36a "*** %s ***: %s terminated\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4  0x4054c970 in __fortify_fail (msg=<value optimized out>)
    at fortify_fail.c:32
#5  0x4054c8da in ____longjmp_chk ()
    at ../sysdeps/unix/sysv/linux/i386/____longjmp_chk.S:76
#6  0x4054c849 in __longjmp_chk (env=<value optimized out>, val=1)
    at ../setjmp/longjmp.c:40
#7  0x4020dd08 in alarmfunc () from /usr/lib/libcurl-gnutls.so.4
#8  <signal handler called>
#9  0x4001e416 in __kernel_vsyscall ()
#10 0x4004b930 in sem_wait@GLIBC_2.0 ()
    at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:318
#11 0x400fa7ac in PeekMessageEx (pMsg=0xbffff0b8, hWnd=134580240, 
    iMsgFilterMin=0, iMsgFilterMax=0, bWait=1, uRemoveMsg=1) at message.c:628
#12 0x0804b45f in GetMessage (this=0xbffff104)
    at /usr/local/include/minigui/window.h:1935
#13 WeiboUI::Application::run (this=0xbffff104) at application.cc:99
#14 0x08049df0 in MiniGUIAppMain (argc=1, argv=0xbffff274) at main.cc:56
#15 0x08049f4c in main (args=1, argv=0xbffff274) at main.cc:56

简单说明一下，就是主循环在执行sem_wait時，被一个信号打断，然后导致整个程序的崩溃。问题的关键就在那个alarmfunc ()，是libcurl打断了我的循环。

最后以alarmfunc为关键词搜索后才发现，原来libcurl居然使用alarm来实现超时的判断！在多线程环境里，alarm产生的信号会打断一切主循环，然后导致非常难以察觉的Bug。

解决方法很简单，把CURLOPT_NOSIGNAL设为1就行了，这样libcurl将不会产生任何信号：

http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTNOSIGNAL

这个Bug连着困扰了我六七个小时，而且表现神秘不定，我觉得很有必要把它详细地记录下来。

事情源于我正在编写的一个GUI库，底层基于MiniGUI，主要用在嵌入式Linux下显示图形界面。最开始的表现是，我在本机编译完成后跑得好好的程序，在交叉编译后放到arm板子上一启动就崩溃，而且诡异的是，崩溃的几率和我类的参数有关，最开始我在类的destructor前加上了virtual之后，崩溃消失了，然后我又在类里加了些变量，程序又崩溃了。而且本机上一点崩溃的迹象也没有。所以我一度认为这是交叉编译器的Bug，无奈。

之后事情终于有了转机，本机上编译的程序终于也崩溃了！可见，很多时候程序员们是多么渴望程序崩溃啊！

于是马上调出gdb，崩溃处的代码如下：

dskOnNewCtrlInstance (hWnd=1075427776, message=361, wParam=134576144,
lParam=134575776) at desktop-comm.c:2683
2683 pNode->hWnd = (HWND)pNewCtrl;

p pNode 发现pNode是0x00，找到你了！难道是MiniGUI的Bug？

再仔细观察代码：

if (pNewCtrl->dwExStyle & WS_EX_CTRLASMAINWIN) {
    PZORDERNODE pNode = pNewCtrl->pZOrderNode;

不对！代码理应不会跳到这一段，我的dwExStyle并没有包含WS_EX_CTRLASMAINWIN，我设置的应该是WS_EX_NONE，最后前往注册窗口类的代码处，终于发现了Bug所在：

/* Register the common WINDOW_CLASS_NAME */
WNDCLASS WindowClass;
 
WindowClass.spClassName = (char*) WINDOW_CLASS_NAME;
WindowClass.dwStyle = WS_EX_NONE;
WindowClass.hCursor = GetSystemCursor(IDC_ARROW);
WindowClass.iBkColor = COLOR_lightwhite;
WindowClass.WinProc = BasicWindow::dispatch;

RegisterWindowClass(&WindowClass);

原来我没有设置dwExStyle，于是dwExStyle被填充入了垃圾数据，运气好時不会启动这个Bug，运气不好時就会崩溃，归根到底问题还是出在我自己身上……

最后虽然MiniGUI没有错，但也许一句 assert (NULL != pNode); 就能省下我许许多多的时间，也算是今后自己写代码的一个教训吧。

最近几周懒懒散散混了过去，代码一行也没敲过，真不像自己。

不过到此为止，学校的嵌入式竞赛正式开始，不出意料进入了复赛名单，准备开始艰辛地垒代码吧！