Death causes LD, corpse loss, and zone segfault

[Derision]

The first step in diagnosing a segfault in Linux is to enable core dumps in the shell in which you start eqlaunch:

ulimit -c unlimited

Then, once the zone crashes, you should have a core file, either just called 'core' or 'core.<process number>'.

Fire up gdb:

gdb <path to zone executable> <core file name>

Then once gdb has loaded up and gives you the (gdb) prompt, get a backtrace:

(gdb) bt

That should tell you the source file and line number that the crash occurred at, with a backtrace of how it got there. If you get that far, post the backtrace here and I'll take a look at it.

[cubber]

the core dump:

 gdb zone core 

warning: Can not parse XML syscalls information; XML support was disabled at compile time.
GNU gdb (Gentoo 7.0 p2) 7.0
Copyright (C) 2009 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 "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /opt/eqemu/zone...done.
[New Thread 2054]
[New Thread 2040]
[New Thread 2046]
[New Thread 2053]

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libstdc++.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libmysqlclient.so.15...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libmysqlclient.so.15
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /lib/libcrypt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /usr/lib/libssl.so.0.9.8...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libcrypto.so.0.9.8...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /usr/lib/libperl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libperl.so.1
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/libgcc_s.so.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from ./libEMuShareMem.so...done.
Loaded symbols for ./libEMuShareMem.so
Core was generated by `./zone dynamic_04 zone'.
Program terminated with signal 11, Segmentation fault.
#0  0x0815abee in CRC32::Update (
    buf=0x815aca7 "\367\320\203\304\f\303\220WVS\203\354 \213t$0\213\\$4\307D$\034\377\377\377\377\203\373\003v\025\205\366t\021\271\004", bufsize=141720844, 
    crc32=91) at ../common/crc32.cpp:247
247             );
(gdb)

[Derision]

It appears to be crashing in the assembler in common/crc32.cpp.

Maybe a GCC version related issue (I use 4.1.1 without issue).

A quick thing to try rather than downgrading your GCC version would be to edit common/crc32.cpp and change line 175 from:

#elif defined(i386)

to

#elif defined(i386xxx)

and recompiling, so it should fall back to using the C version of the CRC code instead of the assembler.

[cubber]

Using sys-devel/gcc-4.3.4 . I will try that change and post my results.

[snorkle]

I had to make some changes to get the old VZTZ source to work in Linux. I'm not sure what revision their source was based on but I ended up scrapping it for 8.0. Here's one of the things I had to change to get it to work with newer gcc versions:

vztzfebsource-read-only/common$ svn diff crc32.cpp
Index: crc32.cpp
===================================================================
--- crc32.cpp   (revision 7)
+++ crc32.cpp   (working copy)
@@ -112,6 +112,14 @@
 #undef i386    //darwin seems to think we are generating PIC, and we clobber ebx
 #endif

+/* Some 64bit systems do not like the i386 assembly code below. However, some 64bit
+   systems do work with the assembly code below. We #undef i386 to be on the safe
+   side if we are compiling 64bit. */
+
+#ifdef __x86_64__
+#undef i386
+#endif
+
 uint32 CRC32::Update(const int8* buf, uint32 bufsize, uint32 crc32) {
 #if defined(WIN32)
    // Register use:
@@ -167,8 +175,8 @@
 #elif defined(i386)
        register uint32  val __asm ( "ax" );
        val = crc32;
-
 __asm __volatile (
+       "push   %%ebx\n"
        "xorl   %%ebx, %%ebx\n"
        "movl   %1, %%esi\n"
        "movl   %2, %%ecx\n"
@@ -232,9 +240,10 @@
        "xorb   2(%%esi), %%bl\n"
        "xorl   (%%edi,%%ebx,4), %%eax\n"
    "2:\n"
+       "pop  %%ebx\n"
        :
        : "a" (val), "g" (buf), "g" (bufsize)
-       : "bx", "cx", "dx", "si", "di"
+       : "cx", "dx", "si", "di"
    );

    return val;

[cubber]

This worked!

Originally Posted by Derision

It appears to be crashing in the assembler in common/crc32.cpp.

Maybe a GCC version related issue (I use 4.1.1 without issue).

A quick thing to try rather than downgrading your GCC version would be to edit common/crc32.cpp and change line 175 from:

#elif defined(i386)

to

#elif defined(i386xxx)

and recompiling, so it should fall back to using the C version of the CRC code instead of the assembler.

Thanks a bunch!