Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, Sogou

Members: 0
Guests: 10
Stats
Files
Topics
Posts
Members
Newest Member
481
3,739
19,386
621
KellieBusb
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Smaug Snippets » DNS Resolver issues?
Forum Rules | Mark all | Recent Posts

DNS Resolver issues?
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Jan 7, 2006, 7:20 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

I recently installed the DNS Resolver snippet to my MUD and tested it on Cygwin first. I'm getting a bunch of weird errors and crashes. First of all, if I run it normally and try to connect, this happens:
Sat Jan  7 22:13:11 2006 :: InuYasha Galaxy ready at address Zeno on port 1801.
Sat Jan  7 22:13:19 2006 :: [*****] BUG: Auth_check: exception found for (unknow
n)@127.0.0.1.
Sat Jan  7 22:13:20 2006 :: [*****] BUG: Char_to_room: supermob -> NULL room!  P
utting char in limbo (2)
Segmentation fault (core dumped)


Oddly enough, I attached gdb to the MUD process and this:
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4412.0x14ac]
char_to_room (ch=0x100835b0, pRoomIndex=0x0) at handler.c:1104
1104        LINK( ch, pRoomIndex->first_person, pRoomIndex->last_person,
(gdb) bt
#0  char_to_room (ch=0x100835b0, pRoomIndex=0x0) at handler.c:1104
#1  0x004df9d9 in release_supermob () at mud_prog.c:3135
#2  0x004e0c75 in rprog_enter_trigger (ch=0x10378b48) at mud_prog.c:3776
#3  0x0041dba1 in move_char (ch=0x10378b48, pexit=0x102bac38, fall=0,
    running=0 '\0') at act_move.c:1356
#4  0x005275b5 in mobile_update () at update.c:1149
#5  0x0052a626 in update_handler () at update.c:2555
#6  0x004812e8 in game_loop () at comm.c:1259
#7  0x00480397 in main (argc=2, argv=0x61824718) at comm.c:594
(gdb) p ch->name
$1 = 0x102b9898 "Imperial Palace"

So it's a mob... The supermob. Something is very wrong here.
3135      char_to_room( supermob, get_room_index( 3 ) );

So room 3 is missing?

I realize Cygwin is not the best place to test this, but I don't have any other place to test it.
       
Post is unread #2 Jan 7, 2006, 7:35 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

#0 char_to_room (ch=0x100835b0, pRoomIndex=0x0) at handler.c:1104


You're on the right track. Room 3 is missing. One of the dangers of using hardcoded room values. But that's not really the point I guess. Fix that, try again, and see what happens.
       
Post is unread #3 Jan 7, 2006, 7:40 pm
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

Fix what? Not being hardcoded? That really doesn't solve the problem of why room 3 no longer exists after installing this snippet.

I have a feeling somehow it's failing to load areas or something of that matter. The source worked fine before I installed the snippet.
       
Post is unread #4 Jan 7, 2006, 7:59 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

There should be no reason for the DNS code to interfere with area loading. It doesn't affect that at all. Your crash hs nothing to do with bad DNS, it's clearly indicating room 3 does not exist.
       
Post is unread #5 Jan 7, 2006, 8:12 pm   Last edited Jan 7, 2006, 8:28 pm by Zeno
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

Fixed that bug. Another crash again.
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 4820.0x12a4]
0x0041bd86 in will_fall (ch=0x100835b0, fall=0) at act_move.c:493
493         if ( xIS_SET( ch->in_room->room_flags, ROOM_NOFLOOR )
(gdb) bt
#0  0x0041bd86 in will_fall (ch=0x100835b0, fall=0) at act_move.c:493
#1  0x00529102 in char_check () at update.c:1918
#2  0x0052a6c8 in update_handler () at update.c:2579
#3  0x004812e8 in game_loop () at comm.c:1259
#4  0x00480397 in main (argc=2, argv=0x61824718) at comm.c:594
(gdb) list
488     /*
489      * Check to see if a character can fall down, checks for looping   -Thor
ic
490      */
491     bool will_fall( CHAR_DATA *ch, int fall )
492     {
493         if ( xIS_SET( ch->in_room->room_flags, ROOM_NOFLOOR )
494         &&   CAN_GO(ch, DIR_DOWN)
495         && (!IS_AFFECTED( ch, AFF_FLYING )
496         || ( ch->mount && !IS_AFFECTED( ch->mount, AFF_FLYING ) ) ) )
497         {
(gdb) p ch->name
$1 = 0x102b9898 "Imperial Palace"
(gdb) p ch->in_room
$2 = (ROOM_INDEX_DATA *) 0x0

Again, the supermob.

The simple fact is, the MUD is fine without the DNS snippet. With it, rooms seem to no longer exist.

[EDIT] It doesn't seem to let me in the MUD anyways. It connects, but fails to bring up the greeting screen or anything else.
Oh wait... The MUD is running. And it is failing to display anything. Nothing is displayed, but if I enter my name and password, it connects me to the MUD. Considering it's in help.are, it really seems like something went wrong with areas.

Example of playing the MUD:
--- Connected on Saturday, January 07, 2006, 11:25 PM ---
Xio
<the password>


l
astat
rstat

who
prac
eq
i
score
comm
l
quit
--- Disconnected on Saturday, January 07, 2006, 11:27 PM ---


Some commands bleed colors, such as commands will bleed grey. This bleeds into the command I entered which means the MUD is running and I am on it.
       
Post is unread #6 Jan 8, 2006, 12:17 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002


Sat Jan 7, 2006 11:57:29 PM PST :: Initializing main socket

Program received signal SIGSEGV, Segmentation fault.
0x77ea3c00 in RpcRaiseException () from /cygdrive/c/WINDOWS/system32/rpcrt4.dll
(gdb) bt
#0 0x77ea3c00 in RpcRaiseException () from /cygdrive/c/WINDOWS/system32/rpcrt4.dll
#1 0x76f22d78 in DnsWriteReverseNameStringForIpAddress ()
#2 0x00000000 in ?? () from


There appears to be some sort of problem with Cygwin or with the Win32 API it interfaces with. The above gdb crash was caused by AFKMud 1.76a. Fresh compile, simply booting it up. Seems odd there was never a report on this before but it's certainly not doing something right.

http://www.mail-archive.com/cygwin@cygwin.com/msg48157.html

That link points to this being a bit beyond our control.

What version specifically of gcc are you using in Cygwin?
       
Post is unread #7 Jan 8, 2006, 10:17 am   Last edited Jan 8, 2006, 10:58 am by Zeno
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

I'm using version 3.4.4 on Cygwin. Although, I didn't get any crashes with that bt. I'll see if I can test this on *nix.

[EDIT] Tested on:
Linux speedy.alberta 2.6.12-1.1381_FC3 #1 Fri Oct 21 03:46:55 EDT 2005 i686 i686 i386 GNU/Linux


Using gcc version 3.4.4

Same problems. (No displays, etc) So it's not Cygwin.

If you want to see what I'm talking about, connect to:
tcdbbs.zapto.org 4218
       
Post is unread #8 Jan 8, 2006, 12:06 pm   Last edited Jan 8, 2006, 12:06 pm by remcon737
Go to the top of the page
Go to the bottom of the page

Remcon
Geomancer
GroupAdministrators
Posts1,874
JoinedJul 26, 2005

I just tested AFKMud 1.76a and had no problems on it lol. Once I specified the port, using the default of 9050 I couldnt connect to it, but when I did ./startup 4020 (one i normaly use) I had no problems logging in and all.
And so you know it was tested on cygwin
gcc version 3.44 (cygming special) (gdc 0.12, using dmd 0.125)
       
Post is unread #9 Jan 8, 2006, 1:48 pm
Go to the top of the page
Go to the bottom of the page

Conner
Sorcerer
GroupMembers
Posts870
JoinedMay 8, 2005

Very strange behaviour, but I can see what you're talking about Zeno, when I try to connect I get a blank and if I let it wait for the greeting screen it just times out but if I type my username it waits for my password but then when I enter my password it disconnects me immediately without any sort of message or output being displayed at all. :(
       
Post is unread #10 Jan 8, 2006, 2:09 pm   Last edited Jan 8, 2006, 2:23 pm by Zeno
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

I've tested this with noresolve on and off. Either way still has this issue. Although using gdb, I can see that the DNS lookups actually work. It just... doesn't display anything on the MUD. It's still writing to logs.

[EDIT] I've dug deep into this with gdb.
Breakpoint 6, write_to_buffer (d=0x9b30dd0, txt=0x81bebb9 "Password: ", length=0) at comm.c:1997


2002
2003        /*
2004         * Normally a bug... but can happen if loadup is used.
2005         */
2006        if ( !d->outbuf )
2007            return;
2008


(gdb) p d->outbuf
$12 = 0x0


Well now... this may be why it's not sending anything. outbuf is null?

In the snippet:
   Then a few lines below, locate the following:

    CREATE( dnew->outbuf, char, dnew->outsize );

    strcpy( buf, inet_ntoa( sock.sin_addr ) );
    sprintf( log_buf, "Sock.sinaddr:  %s, port %hd.",
		buf, dnew->port );
    log_string_plus( log_buf, LOG_COMM, sysdata.log_level );
    if ( sysdata.NO_NAME_RESOLVING )
      dnew->host = STRALLOC( buf );
    else
    {
       from = gethostbyaddr( (char *) &sock.sin_addr,
	  	sizeof(sock.sin_addr), AF_INET );
       dnew->host = STRALLOC( (char *)( from ? from->h_name : buf) );
    }

   Change it to read as follows:

   strncpy( log_buf, inet_ntoa( sock.sin_addr ), MAX_STRING_LENGTH );
   dnew->host = STRALLOC( log_buf );
   if( !sysdata.NO_NAME_RESOLVING )
   {
      strncpy( buf, in_dns_cache( log_buf ), MAX_STRING_LENGTH );

      if( buf[0] == '\0' )
         resolve_dns( dnew, sock.sin_addr.s_addr );
      else
      {
         STRFREE( dnew->host );
         dnew->host = STRALLOC( buf );
      }
   }


The CREATE line was taken out. It has outbuf in it. This could be the problem. Was that line really suppose to be taken out?
       
Post is unread #11 Jan 8, 2006, 2:28 pm   Last edited Jan 8, 2006, 2:35 pm by Samson
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

Try some poor man's logging in there. In the null check, put a log message in and see if it triggers it. Then you'll know for sure. I have no trouble running this code on Linux but it seems XP doesn't much care for it. Doesn't matter if I run in gdb or out, it crashes. What gets me is I know this worked once before because I did verification testing on AFKMud to be sure you could log on and connect to imc2 and everything. Not sure how far back that was but clearly something has been changed for the worse.

EDIT: And no, the CREATE statement was not supposed to have been taken out. Chalk that up to a big fat oops. However, this does not resolve the issue I had while testing on Cygwin for this thread. AFKMud has the CREATE statement.

EDIT 2: Snippet install instructions fixed. Talk about a huge oversight :P
       
Post is unread #12 Jan 8, 2006, 2:31 pm   Last edited Jan 8, 2006, 2:40 pm by Zeno
Go to the top of the page
Go to the bottom of the page

Zeno
Sorcerer
GroupMembers
Posts723
JoinedMar 5, 2005

Yes. It's totally that part of the code.
Sun Jan  8 17:31:30 2006 :: [*****] BUG: write_to_buffer: NULL d->outbuf!
Sun Jan  8 17:31:34 2006 :: Preloading player data for: Xio (2K)
Sun Jan  8 17:31:34 2006 :: [*****] BUG: write_to_buffer: NULL d->outbuf!
Sun Jan  8 17:31:34 2006 :: [*****] BUG: write_to_buffer: NULL d->outbuf!
Sun Jan  8 17:31:35 2006 :: [*****] BUG: write_to_buffer: NULL d->outbuf!
Sun Jan  8 17:31:35 2006 :: [*****] BUG: write_to_buffer: NULL d->outbuf!
Sun Jan  8 17:31:35 2006 :: [*****] FILE: ../player/x/Xio LINE: 91
Sun Jan  8 17:31:35 2006 :: [*****] BUG: write_to_buffer: NULL d->outbuf!
Sun Jan  8 17:31:35 2006 :: Xio@24.194.240.177 has connected.
Sun Jan  8 17:31:35 2006 :: [*****] BUG: write_to_buffer: NULL d->outbuf!


[EDIT] Yep, adding that missing CREATE line fixed it. I can see text now again, whee. ;)

One problem fixed. Now to find out why my Firefox likes to DDoS websites randomly.
       
Post is unread #13 Jan 8, 2006, 2:37 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

And that would make sense - with the CREATE missing, the code can never *PROPERLY* update it so it sees it as null. All should be well now that it's been fixed. For once it wasn't the code, just the instructions that were bad :)
       
Pages:<< prev 1 next >>