JTP wrote: Seems there is something messing in the Stock code to prevent a crash. It has happened 3 times in a year now.
One of the attached pictures is the backtrace
This is BAD. The code around the crashing line looks like this:
Code:
case CON_NAME_CNFRM: /* wait for conf. of new name */
if (UPPER(*arg) == 'Y') {
if (isbanned(d->host) >= BAN_NEW) {
mudlog(NRM, LVL_GOD, TRUE, "Request for new char %s denied from [%s] (siteban)", GET_PC_NAME(d->character), d->host);
write_to_output(d, "Sorry, new characters are not allowed from your site!\r\n");
STATE(d) = CON_CLOSE;
return;
}
if (circle_restrict) {
write_to_output(d, "Sorry, new players can't be created at the moment.\r\n");
mudlog(NRM, LVL_GOD, TRUE, "Request for new char %s denied from [%s] (wizlock)", GET_PC_NAME(d->character), d->host);
STATE(d) = CON_CLOSE;
return;
}
perform_new_char_dupe_check(d);
write_to_output(d, "New character.\r\nGive me a password for %s: ", GET_PC_NAME(d->character));
echo_off(d);
STATE(d) = CON_NEWPASSWD;
But the innocent call to perform_new_char_dupe_check(d) can alter the connectedness (and in particular, can close close the connection as well as nulling out d->character, which causes the crash).
The log statement you are showing tells us as much.
So, what is really happening here? Well, nanny() is buggy - I think it really could use a cleanup. It seems we are getting a situation where we have no player file for a player that is logged in. Then, a second attempt with the same name will trigger the dupe_check. There may be more ways to reach this situation, but that one will surely cause it.
One, simple, band-aid could be to do this:
Code:
if (!perform_new_char_dupe_check(d)) {
write_to_output(d, "New character.\r\nGive me a password for %s: ", GET_PC_NAME(d->character));
echo_off(d);
STATE(d) = CON_NEWPASSWD;
}
But it doesn't fix the underlying issue.
