Andreas Vogl wrote: > > The following bug is causing the great instability of > our servers these days. Let's try to fix it. > > > [...] > > Saving map /pup_land/begin/p1 > > Resetting map /pup_land/raffle/raffle1. > > Internal error in update_button (6666). > > Internal error in update_button (6666). > > Internal error in update_button (6666). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > Internal error in update_button (small button). > > > > .... (crash.) > > First of all, the bug is very easy to reproduce: > - Take the map "/pup_land/raffle/raffle1" and set the fixed reset down to > 10. > - Then start a crossfire server, log in with a char > - Enter the raffle1, leave it again, and wait for a short while > => server crashes, the log looks pretty much like above. Thanks for letting me know how to reproduce it. I always like bugs that are easy to reproduce. The real cause is harmless, or at least mostly harmless. What is happening when we delete the map (without saving it), is that delete_map is called, which then calls free_all_objects (which does as it suggests - frees all the objects on the map). This is fine and dandy, but then that goes through and calls remove_ob, which then goes and checks walk on/fly on/ other flags, and if it gets one, calls move_apply, which then looks at the space, and trys to do something. What is happening now is that some of the objects in the button links have gotten freed by the time remove_ob does it stuff, resulting in the error message. I have a simple fix that I'll check in later tonight - basically, if we set the map status to MAP_SAVING, remove_ob does a lot less processing (skips all the walk on/fly on stuff), which is why you don't get those errors on normal map savings. So before calling the free_all_objects, I just set that flag. Seems to work fine.