ID:101624
 
Resolved
Changes to the ban list could cause a crash in some cases.
BYOND Version:475
Operating System:Windows XP Home
Web Browser:Firefox 3.5.11
Applies to:Dream Daemon
Status: Resolved (476)

This issue has been resolved.
Descriptive Problem Summary:

Dream Daemon has been crashing for awhile now, but usually, when I host ban or host kick someone, then unhost ban them, Dream Daemon crashes, and asks to send an error report, meaning the server is dead.

Numbered Steps to Reproduce Problem:

1. Open Dream Daemon.
2. Host a game.
3. Kick a player.
4. Unban the player.

I don't think it always happens, though.

Code Snippet (if applicable) to Reproduce Problem:


Expected Results:

Hosting without crashing constantly.

Actual Results:

Server crashes whenever someone is punished by the host, or crashes without even punishing.

Does the problem occur:

Every time? Or how often?
Not every time, only a few. And it sometimes crashes within a few hours of being hosted.

In other games?
I've encountered it before.

In other user accounts?
Yes.

On other computers?
Haven't tested.

When does the problem NOT occur?

When you don't ban someone, or the server has only been on for an hour or two.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Happened in all the versions up to now.

Workarounds:

Don't know of any.
We'll need crash details to be able to investigate this report. What you need to do is enable Dr. Watson by going to Start | Run... and typing "drwtsn32 -i". The next time you get a crash, Dr. Watson will create a minidump file. You can get the contents of that file and post a comment here with all the information within.
It should have created a file called Drwtsn32.log. Go back to Start | Run... and just type in "drwtsn32". That should bring up the configuration for the program, and the first item listed is the log file path. Open up that directory and then open up Drwtsn32.log in an editor like Notepad. Copy and paste the contents.
Based on your trace, I found what appears to be a loophole in an earlier fix to an issue much like this. I'll have to do considerable testing to see if I can reproduce the bug and confirm the fix, but I think I have the fix ready to go. Thanks for providing that info.
The newer trace seems to be an unrelated issue. I recommend you post a separate bug report for that one.
I'm confident of the fix for your first trace. Please post your second trace in a new report.