FoM Port Problems

I finally sat down today in hopes of tracking down some of the bugs we encountered at FoM last April. The bug that kept crashing the mud in the latter half had something to do with the MUD completely locking up when someone disconnected during pre-load (i.e. typing in a wrong password). Of course, I can't seem to reproduce that error now, so I've put that one on the backburner for the time being.

The one I can look into is a bug with copyover. Whenever I use copyover and someone is connected to the FoM port, the MUD locks into a loop somewhere during or after copyover_recover, logging "Write_to_descriptor: Bad file number" indefinitely. This doesn't happen when we only have ppl connected to main/java ports; just fom and fomjava. I am at a total loss to find anything wrong with either of them. I tried searching for "Bad file number"; absolutely no instance of that (or "Bad file" or "file number" for that matter) anywhere in the source! Aside from wondering how that error is being generated if it doesn't seem to exist in the code anywhere, I also have no idea what it means, aside that there's -probably something- (not very specific, eh?) wrong with the fom descriptors. I can't even do a basic debug without knowing where the error is coming from in the first place (I'm guessing 'write to descriptor', but I can't see how).

Could you give me some general info on what that bug means, any suggestions, etc? At this point, I'm dead stumped.

Thanks =)

First off, I don't know much about the FoM ports nor do I even have the capability to use them in my mud. However I can explain your error a bit and maybe that'll send you in the right direction. The error you're getting is generated by this line in comm.c:

perror( "Write_to_descriptor" );

It's a system error, hence searching for 'Bad file number' returned no results. In unix all open files as well as socket connections are given a file descriptor. The error you received was generate because the mud tried to send data to a descriptor that either didn't exist or had become corrupt (the second option is unlikely). Without having FoM based port code in front of me or the copyover code you're using I don't know where to send you looking exactly. If I were to guess at a possible problem, the copyover code may be recording the number of connected fom users incorrectly (or not at all) and when the mud tries to reconnect to those users its sending data to the wrong places. Search your copyover recovery code for all instances of write_to_descriptor (or write_to_descriptor_old in some cases) and take a look in those areas regarding fom ports.

Hehe tnx for the info on descriptor stuff. Actually, FoM stands for "Festival of MUD"; the open ports created for it I wrote myself. So someone could connect to, say, port+500 and be treated differently than if connected to port+0. Basically the same concept behind having a java/telnet port.

Thing is, copyover works just fine so long as nobody is connected to port+500 (confom) or port+600 (confomjava); i.e. port+0 (control), port+100 (conjava), and the I3 port (don't remember which it is) don't cause any problems with copyover when used. However, I checked and re-checked, and I'm using confom and confomjava in exactly the same manner and places as the ones that are working; I can't figure out how this is messing-up the descriptors.

I could just refrain from using copyover during FoM, but that is likely the symptom of a bigger problem with the ports/descriptors/whatever. It may help eliminate other mysterious lockup/crash bugs I encountered....