|
From: Eyal L. <ey...@ey...> - 2005-01-20 22:38:20
|
Jeremy Fitzhardinge wrote:
[trimmed]
> I'll note that both FC2 and SUSE 9.2 2.6 kernels seem to show sporadic
> problems with delivering signals without proper siginfo information.
> That will cause your program to spontaneously SIGSEGV when it tries to
> grow the stack, which almost every program will need to do. The kernel
> will stay in this state for some indeterminate amount of time, but then
> will spontaneously start working again.
Some further observations. I ran
strace valgrind --tool=memcheck date >date.strace 2>&1
when a crash is reported, and then when one is not. Comparing the
two logs (attached) I note the point when the two diverge:
non-crashing
============
fstat(3, {st_mode=S_IFREG|0644, st_size=78233, ...}) = 0
readlink("/proc/self/fd/3", "/lib/tls/libpthread-0.60.so", 4096) = 27
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
gettid() = 31890
old_mmap(0x52bfd000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x52bfd000
crashing
========
fstat(3, {st_mode=S_IFREG|0644, st_size=78233, ...}) = 0
readlink("/proc/self/fd/3", "/lib/tls/libpthread-0.60.so", 4096) = 27
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
gettid() = 31744
gettid() = 31744
old_getrlimit(RLIMIT_CORE, {rlim_cur=0, rlim_max=2147483647}) = 0
getpid() = 31744
write(1016, "==31744== \n", 11==31744==
) = 11
getpid() = 31744
write(1016, "==31744== Process terminating wi"..., 73==31744== Process terminating with default action of signal 11 (SIGSEGV)
) = 73
I note that there is always a "SIGSEGV (Segmentation fault)"
present, even in a good run. It is the reaction to it that
differs. Is it possible that there is a special SIGSEGV
(in vg or glibc) that is overloaded (not a real segfault)
and should be handled specially?
BTW, The 'good' run was done after a fresh boot, to ensure
the kernel is not in any 'funny' state. Just in case.
--
Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/>
attach .zip as .dat
|