• <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>

            大龍的博客

            常用鏈接

            統計

            最新評論

            pthread之線程堆棧(2)--轉

            用下面的命令來看linux下面的對系統的一些限制:
            dongq@DongQ_Lap ~/workspace/test/pthread_attr $ ulimit -a
            core file size          (blocks, -c) 0
            data seg size (kbytes, -d) unlimited
            scheduling priority (-e) 0
            file size (blocks, -f) unlimited
            pending signals (-i) 16365
            max locked memory (kbytes, -l) 32
            max memory size (kbytes, -m) unlimited
            open files (-n) 1024
            pipe size (512 bytes, -p) 8
            POSIX message queues (bytes, -q) 819200
            real-time priority (-r) 0
            stack size (kbytes, -s) 8196
            cpu time (seconds, -t) unlimited
            max user processes (-u) 16365
            virtual memory (kbytes, -v) unlimited
            file locks (-x) unlimited


            通過上面的命令, 我們可以清楚的看到一個進程在正常的情況下,最大的棧空間為8M。
            那么8M我們夠用嗎?當你分配大量的static或者auto變量的時候,一般都是放在??臻g的。如果分配一個大于8M的數組,會發生什么呢?
            先來看看測試代碼:
            int main()
            {

            int i = 1024 * 1024 * 8;
            char p[ i ];
            memset( p, 0, sizeof( char ) * i );

            while( i-- )
            {
            p[ i ] = i;
            }

            return 0;
            }
            上面的代碼直接分配一個大小為8M的數組,編譯后運行,出現段錯誤??!
            很奇怪嗎?不是說可以分配8M嗎?怎么不行?當然不行,因為在分配p時,棧中已經放有其它的變量,最明顯的就是int i;
            這樣子的話,棧中就沒有足夠的空間給變量p分配,從而出現段錯誤。下面用gdb進行調試:
            DongQ_Lap pthread_attr # gdb process_stack

            GNU gdb 6.5
            (gdb) b main
            Breakpoint 1 at 0x8048392: file process_stack.c, line 13.
            (gdb) r > /home/dongq/tmp/gdb.txt
            Starting program: /home/dongq/workspace/test/pthread_attr/process_stack > /home/dongq/tmp/gdb.txt
            [Thread debugging using libthread_db enabled]
            [New Thread -1209533760 (LWP 10947)]
            [Switching to Thread -1209533760 (LWP 10947)]

            Breakpoint 1, main () at process_stack.c:13
            13 {
            (gdb) s
            15 int i = 1024 * 1024 * 8;
            (gdb) s
            16 char p[ i ];
            (gdb) s
            17 memset( p, 0, sizeof( char ) * i );
            (gdb) p p
            $1 = 0xbf6c3470 <Address 0xbf6c3470 out of bounds>
            (gdb) s

            Program received signal SIGSEGV, Segmentation fault.
            0x080483d4 in main () at process_stack.c:17
            17 memset( p, 0, sizeof( char ) * i );
            (gdb) bt
            #0 0x080483d4 in main () at process_stack.c:17
            (gdb) quit

            看到了嗎?char p[i]這句執行后的結果是out of bounds!!也就是內存沒有分配成功。(在linux程序運行的地址空間為0x8048000-0xbfffffff)
            用下面的命令改變進程??臻g:
            ulimit -s 16392
            重新改變程序的棧空間,很奇怪的是,有時普通用戶可以操作,有時卻出現:
            dongq@DongQ_Lap ~/workspace/test/pthread_attr $ ulimit -s 16384
            bash: ulimit: stack size: cannot modify limit: Operation not permitted

            改用超級權限即可成功修改,改完之后,limit -a得到的結果中應該有下面的一行就表示成功了:
            stack size (kbytes, -s) 16392

            再運行上面的程序就可以正常的運行了,當然,你還可以分配更大的數組:)

            posted on 2009-06-07 15:06 大龍 閱讀(614) 評論(0)  編輯 收藏 引用

            日本久久中文字幕| 成人国内精品久久久久影院| 天天做夜夜做久久做狠狠| 中文国产成人精品久久不卡| 久久人人爽人人爽人人片AV不| 久久综合久久久| 午夜精品久久久久久久| 久久久久亚洲精品天堂久久久久久| 2021久久精品免费观看| 99国产精品久久| 色妞色综合久久夜夜| 亚洲欧洲久久久精品| 国产精品成人99久久久久91gav| 久久99热这里只频精品6| 精品久久久久久国产三级| 成人国内精品久久久久一区| 人妻无码精品久久亚瑟影视| 九九久久精品国产| 国内精品久久国产大陆| 亚洲国产精品一区二区久久hs| 久久成人精品| 国产成人久久777777| 亚洲天堂久久精品| AV无码久久久久不卡网站下载 | 久久国产精品偷99| 国产午夜精品理论片久久影视| 奇米影视7777久久精品人人爽| 久久婷婷色综合一区二区| 国产精品久久久久久久午夜片| 99国产欧美精品久久久蜜芽| 久久天堂AV综合合色蜜桃网| 综合久久国产九一剧情麻豆| 囯产极品美女高潮无套久久久| 久久久久亚洲av成人网人人软件| 亚洲国产成人精品女人久久久| 三级韩国一区久久二区综合| 色综合合久久天天给综看| 香蕉久久久久久狠狠色| 久久久无码精品亚洲日韩蜜臀浪潮 | 一本一道久久综合狠狠老| 一本一本久久aa综合精品 |