SB 1.2.5 Linux client crash

[edgan]

Anyone had a problem running Seventeen or Bust 1.2.5 on a Fedora Core 2 box?

It seems to work fine on many Intel boxes running FC2, and works on my Fedora Core 3 development box with Athlon XP processor. It crashes on my Fedora Core 2 box with Athlon XP processor. I thought it might be related to gethostname, but it seems to be more related to time, though exactly how I am not sure. All the FC2 boxes including the one that crashes are using the same version of glibc and kernel. I also don't have a problem with the SB 2 test release FC2 P4 boxes. /proc/cpuinfo does shows the same set of flags for both XPs, including sse and 3dnow. I tried syncing the time of the box that crashes, and updating the hardware clock with no results.

Box that crashes:

write(1, "[Mon Oct 18 19:56:00 2004] serve"..., 56[Mon Oct 18 19:56:00 2004] server packet cached to disk
) = 56
time([1098154560]) = 1098154560
--- SIGSEGV (Segmentation fault) @ 0 (0) ---


Box that works:

write(1, "[Mon Oct 18 20:04:17 2004] got k"..., 50[Mon Oct 18 20:04:17 2004] got k and n from cache
) = 50
time([1098155057]) = 1098155057
rt_sigaction(SIGILL, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL}, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, 8) = 0
rt_sigaction(SIGILL, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL}, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, 8) = 0
rt_sigaction(SIGILL, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL}, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, 8) = 0
rt_sigaction(SIGILL, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL}, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, 8) = 0
rt_sigaction(SIGILL, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGILL, {SIG_DFL}, {0x80491a4, [ILL], SA_RESTORER|SA_RESTART, 0x138718}, 8) = 0
gettimeofday({1098155057, 258877}, {420, 0}) = 0
gettimeofday({1098155057, 259143}, {420, 0}) = 0
gettimeofday({1098155057, 307604}, {420, 0}) = 0
gettimeofday({1098155057, 307889}, {420, 0}) = 0

[edgan]

Another difference I had noticed between the FC2/Intel boxes and the crashing FC2/AMD box is that I was running as root on the Intel boxes, but not on the AMD box. I tried running it as root with a fresh client with the same results.

[royanee]

Does mprime's stress test work? I know that I had a problem with system stability (see sieving forum for info).

[edgan]

I tried running 23.5 of mprime, but it seg faulted. I then found 23.9, which ended up being 23.9.2.

Linux version 23.9. Solves a crash problem that occured when running on Fedora core 2 with kernel 2.6.8.1. I hope it doesn't cause older linux installs problems....


I wonder if mprime's former problem is the same problem I have with sb 1.2.5, or at least is similar.

[edgan]

I narrowed it down to /proc/sys/vm/legacy_va_layout. I found things weren't as consistant as I thought they where. The new SB 2 test seems to fix the legacy_va_layout issue, while the older version does not. I am using the SB 2 test version on all the computers with a P4/Celeron. The P3s were exceptions in two different ways. One had legacy_va_layout set to 1 for TeamSpeak, and the other was running an older kernel which doesn't have legacy_va_layout. Which leaves the FC2 XP box with the latest kernel, not test release, and lack of legacy_va_layout.

Setting the proc setting below will workaround the problem with SB 1.2.5.

echo 1 > /proc/sys/vm/legacy_va_layout