Server crash during client logon

A place for people to post strange occurances that could be potential bugs.

Moderator: Board moderators

Post Reply
hc
Newbie
Posts: 2
Joined: Mon Sep 26, 2005 9:17 am

Server crash during client logon

Post by hc »

I just set up a server (1.8.0) running under FreeBSD 5.4. When I terminate the client during the login procedure (shortly after the client connected to the server), the server crashes.

I tried this with server version 1.7.0, it crashed as well.

Is anyone able to reproduce this bug?
Rednaxela
Senior member
Posts: 434
Joined: Wed Jan 26, 2005 5:13 am

Post by Rednaxela »

I haven't heard of anyone else with this issue. It would be helpful if you can get a backtrace of the server by running it through a debugger (i.e. gdb).
If you don't know how to do it and you have gdb installed:

Code: Select all

gdb <path to server>/crossfire
    --You will now be at the gdb prompt--
(at the gdb prompt): run
    --The server will start runing now, so login with the client--
    --When the server crashes, you will return to the gdb prompt--
(at the gdb prompt): bt
    --And then paste the results of that here (or better, on the mailing list where more devs are)--
(at the gdb prompt): quit
Also, you might want to try the cvs version of the server, though parties may be slightly unstable due to recent change which should be fixed now, but there still might be some issues left.
cavesomething
Forum Fanatic
Posts: 852
Joined: Sun Jun 13, 2004 2:07 am
Location: Hemel Hempstead

Post by cavesomething »

A more interesting question might be 'does anyone else run crossfire on FreeBSD 5.4'....

when you say during the login procedure, there are 5 pieces of data to send, name, password, password confirmation, stat confirmation/alteration and race. How far along do you get before quitting, or does it not make any difference?

FWIW I can't reproduce the bug on my GNU/Linux system, this may be because it is OS-specific, or (more probably) that some of the network code has got an unintentional GNU-ism in it (this is not as uncommon as it should be)

If you could provide a backtrace it would be very helpful (either run a debugger on a core file, or run the server through a debugger (such as gdb) and type bt when it crashes)

one other thng to check, if you run the server with debug output on (which you will unless you explicitly turned it off, you should see the following output:

if you connect then exit the client before choosing a name/password

Code: Select all

Waiting for connections...
BUG: process_events(): Object without map or inventory is on active list: mobility (0)
clean_friendly_list: Removed 1 bogus links
CS: connection from client of type < GTK Unix Client 1.8.0>
Get SetupCmd:: map1acmd 1 sound 1 sexp 1 darkness 1 newmapcmd 1 faceset 0 facecache 1 exp64 1 itemcmd 2
SendBack SetupCmd:: setup map1acmd 1 sound 1 sexp FALSE darkness 1 newmapcmd 1 faceset 0 facecache 1 exp64 1 itemcmd 2
Get SetupCmd:: mapsize 17x17
SendBack SetupCmd:: setup mapsize 17x17
Get SetupCmd:: extendedMapInfos 1
SendBack SetupCmd:: setup extendedMapInfos 1
Get SetupCmd:: extendedTextInfos 1
SendBack SetupCmd:: setup extendedTextInfos 1
Get SetupCmd:: faceset 0
SendBack SetupCmd:: setup faceset 0
Trying to load map /home/bren/opt/crossfire-crashtest/share/crossfire/maps/HallOfSelection.
load_original_map: /HallOfSelection (0)
enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1)
PYTHON - triggerEvent:: eventcode 20
LOGOUT: Player named dwarf from ip 127.0.0.1
if you connect then exit the client after choosing a name/password, but before choosing stats.
OR
if you connect then exit the client after choosing stats but before choosing race.

Code: Select all

Waiting for connections...
clean_friendly_list: Removed 1 bogus links
CS: connection from client of type < GTK Unix Client 1.8.0>
Get SetupCmd:: map1acmd 1 sound 1 sexp 1 darkness 1 newmapcmd 1 faceset 0 facecache 1 exp64 1 itemcmd 2
SendBack SetupCmd:: setup map1acmd 1 sound 1 sexp FALSE darkness 1 newmapcmd 1 faceset 0 facecache 1 exp64 1 itemcmd 2
Get SetupCmd:: mapsize 17x17
SendBack SetupCmd:: setup mapsize 17x17
Get SetupCmd:: extendedMapInfos 1
SendBack SetupCmd:: setup extendedMapInfos 1
Get SetupCmd:: extendedTextInfos 1
SendBack SetupCmd:: setup extendedTextInfos 1
Get SetupCmd:: faceset 0
SendBack SetupCmd:: setup faceset 0
enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1)
PYTHON - triggerEvent:: eventcode 20
ReadPacket got an error.: Connection reset by peer
ReadPacket got error 104, returning 0
New socket write failed WTS (32: Broken pipe).
Write_To_Socket called with dead socket
LOGOUT: Player named foo from ip 127.0.0.1
Letting us know which line is the last to appear before the crash would also be helpful.
hc
Newbie
Posts: 2
Joined: Mon Sep 26, 2005 9:17 am

Post by hc »

It happens both before you login and while you define your new character(race, abils, etc).
The server doesn't really crash, or at least it doesn't dump core. It seems to just exit normally (calling exit()). These are
the last messages I get:

Code: Select all

LOGIN: Player named hc from ip 84.182.188.149
make_path_tofile /usr/games/crossfire/var/crossfire/players/hc/hc.pl...
enter_map: supplied coordinates are not within the map! (/HallOfSelection: -1, -1)
ReadPacket got an error.: Connection reset by peer
ReadPacket got error 54, returning 0
Broken pipe
I think the theory about the server relying on the gnu libs is right. I'll try to track down the problem in the code...

Here's the gdb output:

Code: Select all

#0  0x281aa6db in write () from /lib/libc.so.5
#1  0x080d20c2 in Write_To_Socket (ns=0x89b6004, buf=0xbfbf741c "", len=2) at lowlevel.c:369
#2  0x080d21bc in Send_With_Handling (ns=0x89b6004, msg=0xbfbf7520) at lowlevel.c:446
#3  0x080d556f in draw_client_map1 (pl=0x81394d4) at request.c:1726
#4  0x080d6bb6 in draw_client_map (pl=0x81394d4) at request.c:1787
#5  0x080d1a7d in doeric_server () at loop.c:682
#6  0x0806e1c7 in main (argc=14, argv=0x20) at main.c:1231
cavesomething
Forum Fanatic
Posts: 852
Joined: Sun Jun 13, 2004 2:07 am
Location: Hemel Hempstead

Post by cavesomething »

looking at where that backtrace ends, nothing looks obviously wrong (write is conforment to POSIX and 4.3BSD)

The only thing that looks platform dependent is the ifndef __GNU__ block a bit further up, something there doesn't seem to work on Hurd, so it might have problems on other non-Linuxen

on that basis then, one of the first things to try would be to ifdef that out for a BSD system too, since obviously the server can work without that call. (and if it can't then you have found a bug in the Hurd support as well....)

So try something like this as a first guess.

Code: Select all

Index: socket/lowlevel.c
===================================================================
RCS file: /cvsroot/crossfire/crossfire/socket/lowlevel.c,v
retrieving revision 1.11
diff -C5 -r1.11 lowlevel.c
*** socket/lowlevel.c   4 Sep 2005 16:58:13 -0000       1.11
--- socket/lowlevel.c   27 Sep 2005 22:02:14 -0000
***************
*** 347,357 ****
      if (ns->status == Ns_Dead || !buf) {
        LOG(llevDebug,"Write_To_Socket called with dead socket\n");
        return;
      }

! #ifndef __GNU__ /* This caused problems on Hurd */
      if (!ns->can_write) {
        add_to_buffer(ns, buf, len);
        return;
      }
  #endif
--- 347,357 ----
      if (ns->status == Ns_Dead || !buf) {
        LOG(llevDebug,"Write_To_Socket called with dead socket\n");
        return;
      }

! #ifndef __FreeBSD__
      if (!ns->can_write) {
        add_to_buffer(ns, buf, len);
        return;
      }
  #endif
note that I may have the define wrong there, if so, make sure you set it to what it should be
Post Reply