• <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)  編輯 收藏 引用

            久久精品人人做人人爽电影| 2020国产成人久久精品| 国产精品毛片久久久久久久| 久久青青草原亚洲av无码app | 亚洲日本久久久午夜精品| 伊人久久精品无码二区麻豆| 一级做a爰片久久毛片人呢| 亚洲精品视频久久久| 国产精品无码久久久久久| 伊人久久亚洲综合影院| 91久久精品国产91性色也| 日韩精品无码久久久久久| 久久婷婷人人澡人人| 精品999久久久久久中文字幕| 一本综合久久国产二区| 国产精品日韩欧美久久综合| 亚洲精品乱码久久久久久中文字幕 | 久久99毛片免费观看不卡| 少妇人妻综合久久中文字幕| 99久久99久久精品国产片| 中文字幕乱码久久午夜| 亚洲精品国产第一综合99久久| 久久99精品综合国产首页| 久久久婷婷五月亚洲97号色 | 久久被窝电影亚洲爽爽爽| 99精品国产99久久久久久97| 欧美无乱码久久久免费午夜一区二区三区中文字幕 | 久久播电影网| 亚洲国产天堂久久综合网站 | 久久伊人色| 青青青青久久精品国产h久久精品五福影院1421| 午夜精品久久久久久久久| 四虎国产精品成人免费久久| 亚洲国产成人久久综合区| 久久综合九色综合欧美就去吻| 久久精品成人免费国产片小草| 久久久九九有精品国产| 久久综合综合久久狠狠狠97色88| 久久99免费视频| 国产一区二区三精品久久久无广告 | 最新久久免费视频|