Getting eternal waiting while opening 6 GB core file
Andrey Utkin <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CANZNk83N6C=62pKW3TMZ=TDOohTOQeKSmndR3GU0Jcn9-h0_jA@mail.gmail.com> |
Hi. My program crashed while being launched by another person in their private environment (so it is not a good option to re-run app under gdb). They gave me an app binary which produced crash, and a core file. Core file size is ~6 GB, i don't know if it matters. I open it as "gdb app-binary core-file" GNU gdb (Gentoo 7.5.1 p2) 7.5.1 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". For bug reporting instructions, please see: <http://bugs.gentoo.org/>... Reading symbols from /tmp/tvipdrm_scrambler...done. warning: core file may not match specified executable file. [New LWP 13022] ... [New LWP 13061] warning: Can't read pathname for load map: Ошибка ввода/вывода. warning: .dynamic section for "/lib/libpthread.so.0" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libdl.so.2" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/librt.so.1" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libm.so.6" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib/libc.so.6" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/lib64/ld-linux-x86-64.so.2" is not at the expected address (wrong library or version mismatch?) warning: Could not load shared library symbols for 2 libraries, e.g. /usr/lib/libstdc++.so.6. Use the "info sharedlibrary" command to see the complete listing. Do you need "set solib-search-path" or "set sysroot"? And there it hangs forever. I see gdb process loads one processor core for ~100%. "ps axf" shows gdb process state "R+". I thought it's ok, because i have large file, so i left it to work. But it did not show any progress in ~8 hours. So i attached to gdb process with gdb. See backtrace below: (gdb) info threads Id Target Id Frame * 1 Thread 0x7f1283f6f700 (LWP 4307) "gdb" 0x00007f1282933af0 in __lseek_nocancel () from /lib64/libc.so.6 (gdb) bt #0 0x00007f1282933af0 in __lseek_nocancel () from /lib64/libc.so.6 #1 0x00007f12828beffd in _IO_file_seekoff () from /lib64/libc.so.6 #2 0x00007f12828bcf32 in fseeko64 () from /lib64/libc.so.6 #3 0x000000000066c467 in bfd_seek () #4 0x0000000000671819 in _bfd_generic_get_section_contents () #5 0x00000000005b1ee8 in section_table_xfer_memory_partial () #6 0x000000000052b367 in core_xfer_partial () #7 0x00000000005a667d in memory_xfer_partial_1 () #8 0x00000000005a6c6f in target_xfer_partial () #9 0x00000000005a6509 in target_read () #10 0x00000000005a6fd0 in target_read_memory () #11 0x000000000048fad1 in ps_xfer_memory () #12 0x00007f1281f25a93 in td_thr_get_info () from /lib64/libthread_db.so.1 #13 0x00000000004909b1 in find_new_threads_callback () #14 0x00007f1281f255da in iterate_thread_list () from /lib64/libthread_db.so.1 #15 0x00007f1281f2573e in td_ta_thr_iter () from /lib64/libthread_db.so.1 #16 0x0000000000490262 in find_new_threads_once () #17 0x0000000000490581 in thread_db_find_new_threads_2 () #18 0x0000000000492749 in thread_db_find_new_threads_silently () #19 0x0000000000492b7b in try_thread_db_load () #20 0x000000000049341d in check_for_thread_db () #21 0x00000000005b6215 in observer_notify_new_objfile () #22 0x000000000055d240 in symbol_file_add_with_addrs_or_offsets.constprop.17 () #23 0x000000000064e449 in solib_read_symbols () #24 0x000000000064e85b in solib_add () #25 0x0000000000569580 in post_create_inferior () #26 0x000000000052bdcb in core_open () #27 0x000000000058164f in catch_command_errors () #28 0x0000000000583a6b in captured_main () #29 0x000000000058158b in catch_errors () #30 0x0000000000583bf4 in gdb_main () #31 0x0000000000456bbe in main () (gdb) Any ideas how to succeed working with that core? -- Andrey Utkin