C時的讀數很長的線 - 內存問題

-2

我不知道什麼是錯用下面的函數讀取任意長度的文本行：C時的讀數很長的線 - 內存問題

char *GetLine(FILE * f) { 
    size_t size = 0; 
    size_t len = 0; 
    size_t last = 0; 
    char *buf = NULL; 
    bool line_end = false; 

    while (!feof(f) && !line_end) { 
     printf("[GetLine] size = %ld, BUFSIZE = %d\n", size, BUFSIZ); 
     size += BUFSIZ; 
     buf = realloc(buf, size); 
     assert(buf); 
     if (fgets(buf + last, (int) size, f) == NULL) 
      return NULL; 
     len = strlen(buf); 
     // overwrite '\0' at the end of the string that fgets put 
     last = len - 1; 
     if (last >= 0 && buf[last] == '\n') 
      line_end = true; 
    } 

    return buf; 
}

我的測試客戶端很簡單：

int main() { 
    char *line; 

    line = GetLine(stdin); 

    return 0; 
}

它工作得很好，沒有太長的線條（如長度在8,000以下的線條），但它裂縫的長度約爲16,000。我BUFSIZE是8192

這裏是Valgrind的報告：

==14413== WARNING: new redirection conflicts with existing -- ignoring it 
--14413--  old: 0x04017ca0 (strlen    ) R-> (0000.0) 0x38075d61 ??? 
--14413--  new: 0x04017ca0 (strlen    ) R-> (2007.0) 0x04c2c730 strlen 
--14413-- REDIR: 0x4017a50 (ld-linux-x86-64.so.2:index) redirected to 0x4c2c2e0 (index) 
--14413-- REDIR: 0x4017c70 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4c2d880 (strcmp) 
--14413-- REDIR: 0x40189a0 (ld-linux-x86-64.so.2:mempcpy) redirected to 0x4c30330 (mempcpy) 
--14413-- Reading syms from /lib64/libc-2.19.so 
--14413-- REDIR: 0x4eba7f0 (libc.so.6:strcasecmp) redirected to 0x4a23770 (_vgnU_ifunc_wrapper) 
--14413-- REDIR: 0x4ebcae0 (libc.so.6:strncasecmp) redirected to 0x4a23770 (_vgnU_ifunc_wrapper) 
--14413-- REDIR: 0x4eb9f70 (libc.so.6:[email protected]_2.2.5) redirected to 0x4a23770 (_vgnU_ifunc_wrapper) 
--14413-- REDIR: 0x4eb82f0 (libc.so.6:rindex) redirected to 0x4c2bfc0 (rindex) 
--14413-- REDIR: 0x4ec1180 (libc.so.6:strchrnul) redirected to 0x4c2ff40 (strchrnul) 
[GetLine] size = 0, BUFSIZE = 8192 
--14413-- REDIR: 0x4eb0fd0 (libc.so.6:realloc) redirected to 0x4c2b3a0 (realloc) 
--14413-- REDIR: 0x4eb9640 (libc.so.6:memchr) redirected to 0x4c2d920 (memchr) 
--14413-- REDIR: 0x4ebf210 (libc.so.6:__GI_memcpy) redirected to 0x4c2e220 (__GI_memcpy) 
--14413-- REDIR: 0x4eb65f0 (libc.so.6:strlen) redirected to 0x4c2c670 (strlen) 
[GetLine] size = 8192, BUFSIZE = 8192 
==14413== Invalid write of size 1 
==14413== at 0x4C2E4C3: __GI_memcpy (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) 
==14413== by 0x4E9F542: _IO_getline_info (in /lib64/libc-2.19.so) 
==14413== by 0x4E9E475: fgets (in /lib64/libc-2.19.so) 
==14413== by 0x4007B8: GetLine (in /home/.../alfa_1/src/linetest) 
==14413== by 0x400832: main (in /home/.../alfa_1/src/linetest) 
==14413== Address 0x51e3080 is 0 bytes after a block of size 16,384 alloc'd 
==14413== at 0x4C2B41E: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) 
==14413== by 0x400777: GetLine (in /home/.../alfa_1/src/linetest) 
==14413== by 0x400832: main (in /home/.../alfa_1/src/linetest) 
==14413== 

valgrind: m_mallocfree.c:304 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed. 
valgrind: Heap block lo/hi size mismatch: lo = 16448, hi = 3903549025615949881. 
This is probably caused by your program erroneously writing past the 
end of a heap block and corrupting heap metadata. If you fix any 
invalid writes reported by Memcheck, this assertion failure will 
probably go away. Please try that before reporting this as a bug. 


host stacktrace: 
==14413== at 0x3805D3B6: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x3805D4E4: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x3805D666: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x3806A433: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x38056A8B: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x3805556B: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x380593DB: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x38054B67: ??? (in /usr/lib64/valgrind/memcheck-amd64-linux) 
==14413== by 0x808C61F58: ??? 
==14413== by 0x808B99EEF: ??? 

sched status: 
    running_tid=1 

Thread 1: status = VgTs_Runnable 
==14413== at 0x4E9E4E2: fgets (in /lib64/libc-2.19.so) 
==14413== by 0x4007B8: GetLine (in /home/.../alfa_1/src/linetest) 
==14413== by 0x400832: main (in /home/.../alfa_1/src/linetest)

看起來有些堆分配問題（我懷疑realloc），但我不能看到它

來源

2017-05-26 micsza

首先，請看[爲什麼while（！feof（file））總是出錯？]（https://stackoverflow.com/questions/5431941/why-is-while-feof-file-always-wrong] ）。 –

有兩件事：[不要使用'while（！feof（...））']（http://stackoverflow.com/questions/5431941/why-is-while-feof-file-always-wrong），並且不要返回給你傳遞給'realloc'的同一個指針（想想如果'realloc'返回'NULL'會發生什麼）。 –

不是'last> = 0'會引發編譯器警告？（或者你是否忘記啓用編譯器警告？）由於'last'是無符號的，所以比較必須是真的，如果'len'爲0，會導致問題。另外，如果'fgets'返回'NULL'，你只要返回。這會泄漏內存並有效地丟棄當前行，因此如果您的輸入不以換行符結束，則最後一行將被放入bitbucket中。這並不嚴格地說是錯誤的 - 文本文件不應該有未終止的行 - 但它可能會令人驚訝。 – rici

問題的確切來源是在這裏：

fgets(buf + last, (int) size, f)

如果last不爲零，則fgets調用可以寫出你的BU的界限FFER。您最多需要讀取size - last字節。

來源

2017-05-26 13:07:29

C時的讀數很長的線 - 內存問題

回答

相關問題