2017-05-29 19 views
0

カーネル4.10.1でLinux上で動作するアプリケーションを移植しました。プログラムの失敗は__GI_abort()呼び出しでハングしたように見え、後でエラーログファイルの書き込みに失敗したプロセスに対してSIGABRTが発行されました。この同じプログラムはLinuxカーネル2.6で動作します。スタックトレースとコードが添付されています。どんな提案も役に立ちます。ありがとう。 gccのバージョン6.3.1 20161221(Red Hatの6.3.1-1)(GCC)fopenでCプログラムが失敗し、スタックトレースが添付されました

:アプリケーションがコンパイルされた

我々は以前のgcc 6.3.1 を使用して4.10.1カーネルとアプリケーションの両方を作っていました

スタックトレース:

(gdb) where 
#0 __lll_lock_wait_private() at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 
#1 0x00007f8f1c16ffb2 in __GI___libc_malloc (bytes=140252631706336, [email protected]=552) at malloc.c:2923 
#2 0x00007f8f1c15905d in __fopen_internal (filename=0x7ffeb54deac0 "/tmp/logs/app_exit.log", mode=0x497fc2 "a+", is32=1) at iofopen.c:69 
#3 0x0000000000477690 in fep_sigbus_handler (signum=6, info=0x7ffeb54decb0, ptr=0x7ffeb54deb80) at app_util.c:559 
#4 <signal handler called> 
#5 __GI_raise ([email protected]=6) at ../sysdeps/unix/sysv/linux/raise.c:58 
#6 0x00007f8f1c12151a in __GI_abort() at abort.c:89 
#7 0x00007f8f1c169d68 in __malloc_assert (
    [email protected]=0x7f8f1c277f90 "(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)", [email protected]=0x7f8f1c274807 "malloc.c", [email protected]=2403, 
    [email protected]=0x7f8f1c2787d8 <__func__.11266> "sysmalloc") at malloc.c:301 
#8 0x00007f8f1c16d5b6 in sysmalloc ([email protected]=560, av=0x7f8f1c4aaae0 <main_arena>) at malloc.c:2400 
#9 0x00007f8f1c16e63a in _int_malloc ([email protected]=0x7f8f1c4aaae0 <main_arena>, [email protected]=552) at malloc.c:3862 
#10 0x00007f8f1c16ff14 in __GI___libc_malloc ([email protected]=552) at malloc.c:2925 
#11 0x00007f8f1c15905d in __fopen_internal (filename=0xf4cda4 <file_tbl+4> "/etc/app_config.dat", mode=0x48b735 "r", is32=1) 
    at iofopen.c:69 
#12 0x000000000042e96c in load_conversion_file (filename=0xf4cda4 <file_tbl+4> "/etc/app_config.dat") at app_config.c:1817 
#13 0x000000000042ebc2 in load_all_conversion_files() at app_config.c:1864 
#14 0x000000000042eeb9 in app_config_init() at app_config.c:1958 
#15 0x0000000000403d9e in main (argc=1, argv=0x7ffeb54df6e8) at app_main.c:271 

static int load_conversion_file(const char* filename) 
{ 
    int  rc = FAILURE; 
    FILE* fd = NULL; 
    int  parsedbg = (app_debug_mask & APP_DBG_PARSECONV) ? 1 : 0; 
    AppCfg* pcfg; 

    pcfg = (AppCfg*) malloc(sizeof(AppCfg)); 

    if (pcfg == NULL) 
     LOG(APP_DBG_ERROR, BLANK_TID, ("error allocating AppCfg\n")); 

    else if ((fd = fopen(filename, "r")) == NULL) 
     LOG(APP_DBG_CONFIG, BLANK_TID, ("error opening conversion file: %s\n", 
               filename)); 

    else if (app_parse_file(fd, pcfg, parsedbg) != 0) 
     LOG(APP_DBG_CONFIG, BLANK_TID, ("Parser error %s on line %d at token <%s>\n", 
               app_parser_get_error_string(), 
               app_parser_get_error_line(), 
               app_parser_get_error_token())); 
. 
. 
. 
} 
+2

コードのどこかにヒープの破損があるように見えます。それを見つけるためにvalgrindとそれを実行してみてください。 – kolrabi

答えて

0

)あり関数のいずれかでのcalloc()メモリ割り当てがあったが、この機能は、(従来のfopenに呼ばれました。その関数には、呼び出し元のバッファにデータが格納され、最後のエントリを過ぎたコードがあります。それを修正した後、問題は解決されます。しかし、古いバージョンのgccでビルドされたlinuxの以前のバージョンのコードは、malloc()でアサートして中断しませんでした。

+0

異なるライブラリのバージョンでは、処理が異なります。なぜ新しいバージョンを持っているのでしょうか?より新しいアロケータは、複数のスレッド、メモリの断片化などでよりうまくいく可能性が高いです。間違ったことをすると失敗することがあります。 –

関連する問題