1. 程式人生 > >Linux系統呼叫__get_thread獲取TLS失敗導致應用程式奔潰

Linux系統呼叫__get_thread獲取TLS失敗導致應用程式奔潰

背景

Android模擬器執行在PC端,Android應用執行在模擬器內部,當PC機在BIOS中沒有開啟虛擬化技術(vt-x: intel的硬體虛擬化技術; AMD-V: AMD CPU的硬體虛擬化技術)的時候,在模擬器內部執行ARM庫的遊戲,出現崩潰或者執行一段時間之後崩潰的問題. 具體奔潰點在__get_tls()+6處. 這裡以當樂.apk這個遊戲為例子,刪除其中libs下的x86庫,只保留arm型別庫檔案,安裝執行後整個崩潰日誌如下:

03-27 15:51:21.236 E/ZKOPCountUtil( 3290): find Name = 當樂
03-27 15:51:21.344
D/dalvikvm( 4203): GC_CONCURRENT freed 1093K, 8% free 13255K/14404K, paused 15ms+12ms, total 212ms 03-27 15:51:21.344 D/dalvikvm( 4203): WAIT_FOR_CONCURRENT_GC blocked 96ms 03-27 15:51:21.348 D/dalvikvm( 4203): WAIT_FOR_CONCURRENT_GC blocked 89ms 03-27 15:51:21.360 D/dalvikvm( 4203): WAIT_FOR_CONCURRENT_GC blocked 96
ms 03-27 15:51:21.404 W/View ( 4203): requestLayout() improperly called by android.support.v7.widget.AppCompatTextView{52831f4c V.ED.... ......I. 20,0-148,91 #7f0d0438 app:id/expand_title} during layout: running second layout pass 03-27 15:51:21.584 D/Volley ( 4203): [148] b.a: HTTP response for request=<[ ] http://res5.d.cn/cp/img/502487/o_1bbl6epie170sbec184qs9i1ggou.png 0x22e400ee LOW 2> [lifetime=4156], [size=67], [rc=200], [retryCount=0]
03-27 15:51:21.920 F/libc ( 4203): Fatal signal 11 (SIGSEGV) at 0x24244c8d (code=1), thread 4246 (Thread-133) 03-27 15:51:22.044 I/DEBUG ( 112): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 03-27 15:51:22.044 I/DEBUG ( 112): Build fingerprint: 'SAMSUNG/hlteatt/hlteuc:4.4.4/tt/eng.jenkins.20170306.140753:userdebug/test-keys' 03-27 15:51:22.044 I/DEBUG ( 112): Revision: '0' 03-27 15:51:22.044 I/DEBUG ( 112): pid: 4203, tid: 4246, name: Thread-133 >>> com.diguayouxi <<< 03-27 15:51:22.044 I/DEBUG ( 112): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 24244c8d 03-27 15:51:23.412 D/dalvikvm( 784): GC_CONCURRENT freed 437K, 28% free 3834K/5272K, paused 7ms+6ms, total 75ms 03-27 15:51:23.568 I/GAv4-SVC( 2937): Google Analytics 8.7.03 is starting up. 03-27 15:51:23.884 I/DEBUG ( 112): eax 24244c89 ebx b76b7fcc ecx 00000018 edx 00004000 03-27 15:51:23.888 I/DEBUG ( 112): esi b76c694c edi 00000000 03-27 15:51:23.888 I/DEBUG ( 112): xcs 00000073 xds 0000007b xes 0000007b xfs 0000003b xss 0000007b 03-27 15:51:23.888 I/DEBUG ( 112): eip b76343c6 ebp 00004000 esp 956396cc flags 00210206 03-27 15:51:23.900 D/dalvikvm( 697): GC_CONCURRENT freed 489K, 12% free 4671K/5284K, paused 10ms+1ms, total 74ms 03-27 15:51:23.976 I/DEBUG ( 112): 03-27 15:51:23.976 I/DEBUG ( 112): backtrace: 03-27 15:51:23.984 I/DEBUG ( 112): #00 pc 000183c6 /system/lib/libc.so (__get_thread+6) 03-27 15:51:23.984 I/DEBUG ( 112): #01 pc 0000de2d /system/lib/libc.so (pthread_mutex_lock+205) 03-27 15:51:23.988 I/DEBUG ( 112): #02 pc 0005a745 /system/lib/libc.so (flockfile+37) 03-27 15:51:23.988 I/DEBUG ( 112): #03 pc 0004651f /system/lib/libc.so (fread+335) 03-27 15:51:23.992 I/DEBUG ( 112): #04 pc 00075f6a /system/lib/libc.so (android_getaddrinfo_proxy+1050) 03-27 15:51:23.996 I/DEBUG ( 112): #05 pc 00078c30 /system/lib/libc.so (android_getaddrinfoforiface+1936) 03-27 15:51:24.000 I/DEBUG ( 112): #06 pc 00078e97 /system/lib/libc.so (getaddrinfo+55) 03-27 15:51:24.000 I/DEBUG ( 112): #07 pc 00037160 /system/lib/libjavacore.so (Posix_getaddrinfo(_JNIEnv*, _jobject*, _jstring*, _jobject*)+336) 03-27 15:51:24.000 I/DEBUG ( 112): #08 pc 0002a4ab /system/lib/libdvm.so (dvmPlatformInvoke+79) 03-27 15:51:24.008 I/DEBUG ( 112): #09 pc 00077a27 [heap] 03-27 15:51:24.008 I/DEBUG ( 112): #10 pc 00086da2 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+434) 03-27 15:51:24.008 I/DEBUG ( 112): #11 pc 001775b8 /system/lib/libdvm.so 03-27 15:51:24.008 I/DEBUG ( 112): #12 pc 00003cf7 <unknown> 03-27 15:51:24.008 I/DEBUG ( 112): #13 pc 0003b962 /system/lib/libdvm.so (dvmMterpStd(Thread*)+66) 03-27 15:51:24.008 I/DEBUG ( 112): #14 pc 00037029 /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+217) 03-27 15:51:24.008 I/DEBUG ( 112): #15 pc 000bd027 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, char*)+759) 03-27 15:51:24.008 I/DEBUG ( 112): #16 pc 000bd437 /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+55) 03-27 15:51:24.008 I/DEBUG ( 112): #17 pc 000993c3 /system/lib/libdvm.so (interpThreadStart(void*)+995) 03-27 15:51:24.008 I/DEBUG ( 112): #18 pc 0000bc3c /system/lib/libc.so (__thread_entry+236) 03-27 15:51:24.008 I/DEBUG ( 112): #19 pc 0003e1b5 /system/lib/libc.so (__pthread_clone+69) 03-27 15:51:24.008 I/DEBUG ( 112): #20 pc 00098fdf /system/lib/libdvm.so (internalThreadStart(void*)+655) 03-27 15:51:24.008 I/DEBUG ( 112): 03-27 15:51:24.008 I/DEBUG ( 112): stack: 03-27 15:51:24.008 I/DEBUG ( 112): 9563968c b4db080e /system/lib/libdvm.so (dvmMterp_OP_RETURN_VOID_BARRIER+158) 03-27 15:51:24.008 I/DEBUG ( 112): 95639690 b8cadbc0 [heap] 03-27 15:51:24.008 I/DEBUG ( 112): 95639694 00000001 03-27 15:51:24.008 I/DEBUG ( 112): 95639698 00000000 03-27 15:51:24.008 I/DEBUG ( 112): 9563969c b7629f39 /system/lib/libc.so (pthread_mutex_unlock+25) 03-27 15:51:24.008 I/DEBUG ( 112): 956396a0 00000000 03-27 15:51:24.024 I/DEBUG ( 112): 956396a4 9db6fdee /data/dalvik-cache/[email protected]@[email protected] 03-27 15:51:24.024 I/DEBUG ( 112): 956396a8 9563dce4 03-27 15:51:24.024 I/DEBUG ( 112): 956396ac b7629fba /system/lib/libc.so (pthread_mutex_unlock+154) 03-27 15:51:24.024 I/DEBUG ( 112): 956396b0 00000000 03-27 15:51:24.024 I/DEBUG ( 112): 956396b4 b8cadbd0 [heap] 03-27 15:51:24.024 I/DEBUG ( 112): 956396b8 9dd30518 /dev/ashmem/dalvik-LinearAlloc (deleted) 03-27 15:51:24.024 I/DEBUG ( 112): 956396bc b7629fba /system/lib/libc.so (pthread_mutex_unlock+154) 03-27 15:51:24.032 I/DEBUG ( 112): 956396c0 00004000 03-27 15:51:24.032 I/DEBUG ( 112): 956396c4 b8cae030 [heap] 03-27 15:51:24.036 I/DEBUG ( 112): 956396c8 b7629d69 /system/lib/libc.so (pthread_mutex_lock+9) 03-27 15:51:24.052 I/DEBUG ( 112): #00 956396cc b7629e2e /system/lib/libc.so (pthread_mutex_lock+206) 03-27 15:51:24.052 I/DEBUG ( 112): #01 956396d0 a59e7eec /dev/ashmem/dalvik-heap (deleted) 03-27 15:51:24.052 I/DEBUG ( 112): 956396d4 b8ea6808 [heap] 03-27 15:51:24.052 I/DEBUG ( 112): 956396d8 b76bc718 03-27 15:51:24.052 I/DEBUG ( 112): 956396dc b762ed4f /system/lib/libc.so (dlmalloc+351) 03-27 15:51:24.052 I/DEBUG ( 112): 956396e0 b76bc800 03-27 15:51:24.052 I/DEBUG ( 112): 956396e4 b8cae030 [heap] 03-27 15:51:24.052 I/DEBUG ( 112): 956396e8 00004000 03-27 15:51:24.052 I/DEBUG ( 112): 956396ec 00004000 03-27 15:51:24.052 I/DEBUG ( 112): 956396f0 00000050 03-27 15:51:24.052 I/DEBUG ( 112): 956396f4 b8e2bee8 [heap] 03-27 15:51:24.052 I/DEBUG ( 112): 956396f8 b7629d69 /system/lib/libc.so (pthread_mutex_lock+9) 03-27 15:51:24.052 I/DEBUG ( 112): 956396fc b76b7fcc /system/lib/libc.so 03-27 15:51:24.052 I/DEBUG ( 112): 95639700 b8ea6808 [heap] 03-27 15:51:24.052 I/DEBUG ( 112): 95639704 00000001 03-27 15:51:24.052 I/DEBUG ( 112): 95639708 b76c63a0 03-27 15:51:24.052 I/DEBUG ( 112): 9563970c b7676746 /system/lib/libc.so (flockfile+38) 03-27 15:51:24.052 I/DEBUG ( 112): #02 95639710 b76c694c 03-27 15:51:24.052 I/DEBUG ( 112): 95639714 b8e2bee8 [heap] 03-27 15:51:24.052 I/DEBUG ( 112): 95639718 00001000 03-27 15:51:24.068 I/DEBUG ( 112): 9563971c b76b7fcc /system/lib/libc.so 03-27 15:51:24.068 I/DEBUG ( 112): 95639720 956397da [stack:4246] 03-27 15:51:24.068 I/DEBUG ( 112): 95639724 b7676726 /system/lib/libc.so (flockfile+6) 03-27 15:51:24.068 I/DEBUG ( 112): 95639728 b76b7fcc /system/lib/libc.so 03-27 15:51:24.068 I/DEBUG ( 112): 9563972c b7662520 /system/lib/libc.so (fread+336) 03-27 15:51:24.296 I/DEBUG ( 112): 03-27 15:51:24.296 I/DEBUG ( 112): memory map around fault addr 24244c8d: 03-27 15:51:24.304 I/DEBUG ( 112): 1c142000-1c145000 rw- 03-27 15:51:24.308 I/DEBUG ( 112): (no map for address) 03-27 15:51:24.308 I/DEBUG ( 112): 9296d000-9296e000 --- 03-27 15:51:24.940 I/PhenotypeConfigurator( 697): Scheduling Phenotype for one-off execution 667 seconds from now (1490601084941) 03-27 15:51:25.244 D/dalvikvm( 2937): GC_CONCURRENT freed 214K, 6% free 5252K/5572K, paused 19ms+26ms, total 106ms

問題定位

根據奔潰日誌,找到相應的函式__get_tls(),在原始碼中實現如下:

//android-4.4.4\bionic\libc\arch-x86\bionic\__get_tls.c

/* see the implementation of __set_tls and pthread.c to understand this
 * code. Basically, the content of gs:[0] always is a pointer to the base
 * address of the tls region
 */
void*   __get_tls(void)
{
  void*  tls;
  asm ( "   movl  %%gs:0, %0" : "=r"(tls) );
  return tls;
}

從程式碼的註釋可以看出,這個gs暫存器儲存的是指向TLS(Thread Local Storage:執行緒本地儲存)的基地址指標.用IDA能更加直觀的看到奔潰的點.如下是用IDA開啟libc.so的__get_tls()函式,那麼在__get_tls()+6這行崩潰,也就是mov eax, [eax+4]間接取址崩潰.

.text:000183C0
.text:000183C0 ; =============== S U B R O U T I N E =======================================
.text:000183C0
.text:000183C0
.text:000183C0                 public __get_thread
.text:000183C0 __get_thread    proc near               ; CODE XREF: __pthread_cleanup_push+1Bp
.text:000183C0                                         ; __pthread_cleanup_pop+1Bp ...
.text:000183C0                 mov     eax, large gs:0
.text:000183C6                 mov     eax, [eax+4]
.text:000183C9                 nop
.text:000183CA                 nop
.text:000183CB                 nop
.text:000183CC                 nop
.text:000183CD                 retn
.text:000183CD __get_thread    endp

那麼問題來了,eax是從gs暫存器讀取的值,加4後間接定址失敗.這裡gs暫存器的值肯定有問題,從奔潰日誌的來看,eax暫存器的值就是gs:0的值,這裡地址有問題.那麼現在我們需要了解的是這個gs暫存器哪裡設定,作用時啥?

既然程式碼註釋說明了gs時存放tls基地址指標的,tls存放在核心GDT表中,那麼這個gs應該是由核心來設定的.這裡以x86的段分配為例子,段定義檔案在asm\Segment.h中,如下:


// genymotion_kernel_3.10\arch\x86\include\asm\Segment.h

/*
 * The layout of the per-CPU GDT under Linux:
 *
 *   0 - null
 *   1 - reserved
 *   2 - reserved
 *   3 - reserved
 *
 *   4 - unused         <==== new cacheline
 *   5 - unused
 *
 *  ------- start of TLS (Thread-Local Storage) segments:
 *
 *   6 - TLS segment #1         [ glibc's TLS segment ]
 *   7 - TLS segment #2         [ Wine's %fs Win32 segment ]
 *   8 - TLS segment #3
 *   9 - reserved
 *  10 - reserved
 *  11 - reserved
 *
 *  ------- start of kernel segments:
 *
 *  12 - kernel code segment        <==== new cacheline
 *  13 - kernel data segment
 *  14 - default user CS
 *  15 - default user DS
 *  16 - TSS
 *  17 - LDT
 *  18 - PNPBIOS support (16->32 gate)
 *  19 - PNPBIOS support
 *  20 - PNPBIOS support
 *  21 - PNPBIOS support
 *  22 - PNPBIOS support
 *  23 - APM BIOS support
 *  24 - APM BIOS support
 *  25 - APM BIOS support
 *
 *  26 - ESPFIX small SS
 *  27 - per-cpu            [ offset to per-cpu data area ]
 *  28 - stack_canary-20        [ for stack protector ]
 *  29 - unused
 *  30 - unused
 *  31 - TSS for double fault handler
 */

 ... ...
 //省去部分程式碼


 /*
 * Save a segment register aw
 */
#define savesegment(seg, value)             \
    asm("mov %%" #seg ",%0":"=r" (value) : : "memory")

/*
 * x86_32 user gs accessors.
 */
#ifdef CONFIG_X86_32
#ifdef CONFIG_X86_32_LAZY_GS
#define get_user_gs(regs)   (u16)({unsigned long v; savesegment(gs, v); v;})
#define set_user_gs(regs, v)    loadsegment(gs, (unsigned long)(v))
#define task_user_gs(tsk)   ((tsk)->thread.gs)
#define lazy_save_gs(v)     savesegment(gs, (v))
#define lazy_load_gs(v)     loadsegment(gs, (v))
#else   /* X86_32_LAZY_GS */
#define get_user_gs(regs)   (u16)((regs)->gs)
#define set_user_gs(regs, v)    do { (regs)->gs = (v); } while (0)
#define task_user_gs(tsk)   (task_pt_regs(tsk)->gs)
#define lazy_save_gs(v)     do { } while (0)
#define lazy_load_gs(v)     do { } while (0)
#endif  /* X86_32_LAZY_GS */
#endif  /* X86_32 */

問題解決

從上表可以看出整個GDT的分段,其中包括TLS段,關鍵的是在最後有關獲取gs暫存器值的方法.可以看到,在核心配置了CONFIG_X86_32的情況下,有兩個獲取gs暫存器值的方法,依賴於核心中巨集CONFIG_X86_32_LAZY_GS的定義與否.

通過檢視核心中CONFIG_X86_32_LAZY_GS的定義,發現處於選中狀態,那麼此時gs的值是從區域性變數v中賦值給gs的,這個時候區域性變數的值由於沒有初始化,所以為一個隨機值.如果沒有選CONFIG_X86_32_LAZY_GS,那麼直接獲取gs暫存器的值返回,這是regs的值在哪裡設定gs暫且不表.看到這裡也許還是不明白gs在整個核心中的作用以及流程.沒有關係,後續在深入. 至於解決這個問題,由於發現CONFIG_X86_32_LAZY_GS對獲取gs暫存器的影響,配置核心,去除CONFIG_X86_32_LAZY_GS選項,重編後驗證,當樂.apk正常執行.說明此配置影響gs暫存器的取值.

解決patch如下,合入x86的deconfig配置檔案即可:


@@ -37,7 +37,6 @@ CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
 CONFIG_HAVE_INTEL_TXT=y
 CONFIG_X86_32_SMP=y
 CONFIG_X86_HT=y
-CONFIG_X86_32_LAZY_GS=y
 CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
 CONFIG_ARCH_CPU_PROBE_RELEASE=y
 CONFIG_ARCH_SUPPORTS_UPROBES=y
@@ -452,7 +451,7 @@ CONFIG_ARCH_RANDOM=y
 CONFIG_X86_SMAP=y
 # CONFIG_EFI is not set
 # CONFIG_SECCOMP is not set
-# CONFIG_CC_STACKPROTECTOR is not set
+CONFIG_CC_STACKPROTECTOR=y
 # CONFIG_HZ_100 is not set
 CONFIG_HZ_250=y
 # CONFIG_HZ_300 is not set
  • 上述CONFIG_X86_32_LAZY_GSCONFIG_CC_STACKPROTECTOR是依賴關係,去除CONFIG_X86_32_LAZY_GS配置需要選擇CONFIG_CC_STACKPROTECTOR=y
  • 如果開啟上述核心配置選項出現核心編譯錯誤error: undefined reference to '__stack_chk_guard',請參考本人的另外一篇文章: Linux編譯x86架構核心出現_stack_chk_guard未定義錯誤

總結

好了,此問題解決了,但是還有很多疑點沒有搞清楚,這個最要命了,作為開發,不瞭解整個流程總是心裡沒底,不踏實.但是還是得慢慢來,後續就是對整個GDT以及記憶體進行學習

感謝

2017 …… ,捲起褲管跑,擼起袖子幹!

相關推薦

Linux系統呼叫__get_thread獲取TLS失敗導致應用程式

背景 Android模擬器執行在PC端,Android應用執行在模擬器內部,當PC機在BIOS中沒有開啟虛擬化技術(vt-x: intel的硬體虛擬化技術; AMD-V: AMD CPU的硬體虛擬化技術)的時候,在模擬器內部執行ARM庫的遊戲,出現崩潰或者執行

Android UI效能優化實戰 解決佈局複雜導致程式

1、概述 2015年初google釋出了Android效能優化典範,發了16個小視訊供大家欣賞,當時我也將其下載,通過微信公眾號給大家推送了百度雲的下載地址(地址在文末,ps:歡迎大家訂閱公眾號),那麼近期google又在udacity上開了系列類的相關課程

linux系統呼叫函式 lstat--獲取檔案屬性

所需標頭檔案: #include<unistd.h> #include<sys/stat.h> #include<sys/types.h> 函式功能:用來獲取linux作業系統下檔案的屬性。 函式原型: int st

Linux下通過ioctl系統呼叫獲取和設定網路資訊

#include <stdio.h>#include <stdlib.h>#include <string.h>#include <unistd.h>#include <sys/ioctl.h>#includ

多種方法獲取sys_call_table(linux系統呼叫表)的地址

一.方法一:常用方式,也是一google一堆的方式 我們首先需要找到call table-with-offset的特徵,先看下面的程式碼 syscall_call:         call *sys_call_table(,%eax,4) 假設我們沒有vmlinux可供

arm linux 系統呼叫過程

在Linux下系統呼叫是用軟中斷實現的,下面以一個簡單的open例子簡要分析一下應用層的open是如何呼叫到核心中的sys_open的。 t8.c 1: #include <stdio.h> 2: #include <sys/types.h> 3:

一次性講明白Linux系統呼叫(1)

什麼是系統呼叫 Linux核心中設定了很多可以實現各種系統功能的子程式,這些子程式就叫系統呼叫。而系統呼叫和普通函式呼叫的區別主要是在系統呼叫是系統提供的,函式一般是函式庫或者自己提供的。 為什麼要用系統呼叫 其實很多我們平時用的C語言標準函式,在Linux

linux 系統呼叫 inotify & epoll

一、inotify 作用: 監控一個目錄下檔案的增加、刪除事件 1.重要的資料結構 // 發生的event結構 struct inotify_event {     __s32       wd;       &nb

linux 系統呼叫open 七日遊(二)

接著昨日的旅程,我們應該開始處理具體的子路徑了: 【fs/namei.c】 sys_open->do_sys_open->do_filp_open->path_openat->link_path_walk 點選(此處)摺疊或開啟 &n

linux系統呼叫open七日遊(一)

友情提示:您需要一個 kernel 3.15.6,下載地址: https://www.kernel.org/pub/linux/kernel/v3.0/linux-3.15.6.tar.xz     我們將以 Linux 系統呼叫 open 為主線,參

Linux 系統呼叫 open 七日遊(七)

【場景三】open(pathname, O_WRONLY | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR)     在這個場景中我們希望建立一個新檔案(O_CREAT),並賦予該檔案使用者可讀(S_IRUSR)和使用者可寫(S_IW

Linux——Linux系統命令列獲取公網IP的方法

今天介紹一些檢視linux系統公網IP的方法 1.通過訪問ipconfig.co來檢視。 命令列如下: #更多用法訪問ifconfig.co wget -qO - ifconfig.co 2.通過curl來獲取IP 如果沒有curl,要先下載安裝curl sudo yum i

time, ctime, sleep, exit等Linux系統呼叫使用方法

作業系統實驗時候整理的一些知識點。有小錯請見諒哦。 (1)Linux中time命令是用來計算某個程式的執行耗時(real),使用者態cpu耗時(user),系統態cpu耗時(sys)。 (2)time命令最常用的使用方式就是在其後面直接跟上命令和引數:time <command>

Linux 環境程式設計——Linux系統呼叫

系統呼叫概述 系統呼叫,顧名思義,說的是作業系統提供給使用者程式呼叫的一組“特殊”介面。使用者程式可以通過這組“特殊”介面來獲得作業系統核心提供的服務,比如使用者可以通過檔案系統相關的呼叫請求系統開啟檔案、關閉檔案或讀寫檔案,可以通過時鐘相關的系統呼叫獲得系統時間或設定定時器等。 從邏輯上來說

linux系統呼叫SYSCALL_DEFINE

核心程式碼中系統呼叫都是:SYSCALL_DEFINEx 巨集,x表示引數個數。 這個巨集參考部落格: http://blog.csdn.net/hxmhyp/article/details/22699669 # 和 ## 使用參考部落格: http://www.linuxid

Linux系統呼叫--getrlimit()與setrlimit()

功能描述: 獲取或設定資源使用限制。每種資源都有相關的軟硬限制,軟限制是核心強加給相應資源的限制值,硬限制是軟限制的最大值。非授權呼叫程序只可以將其軟限制指定為0~硬限制範圍中的某個值,同時能不可逆轉地降低其硬限制。授權程序可以任意改變其軟硬限制。RLIM_INFINITY的值表示

linux系統呼叫原理及實現

linux系統呼叫 系統呼叫是linux核心為使用者態程式提供的主要功能介面。通過系統呼叫,使用者態程序能夠臨時切換到核心態,使用核心態才能訪問的硬體和資源完成特定功能。系統呼叫由linux核心和核心模組實現,核心在處理系統呼叫時還會檢查系統呼叫請求和引數是否正確,保證對特

Linux系統修改/etc/profile檔案後導致輸入密碼正確迴圈登陸

問題描述:在Linux系統下安裝eclipse,在為其配置環境變數,任意修改了/etc/prfile 檔案。導致在開啟Linux系統時,登入即使輸入密碼正確也無法進入系統(反覆的跳回輸入密碼介面) 工作環境:我是Windows10加Ubuntu16.4雙系統(此

Linux系統呼叫索引

本系列計劃把Linux的所有系統呼叫都扒一遍,詳細解釋每個系統呼叫的功能,用法,使用示例,應用場景和注意事項。 系統中支援的系統呼叫列表及編號都定義在 /usr/include/asm/unistd.h檔案下。 以下的列表來源於64位的CentOS 7系統,詳解連結後面會

Linux系統呼叫

一、系統呼叫概述   系統呼叫,顧名思義,說的是作業系統提供給使用者程式呼叫的一組“特殊”介面。使用者程式可以通過這組“特殊”介面來獲得作業系統核心提供的服務,比如使用者可以通過檔案系統相關的呼叫請求系統開啟檔案、關閉檔案或讀寫檔案,可以通過時鐘相關的系統呼叫獲