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?
Server crash during client logon
Moderator: Board moderators
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:
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.
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
-
- Forum Fanatic
- Posts: 852
- Joined: Sun Jun 13, 2004 2:07 am
- Location: Hemel Hempstead
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
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.
Letting us know which line is the last to appear before the crash would also be helpful.
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
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
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:
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:
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
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
-
- Forum Fanatic
- Posts: 852
- Joined: Sun Jun 13, 2004 2:07 am
- Location: Hemel Hempstead
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.
note that I may have the define wrong there, if so, make sure you set it to what it should be
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