Looking at the Underfoot source I see that most of the buffers used to parse text coming from the server seem to use this for their size.

#define MAX_STRING 2048

Any chance of increasing this to 4096 to match the longest message that will be sent from the emu through Client::Message()?

That constant is used in hundreds, possibly thousands of different spots in the MQ client. The impact of changing that value would be highly unpredictable.

In the latest Underfoot source available for download it is used ~569 times to allocate memory, all but one on the stack from what I can see. It is passed to a function, presumably as a buffer size, ~126 times.

I compiled with the change and didn't see any issues, although my testing was not exhaustive by any measure. Since all but one of the allocations are on the stack I would guess it wouldn't cause any issues, but I respect the desire not to make a huge change just to accommodate a minor edge case.

I could never catch the issue in the debugger, but through trial and error I was able to narrow it down and solve my particular issue by changing these 2 lines:

MQ2Emu_Underfoot_Source\MQ2Main\MQ2Globals.cpp(134):CHAR EventMsg[MAX_STRING*2]={0};
MQ2Emu_Underfoot_Source\MQ2Main\MQ2Globals.h(143):LEGACY_VAR CHAR EventMsg[MAX_STRING*2];

I would guess that it probably crashes here:

VOID CheckChatForEvent(PCHAR szMsg)
{
strcpy(EventMsg,szMsg);

If you're interested in duplicating the issue yourself, you can log into a server running v2049 or later with a GM account and type #mysql query "select * from items where id = 1001"

If it silently ignored those long lines, maybe by using strncpy or strcpy_s instead of popping up the crash dialog it would be helpful for those times when I forget to unload MQ2. I suppose I could also switch over to using my own compiled version, but there are a couple of plugins in the distribution that I never got around to compiling myself.

Anyway, thanks for the response. If I had thought about it a little more instead of shaking my fist and cursing mq2 I would have realized it's not exactly a reasonable request. :)

It's not a crazy request or anything =)

I'll make a note to add your changes into the next rebuild of mq2main.dll. Tweaking those two specific vars shouldn't be to big a deal. More-so if you have been using it and it doesn't seem broken.

Have you encountered any places where a non-GM account might be surprised by a crash?

Oh, with all the plugins added into the project including the ones with private source code the count was 1542 instances. =)

I can't think of any place where the server would generate such a long string other than from some of the # commands. I'd guess if it was a common thing there would be more complaints. :)

strcpy_s is easiest solution here; the client (even live) is still set to 2048 string size allocation. EQEMU likes to send a lot of non-standard data, and most of the opcodes are still utilizing the same original structure when they were initially mapped out so many years ago. There are a lot of instances where EQEMU is sending something as an uint16, when it should be an int8. I don't think anyone is really interested in investing enough hours into fixing it all. I started on the task a while ago, and was suggesting changes to Secrets but I never saw any of it actually get committed.

I thought the client might have a length restriction on parsing data, but I tested the Underfoot client with 4000 bytes strings and it displayed them properly. It's possible that earlier clients had different restrictions, but I didn't test those.