跳到主要內容

深奧又愚蠢的問題

前陣子有同仁發現我們的系統中有一支driver會造成系統當機,因為這支driver目前的負責人換我接手了,所以問題就轉到我手上,直到最近把手上幾個比較重要的項目告一段落後才抽空來看這個問題。

一開始先只看一下source,程式看起來不複雜,可能有問題的點都是很簡單易懂的標準程式寫法,看起來沒什麼破綻,看不出問題來。這支driver主要的程式註冊了一個event callback,在這個event callback裡面又會觸發另一個event,而這個event又會讓別支driver註冊的event callback執行,然後啟動一個service。看起來好像很複雜,其實並不複雜,就把它當成只連續call了幾次function就行。

我把driver打開執行看看,果然在我的環境也會發生系統當機的問題,是可以複製的問題,所以不是環境平台不同的問題。再把這支driver關閉,果然就沒有系統當機的問題,所以應該很有可能是這支driver造成的問題。接著我試著調整這支driver的執行次序看看,結果發現如果我讓它提早一些執行,結果就不會當機了。是那邊的記憶體有問題嗎?因為發現問題的同仁也說過,我們release的程式裡面,有幾個版本不會造成當機,但有的版本又會當機。現在我調整次序後又不會當機了?看來應該和記憶體有關係,是這支driver前面的driver造成的嗎?我又去看看前面的driver,看起來也是很簡單的程式,完全看不出來有什麼點是有可能會發生問題的。

光是作了以上幾個測試就花了我不少時間,因為我們的系統每次修改程式到重新編譯程式準備好環境作測試就會花不少時間。debug的方式主要是丟除錯訊息,因為這是最便捷的方法,當然也能支援source level debug,只是因為設定太麻煩以致於平常都習慣靠除錯訊息除錯。最後實在不行了,既然已經花了那麼多時間測試了,不如再多花點時間把source level debugger架起來吧。

source level debugger架起來後,我當然直接在driver的event callback裡面下一個breakpoint,然後執行看看。結果發生詭異的事情!第一次執行,程式並沒有中斷,這就奇怪了,我斷點是下在程式必經之路,怎麼不會斷呢?第二次程式是中斷了,但是居然斷在另外一支driver的callback裡面!我比對了我下斷點的function的位址和實際中斷的function的位址,還真的是一樣的位址。這種事情怎麼會發生呢!?這一定是記憶體的問題。

很快的我就找到問題真正發生點並把它修好:原來會造成系統當機的這支driver在註冊event callback到系統後,後面的初始化動作有問題,對系統報告錯誤後被系統unload掉了。但在driver被系統unload之前並沒有把先前註冊的event callback作反向的unregister動作,所以在系統裡面的記錄就指向一的不明位址。這就是造成當掉的原因,也是有時會當有時不會當的原因。因為這是memory的問題,現象會根據當是系統狀態而有不同。

這個問題初看好像很深奧,其實很愚蠢,這讓我又得到二個教訓。


  1. 那些看起來顯而易見沒有問題的程式有時候真的是問題的所在!
  2. 可以的話還是儘快打開你的source level debugger吧,source debug還是最強大的debug方法!


留言

這個網誌中的熱門文章

單人撲克牌遊戲 - 蒙地卡羅

更多可在網頁玩的 單人撲克牌遊戲 ; 新增一個簡單的單人撲克牌遊戲: 蒙地卡羅 ,簡單介紹一下玩法。 下載 事先排列好5x5張牌。 每次移動一張可以配對的牌,並消除這對牌。在上下、左右及斜向相隣的二張牌,只要擁有同樣數字(不計花色),即可配對。 消除二張配對的牌後,剩餘的牌以往左往上的方式補滿空隙,接著在發新牌補滿後面的空格。 重覆步驟2~3,直到沒有牌可以配對及發完所有牌為止。 結果有二種。一個是勝利,成功的消除掉所有牌。另一個是Gameover沒有牌可以再作配對。

以lex/yacc實作算式計算機

前面我們透過 手工的方式 實作了一個簡易的算式計算機,現在我們要開始使用工具來作同樣的事,比較看看手工和使用工具有什麼不同的差別。首先要介紹的就是lex&yacc。 lex & yacc lex(Lexical Analyzar)及yacc(Yet Another Compiler Compiler)是用來輔助程式設計師製作語法剖析器的程式工具。lex的工作就是幫助我們將輸入的資料文字串流分解成一個個有意義的token,而yacc的工作就是幫我們分析這些token和我們定義的規則作匹配。下圖中所表示的是使用lex及yacc的一般工作流程。 首先看到yacc會讀入一個.y檔案,這裡.y檔案的內容就是我們使用類似(E)BNF語法定義的語法規則,yacc會分析這些語法規則後,幫我們產生可以用來解析這些規則的程式碼,而這個檔案一般名稱預設為y.tab.c,產生的程式碼裡面最重要的一個的函式叫作yyparse。 同yacc類似,lex也會讀入一個.l的檔案,這個檔案裡面定義的是如何從文字流裡解出token的規則,使用的方法是常規表示式(regular expression)。在圖的左側中間我們還可以看到有一個叫作y.tab.h的檔案從yacc產生出來並餵給lex作輸入,這個檔案是yacc根據在讀入的.y檔裡面所定義的token代號所產生出來的一個header,這樣yacc及lex產生出來的程式碼裡面就可以使用共通定義的代碼而不必各寫個的。lex分析過.l檔案後也會產生一個一般預設叫作lex.yy.c的原始碼檔案,裡頭最重要的一個函式叫作yylex。 最後,我們把yacc產生出來的y.tab.c還有lex產生出來的lex.yy.c,以及其它我們自己撰寫的原始碼檔案一起拿來編譯再作連結,最後產生出來的就是一個可以用來解析我們定義的語法的解析器工具。以上是整個lex及yacc的使用流程概觀。 常規表示式 在正式使用lex之前,我們首先來對常規表示法作一個基本的認識。常規表示法是一種用來表示字串樣式(pattern)的中繼語言,就好比前文所介紹的(E)BNF表示式一樣,都是用來描述其它語言的語言,只不過用途不太一樣罷了。 常規表示式使用一些中繼符號(meta-symbol)以及ASCII字元定義字串樣式,以下列出一些常規表示式所使用的符號。 . 表示除了換行字元...

窮人的 AI:自動漫畫分鏡切割

  ( 試試看 ) 在手機上看漫畫時,有一個體驗上的問題: 漫畫原本是「整頁設計」 手機最適合的是「一格一格往下滑」 與其強迫使用者縮放、拖曳、放大,更直覺的做法是: 直接把一頁漫畫自動切成多個分鏡,轉成瀑布流閱讀。 這篇文章分享一個不靠深度學習、完全在前端完成的實作方式: 使用 OpenCV.js 做分鏡偵測 輸出 rect list 再用 全畫面 Canvas 把每個分鏡當成一個「閱讀單位」 整個系統可以拆成三層: 漫畫圖片 ↓ 影像處理(找出 rects) ↓ 排序後的 rect list ↓ 全畫面 Canvas 逐格呈現(瀑布流) Step 1:灰階化 漫畫的資訊 90% 都在線條上,顏色反而是干擾。 cv.cvtColor(src, grayImage, cv.COLOR_RGBA2GRAY); 灰階化的好處: 降低維度 對邊緣偵測更穩定 對黑白漫畫特別有效 Step 2:邊緣偵測,抓出「分鏡的邊」 接下來用最經典、也最夠用的 Canny Edge Detection: cv.Canny(grayImage, edges, 50, 150); 在漫畫中,分鏡外框通常就是最明顯的邊界。 Step 3:形態學操作,把破碎邊框「補起來」 真實漫畫的線條並不完美,常常有斷線、陰影、留白。 所以要做一個很重要的步驟:膨脹(Dilation) const kernel = cv.Mat.ones( 5 , 5 , cv.CV_8U); cv.dilate(edges, dilatedEdges, kernel); 直覺理解就是: 把細線「抹粗一點」, 讓本來斷掉的邊界連成封閉區域。 這一步直接決定後面能不能成功抓到「一整格分鏡」。 Step 4:找輪廓,轉成矩形框(rect) 有了封閉區域之後,就可以找輪廓: cv.findContours( dilatedEdges, contours, hierarchy, cv.RETR_EXTERNAL, cv.CHAIN_APPROX_SIMPLE ); 每一個 contour,代表一個「可能的分鏡區塊」。 接著轉成矩形: const rect = cv.boundingRect(contour); rects.push([rect.x, rect.y, rect.widt...