summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2009-07-07 22:38:38 +0200
committerThomas Schwinge <tschwinge@gnu.org>2009-07-07 22:38:38 +0200
commit98cbdda2b515b108b74c9228814bebb0e071ce00 (patch)
tree9d17d5d93d840424d097854eca172c467624be26 /open_issues
parentc1a671852e57a3219ddb842f83e2ee4cf0915c32 (diff)
Issues with the crash servers.
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/crash_server.mdwn152
1 files changed, 152 insertions, 0 deletions
diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn
new file mode 100644
index 00000000..71f495cc
--- /dev/null
+++ b/open_issues/crash_server.mdwn
@@ -0,0 +1,152 @@
+[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+Given an `a.out` executable that only does `raise (SIGABRT)`, invoking that
+one...
+
+ * ... against `crash-dump-core` will...
+
+ * ... not overwrite existing `core` files.
+
+ Is this reasonable? Linux does overwrite them, for example.
+
+ * ... show big variances in running-time behavior:
+
+ $ TIMEFORMAT='real %R user %U system %S'
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.350 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 22.771 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.367 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 5.789 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
+ Aborted (core dumped)
+ real 22.664 user 0.010 system 0.000
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:01 core
+
+ * ... produce a huge `core` file:
+
+ $ du -hs core
+ 17M core
+
+ On Linux, the `core` file occupies 76 KiB of disk space, which seems
+ much more reasonable.
+
+ * ... produce an invalid `core` file:
+
+ $ gdb a.out core
+ warning: core file may not match specified executable file.
+ [New Thread 76651]
+
+ warning: Wrong size fpregset in core file.
+ Reading symbols from /lib/libc.so.0.3...[...]
+ Core was generated by `./a.out'.
+ Program terminated with signal 6, Aborted.
+
+ warning: Wrong size fpregset in core file.
+ #0 0x00000000 in ?? ()
+ (gdb) bt
+ #0 0x00000000 in ?? ()
+ Cannot access memory at address 0x17
+
+ [[!tag open_issue_gdb]] Probably the `crash` server code and [[GDB]] are
+ out of sync.
+
+ * ... against `crash-suspend` will...
+
+ * ... not work at all:
+
+ $ CRASHSERVER=/servers/crash-suspend ./a.out
+ $ [returns to the shell and doesn't suspended]
+
+ * ... show big variances in running-time behavior:
+
+ $ TIMEFORMAT='real %R user %U system %S'
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.381 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.332 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 21.228 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.323 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 22.279 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.362 user 0.000 system 0.000
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 21.110 user 0.000 system 0.000
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+ $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted (core dumped)
+ real 1.350 user 0.000 system 0.020
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+
+ * ... can reliably crash GNU Mach:
+
+ This happens if a `core` file is already present (and won't get
+ overwritten; see above). I reproduced this three times.
+
+ $ TIMEFORMAT='real %R user %U system %S'
+ $ time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
+ Aborted
+ real 2.856 user 0.000 system 0.010
+ -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core
+
+ panic: zalloc: zone kalloc.8192 exhausted
+ Kernel Breakpoint trap, eip 0x20020a77
+ Stopped at 0x20020a76: int $3
+ db> trace
+ 0x20020a76(2006aba8,4d0f7e9c,200209b0,0,0)
+ 0x20020a4d(2006b094,2006ae40,2000,20016803,4a5f4114)
+ 0x2002bca5(49a03564,1,0,9,1000)
+ 0x20022f4c(2000,4a5f45d4,4a84879c,49a46564,4ac43e78)
+ 0x20021e65(4ac43e78,4a5f45d4,4a5f4114,0,0)
+ 0x2005309d(2106ba9c,3,38,28,1783)
+ Bad frame pointer: 0x2106ba78
+
+ $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020a4d 0x2002bca5 0x20022f4c 0x20021e65 0x2005309d
+ Debugger
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105
+ panic
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:148
+ zalloc
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/zalloc.c:470
+ kalloc
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/kalloc.c:185
+ ipc_kobject_server
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:76
+ mach_msg_trap
+ /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367