zone crashing

[lerxst2112]

The information is likely to be anecdotal and not useful in tracking down the issue. In order to track down the issue and fix it the server owner would need to add debugging info to their zone process and either catch the crash in the debugger or in a minidump. Information on how to do both has been mentioned here many times.

I suspect that zone may be running out of memory due to a pretty easy to cause memory leak. It's a small leak, but given where it is and how easy it is to cause it could be the problem.


This code leaks 4k every time a message is blocked due to filters:

void Client::Message(uint32 type, const char* message, ...) {
	va_list argptr;
	char *buffer = new char[4096];

	if (GetFilter(FilterSpellDamage) == FilterHide && type == MT_NonMelee)
		return;
	if (GetFilter(FilterMeleeCrits) == FilterHide && type == MT_CritMelee) //98 is self...
		return;
	if (GetFilter(FilterSpellCrits) == FilterHide && type == MT_SpellCrits)
		return;

	va_start(argptr, message);
	vsnprintf(buffer, 4096, message, argptr);
	va_end(argptr);

	size_t len = strlen(buffer);

	//client dosent like our packet all the time unless
	//we make it really big, then it seems to not care that
	//our header is malformed.
	//len = 4096 - sizeof(SpecialMesg_Struct);

	uint32 len_packet = sizeof(SpecialMesg_Struct)+len;
	EQApplicationPacket* app = new EQApplicationPacket(OP_SpecialMesg, len_packet);
	SpecialMesg_Struct* sm=(SpecialMesg_Struct*)app->pBuffer;
	sm->header[0] = 0x00; // Header used for #emote style messages..
	sm->header[1] = 0x00; // Play around with these to see other types
	sm->header[2] = 0x00;
	sm->msg_type = type;
	memcpy(sm->message, buffer, len+1);

	FastQueuePacket(&app);

	safe_delete_array(buffer);
}

This code does not leak:

void Client::Message(uint32 type, const char* message, ...) {
	if (GetFilter(FilterSpellDamage) == FilterHide && type == MT_NonMelee)
		return;
	if (GetFilter(FilterMeleeCrits) == FilterHide && type == MT_CritMelee) //98 is self...
		return;
	if (GetFilter(FilterSpellCrits) == FilterHide && type == MT_SpellCrits)
		return;

	va_list argptr;
	char buffer[4096];
	va_start(argptr, message);
	vsnprintf(buffer, sizeof(buffer), message, argptr);
	va_end(argptr);

	size_t len = strlen(buffer);

	//client dosent like our packet all the time unless
	//we make it really big, then it seems to not care that
	//our header is malformed.
	//len = 4096 - sizeof(SpecialMesg_Struct);

	uint32 len_packet = sizeof(SpecialMesg_Struct)+len;
	EQApplicationPacket* app = new EQApplicationPacket(OP_SpecialMesg, len_packet);
	SpecialMesg_Struct* sm=(SpecialMesg_Struct*)app->pBuffer;
	sm->header[0] = 0x00; // Header used for #emote style messages..
	sm->header[1] = 0x00; // Play around with these to see other types
	sm->header[2] = 0x00;
	sm->msg_type = type;
	memcpy(sm->message, buffer, len+1);

	FastQueuePacket(&app);
}

My advice is try making sure the above mentioned filters are off. The server owner could also try replacing the first bit of code with the second and seeing if it helps.

[trevius]

Very nice catch, Lerxst2112! I think you may have just solved one of the main EQEmu memory leaks. I know Lillu was telling me that he noticed memory leaks in their zones while in combat, but no leaks while just standing around. I am sure there are still other leaks, but that should be a pretty big one. I can imagine seeing that leak grow quickly in a raid scenario.