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


            通過上面的命令, 我們可以清楚的看到一個進程在正常的情況下,最大的??臻g為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)
            用下面的命令改變進程棧空間:
            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 大龍 閱讀(613) 評論(0)  編輯 收藏 引用

            久久精品中文无码资源站| 久久综合狠狠综合久久| 久久天天躁狠狠躁夜夜不卡| 婷婷久久精品国产| 7777久久久国产精品消防器材| 潮喷大喷水系列无码久久精品| 久久99精品免费一区二区| 欧美伊人久久大香线蕉综合 | 久久久久人妻精品一区二区三区 | 91精品国产91久久久久久青草| 久久国产精品免费一区| 欧美熟妇另类久久久久久不卡| 久久国产热这里只有精品| 欧美丰满熟妇BBB久久久| 久久综合视频网| 久久这里只有精品首页| 欧美精品久久久久久久自慰| 亚洲国产精品嫩草影院久久| 亚洲国产精久久久久久久| 国内精品人妻无码久久久影院| 久久只这里是精品66| 久久天天躁狠狠躁夜夜av浪潮| 久久精品国产精品青草| 久久久久亚洲AV无码专区体验 | 久久综合狠狠综合久久| 国产精品久久久久久久人人看 | 日韩人妻无码精品久久久不卡 | 国内精品久久久久久久涩爱| 午夜精品久久久久久久久| 日日狠狠久久偷偷色综合0| 国内精品伊人久久久久777| 久久夜色精品国产噜噜亚洲a| 国产叼嘿久久精品久久| 99久久国语露脸精品国产| 伊人久久大香线蕉综合5g| 色婷婷久久综合中文久久一本| 国产69精品久久久久9999| 久久精品国产亚洲av瑜伽| 日本加勒比久久精品| 大香伊人久久精品一区二区| 久久99精品国产麻豆宅宅|