• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            GLORY | 學(xué)習(xí)·記錄

            coding for life

            UVA 457 | 什么是Core Dump?

            UVA457是個水題,但是我還是碰到了一些小問題。

            1.開了一個state[50][42]數(shù)組在main函數(shù)里面,結(jié)果提交之后發(fā)現(xiàn)runtime error,覺著是堆棧溢出了。突然想起來50*42>2000,這種數(shù)組一定是開在main外面的,不然必然堆棧溢出。
            2.是讀題不仔細(xì),當(dāng)成了多重輸入,搞了一個while(scanf(...)),結(jié)果超時了。第一次在UVA OJ上面超時。

            但是這篇文章重點不是講這個,而是講我在運行過程中經(jīng)常遇到的core dumped現(xiàn)象。我在網(wǎng)上找到一點資料,貼在下面:

            原帖:http://blogold.chinaunix.net/u3/98822/showart_2093542.html


            什么是Core Dump?
            Core的意思是內(nèi)存, Dump的意思是扔出來, 堆出來.
            開發(fā)和使用Unix程序時, 有時程序莫名其妙的down了, 卻沒有任何的提示(有時候會提示core dumped). 這時候可以查看一下有沒有形如core.進程號的文件生成, 這個文件便是操作系統(tǒng)把程序down掉時的內(nèi)存內(nèi)容扔出來生成的, 它可以做為調(diào)試程序的參考.
            core dump又叫核心轉(zhuǎn)儲, 當(dāng)程序運行過程中發(fā)生異常, 程序異常退出時, 由操作系統(tǒng)把程序當(dāng)前的內(nèi)存狀況存儲在一個core文件中, 叫core dump.

            如何使用core文件?
            gdb -c core文件路徑 [應(yīng)用程序的路徑]
            進去后輸入where回車, 就可以顯示程序在哪一行當(dāng)?shù)舻? 在哪個函數(shù)中.

            為什么沒有core文件生成呢?
            有時候程序down了, 但是core文件卻沒有生成. core文件的生成跟你當(dāng)前系統(tǒng)的環(huán)境設(shè)置有關(guān)系, 可以用下面的語句設(shè)置一下, 然后再運行程序便成生成core文件.
            ulimit -c unlimited
            沒有找到core文件,我們改改ulimit的設(shè)置,讓它產(chǎn)生。1024是隨便取的,要是core文件大于1024個塊,就產(chǎn)生不出來了。)
            $ ulimit -c 1024 (轉(zhuǎn)者注: 使用-c unlimited不限制core文件大小

            core文件生成的位置一般于運行程序的路徑相同, 文件名一般為core.進程號

            4. 用gdb查看core文件:
            下面我們可以在發(fā)生運行時信號引起的錯誤時發(fā)生core dump了.
            發(fā)生core dump之后, 用gdb進行查看core文件的內(nèi)容, 以定位文件中引發(fā)core dump的行.
            gdb [exec file] [core file]
            如:
            gdb ./test test.core
            在進入gdb后, 用bt命令查看backtrace以檢查發(fā)生程序運行到哪里, 來定位core dump的文件->行.

            ===========================================================================

            造成程序core dump的原因很多,這里根據(jù)以往的經(jīng)驗總結(jié)一下:

            1 內(nèi)存訪問越界

              a) 由于使用錯誤的下標(biāo),導(dǎo)致數(shù)組訪問越界

              b) 搜索字符串時,依靠字符串結(jié)束符來判斷字符串是否結(jié)束,但是字符串沒有正常的使用結(jié)束符

              c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函數(shù),將目標(biāo)字符串讀/寫爆。應(yīng)該使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函數(shù)防止讀寫越界。

            2 多線程程序使用了線程不安全的函數(shù)。

            應(yīng)該使用下面這些可重入的函數(shù),尤其注意紅色標(biāo)示出來的函數(shù),它們很容易被用錯:

            asctime_r(3c) gethostbyname_r(3n) getservbyname_r(3n) ctermid_r(3s) gethostent_r(3n) getservbyport_r(3n) ctime_r(3c) getlogin_r(3c) getservent_r(3n) fgetgrent_r(3c) getnetbyaddr_r(3n) getspent_r(3c) fgetpwent_r(3c) getnetbyname_r(3n) getspnam_r(3c) fgetspent_r(3c) getnetent_r(3n) gmtime_r(3c) gamma_r(3m) getnetgrent_r(3n) lgamma_r(3m) getauclassent_r(3) getprotobyname_r(3n) localtime_r(3c) getauclassnam_r(3) etprotobynumber_r(3n) nis_sperror_r(3n) getauevent_r(3) getprotoent_r(3n) rand_r(3c) getauevnam_r(3) getpwent_r(3c) readdir_r(3c) getauevnum_r(3) getpwnam_r(3c) strtok_r(3c) getgrent_r(3c) getpwuid_r(3c) tmpnam_r(3s) getgrgid_r(3c) getrpcbyname_r(3n) ttyname_r(3c) getgrnam_r(3c) getrpcbynumber_r(3n) gethostbyaddr_r(3n) getrpcent_r(3n)

            3 多線程讀寫的數(shù)據(jù)未加鎖保護。

            對于會被多個線程同時訪問的全局?jǐn)?shù)據(jù),應(yīng)該注意加鎖保護,否則很容易造成core dump

            4 非法指針

              a) 使用空指針

              b) 隨意使用指針轉(zhuǎn)換。一個指向一段內(nèi)存的指針,除非確定這段內(nèi)存原先就分配為某種結(jié)構(gòu)或類型,或者這種結(jié)構(gòu)或類型的數(shù)組,否則不要將它轉(zhuǎn)換為這種結(jié)構(gòu)或類型的指針,而應(yīng)該將這段內(nèi)存拷貝到一個這種結(jié)構(gòu)或類型中,再訪問這個結(jié)構(gòu)或類型。這是因為如果這段內(nèi)存的開始地址不是按照這種結(jié)構(gòu)或類型對齊的,那么訪問它時就很容易因為bus error而core dump.

            5 堆棧溢出

            不要使用大的局部變量(因為局部變量都分配在棧上),這樣容易造成堆棧溢出,破壞系統(tǒng)的棧和堆結(jié)構(gòu),導(dǎo)致出現(xiàn)莫名其妙的錯誤。

            -------
            我自己程序core dumped就是因為第5個原因,堆棧溢出。我的局部數(shù)組開的過大,而局部變量分配在棧上,導(dǎo)致堆棧溢出。

            posted on 2011-03-14 08:24 meglory 閱讀(553) 評論(0)  編輯 收藏 引用 所屬分類: AlgorithmsLinux

            導(dǎo)航

            隨筆分類

            隨筆檔案

            最新評論

            久久99中文字幕久久| 亚洲美日韩Av中文字幕无码久久久妻妇 | 久久久WWW成人| 伊人 久久 精品| 久久精品国产亚洲av影院| 91精品国产91久久| 女人高潮久久久叫人喷水| 99久久免费只有精品国产| 国产午夜免费高清久久影院| 久久久无码一区二区三区| 精品久久久久久中文字幕| 成人综合久久精品色婷婷| 亚洲中文字幕无码久久综合网| 国产精品美女久久久m| 欧美无乱码久久久免费午夜一区二区三区中文字幕 | 久久夜色精品国产噜噜亚洲AV| 久久婷婷成人综合色综合| 久久频这里精品99香蕉久| 国产精品美女久久久久| 久久人妻无码中文字幕| 久久综合九色综合欧美就去吻| 国内精品久久久久久野外| 亚洲精品无码久久毛片| 久久青青草原精品国产不卡| 国产成人精品免费久久久久| A级毛片无码久久精品免费| 久久精品国产亚洲av麻豆图片| 久久国产精品波多野结衣AV | 中文国产成人精品久久不卡| 无码乱码观看精品久久| 2021国内精品久久久久久影院| 久久99国产精品成人欧美| 91精品国产91久久| 免费国产99久久久香蕉| 合区精品久久久中文字幕一区| 久久人人爽人人爽人人片av高请| 国产一区二区三区久久精品| 久久久久亚洲精品天堂久久久久久| 亚洲va国产va天堂va久久| 69久久夜色精品国产69| 狠狠色丁香久久婷婷综合_中 |