stack-dump

how to debug using “*.stackdump” file in cygwin

由 ╄→尐↘猪︶ㄣ 提交于 2019-12-12 17:51:26
问题 I am newbie on cygwin(and linux). When I tried to run my executable file based on C language, segmentation fault occured, and I take stackdump file. but, I don't know how to use it for debugging. I have been searching for the way how to debug using stackdump file, but I cound't find it. Any small tips are very useful to me. thanks for reading my poor english (english is not my 1st language). 回答1: First : you need to compile your program passing to gcc the flag -ggdb otherwise the stackdump

How to analyze core dump

由 五迷三道 提交于 2019-12-06 00:46:29
问题 After application[rtorrent] crashed, it produced core file, 250MB. Caught Segmentation fault, dumping stack:B] [Port: 58940][U 0/0] [D 0/10] [H 1/32] [S 72/75/768] [F 0/128] Stack dump not enabled. Aborted (core dumped) What I need is to analyze and see the stack trace, to have clue why rtorrent is crashing so often. 回答1: gdb should be able to analyse the core: gdb /path/to/binary/rtorrent /path/to/coredump/rtorrent.core type where to see stack trace. To see more: compile rtorrent with debug

Why is this Hotspot JVM option not the default? -XX:+PrintConcurrentLocks

由 房东的猫 提交于 2019-12-05 22:49:39
问题 By default, with Hotspot, a CTRL-Break thread dump will not list what threads are holding java.lang.concurrent locks. And I understand that with these locks, Hotspot cannot have information about at which stack frame a lock was acquired. If you add the JVM option -XX:+PrintConcurrentLocks , then a CTRL-Break stack dump will list (after a thread's stack trace) any concurrent locks held by that frame. For example: "D-Java-5-Lock" prio=6 tid=0x00000000069a1800 nid=0x196c runnable

How to analyze core dump

由 ￡可爱￡侵袭症＋ 提交于 2019-12-04 05:22:36
After application[rtorrent] crashed, it produced core file, 250MB. Caught Segmentation fault, dumping stack:B] [Port: 58940][U 0/0] [D 0/10] [H 1/32] [S 72/75/768] [F 0/128] Stack dump not enabled. Aborted (core dumped) What I need is to analyze and see the stack trace, to have clue why rtorrent is crashing so often. gdb should be able to analyse the core: gdb /path/to/binary/rtorrent /path/to/coredump/rtorrent.core type where to see stack trace. To see more: compile rtorrent with debug symbols, run, wait crash and analyse dump with gdb (in this case you can see exact place where crash occurs)

Why is this Hotspot JVM option not the default? -XX:+PrintConcurrentLocks

由 荒凉一梦 提交于 2019-12-04 04:15:21
By default, with Hotspot, a CTRL-Break thread dump will not list what threads are holding java.lang.concurrent locks. And I understand that with these locks, Hotspot cannot have information about at which stack frame a lock was acquired. If you add the JVM option -XX:+PrintConcurrentLocks , then a CTRL-Break stack dump will list (after a thread's stack trace) any concurrent locks held by that frame. For example: "D-Java-5-Lock" prio=6 tid=0x00000000069a1800 nid=0x196c runnable [0x000000000770f000] java.lang.Thread.State: RUNNABLE at com.Tester.longDelay(Tester.java:41) at com.Tester$D.run
订阅 stack-dump