View Single Post
  #1  
Old 09-22-2005, 05:06 PM
Dakaar
Sarnak
 
Join Date: Apr 2003
Posts: 53
Default Strange zone crash in fedora 8( (double free)

**UPDATE** my zone will launch if i remove spells_us.txt is removed.. Its definately crashing loading the file, or not properly unloading(or unloading twice).. Can someone help me figure out exactly what path the code takes going through and loading spells_us.txt? ***

**more update =P** Apparently this is something new to fc3 where it has a MALLOC_CHECK variable, see below
Now with the MALLOC_CHECK i just segfault on loading spells_us.txt
Im running a proper spells_us.txt so somewhere for me, something is not being accessed correctly

>From the Fedora Core 3 release notes:

glibc
The version of glibc provided with Fedora Core 3 performs
additional internal sanity checks to prevent and detect data
corruption as early as possible. By default, should corruption
be detected, a message similar to the following will be displayed
on standard error (or logged via syslog if stderr is not open):

*** glibc detected *** double free or corruption: 0x0937d008 ***

By default, the program that generated this error will also be
killed; however, this (and whether or not an error message is
generated) can be controlled via the MALLOC_CHECK_ environment
variable. The following settings are supported:

0 -- Do not generate an error message, and do not kill the program
1 -- Generate an error message, but do not kill the program
2 -- Do not generate an error message, but kill the program
3 -- Generate an error message and kill the program

Note

If MALLOC_CHECK_ is explicitly set a value other than 0, this
causes glibc to perform more tests that are more extensive than
the default, and may impact performance.

Should you have a program from a third party ISV that triggers
these corruption checks and displays a message, you should
file a defect report with the application's vendor, since this
indicates a serious bug.


[Status] Starting Log: logs/eqemu_zone.log
[Status] Using database 'eqemu' at localhost
[Status] CURRENT_ZONE_VERSION: EQEMu 0.6.2-DR1
[Status] Loading opcodes..
[Status] Mapping Opcodes
[Status] Loading Variables
[Status] Loading zone names
[Status] Loading items
[Status] libEMuShareMem.so loaded
[Status] Loading items from database: count=46073
[Status] Loading npcs
[Status] Loading npc faction lists
[Status] libEMuShareMem.so loaded
[Status] Loading NPC Faction Lists from database...
[Status] Loading loot tables
[Status] Loading Loot tables from database...
[Status] Loading doors
[Status] libEMuShareMem.so loaded
[Status] Loading Doors from database...
[Status] libEMuShareMem.so loaded
[Status] FileLoadSPDat() Loading spells from ./spells_us.txt
*** glibc detected *** double free or corruption (out): 0x091d08f8 ***
Aborted


Is there something in Doors.cpp that does not properly close up its connection or in spells that doesnt open it properly? What is different at all?

hey all. Im running almost the newest CVS (past the corpse update like 9/20ish) and my world works fine, ive compiled my binaries with gcc33 and I can get my zone to load up untill this point.


At this point cleanipcs does not properly get rid of
:------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x49038011 1409024 deadpeople600 23621072 0
0x5a038011 1441793 deadpeople600 18249721 0
0x46038011 1474562 deadpeople600 3872484 0
0x4c038011 1507331 deadpeople600 1323919 0
0x44038011 1540100 deadpeople600 593610 0
0x53038011 1572869 deadpeople600 7462132 0


I have to manually kill these.

Also when i ran my start script that loads 15 zones, it basically brought hte server to a halt indefinately because i presume of all the unattached sos floating around


edit: added kernel info
Linux version 2.6.12-1.1372_FC3 (bhcompile@tweety.build.redhat.com) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 Fri Jul 15 00:59:10 EDT 2005


After changing database.cpp line 2902 i was able to compile with 3.3, 4.0 and 3.4, will any of them work is another question..

Last edited by Dakaar; 09-24-2005 at 08:20 PM..
Reply With Quote