Blank Screen
< Newer Topic
:: Older Topic >
#21 Mar 1, 2010 4:20 pm
Off the Edge of the Map
GroupAdministrators
Posts1,200
JoinedMar 21, 2006
I apologize, I shouldn't have brushed this under the rug like that. This is a serious issue, but one I can't seem to replicate at all. I booted a copy of stock SWRFUSS, made 30 characters, that's a lot of tabs in zMud btw, and proceeded to attempt to make this happen.
Something, Somewhere in your code is closing descriptor 0. There's no reason it should be assigning 0 anywhere if it hasn't inadvertently been closed. As has been stated, descriptors 0 and 1 are explicitly used for other things, stdin and stdout. Closing these is a bad idea as has been pointed out.
Something, Somewhere in your code is closing descriptor 0. There's no reason it should be assigning 0 anywhere if it hasn't inadvertently been closed. As has been stated, descriptors 0 and 1 are explicitly used for other things, stdin and stdout. Closing these is a bad idea as has been pointed out.
#22 Mar 1, 2010 4:22 pm
Off the Edge of the Map
GroupAdministrators
Posts1,200
JoinedMar 21, 2006
Banner said:
What steps do you suggest I take? How do you connect to a running process with gdb, where should I place breakpoints, and what should I be looking for?
gdb
Anything that closes a descriptor.
Closing descriptor 0.
#23 Mar 1, 2010 4:24 pm
Magician
GroupMembers
Posts169
JoinedNov 29, 2005
Kayle said:I can hardly get it to replicate when I want to, and I'm also fairly sure it only exists in my codebase but I don't know what causes it so I can't readily admit to that. Where and what would 0 be assigned to and what is it called so that I can check that it's not being closed? I don't think it'd be closed or opened anywhere but in comm.cpp.
I apologize, I shouldn't have brushed this under the rug like that. This is a serious issue, but one I can't seem to replicate at all. I booted a copy of stock SWRFUSS, made 30 characters, that's a lot of tabs in zMud btw, and proceeded to attempt to make this happen.
Something, Somewhere in your code is closing descriptor 0. There's no reason it should be assigning 0 anywhere if it hasn't inadvertently been closed. As has been stated, descriptors 0 and 1 are explicitly used for other things, stdin and stdout. Closing these is a bad idea as has been pointed out.
#24 Mar 1, 2010 6:09 pm
Last edited Mar 1, 2010 6:17 pm by Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005
Player Bob quit.
I followed the paper trail through do_quit, to extract_char, to close_socket, and line 1023 turns out to be:
I noticed that that junk doesn't exist in Smaugfuss, so I'm assuming it's outdated unnecessary code I have that is being set at 0 and then being close errornously. Removing it will be okay, yes?
EDIT: On further inspection, I noticed it is initalized as -1. After hotboot, I don't believe it'd be set, and end up as 0. Then when they quit, the check would tell it to go ahead and close it. Amiright?
EDIT: Verified that was what was happening, and removing auth_fd and auth_inc harmed nothing and fixed everything. Thank you all for the help!
Log: [*****] BUG: close_socket closing desc 0 on 1023 Comm: Bob has quit.
I followed the paper trail through do_quit, to extract_char, to close_socket, and line 1023 turns out to be:
SWGI: } compressEnd( dclose ); if( dclose->descriptor == maxdesc ) --maxdesc; if( dclose->auth_fd != -1 ) close( dclose->auth_fd ); //1023 free_desc( dclose ); --num_descriptors; return; } SMAUGFUSS: } compressEnd( dclose ); if( dclose->descriptor == maxdesc ) --maxdesc; free_desc( dclose ); --num_descriptors; return; }
I noticed that that junk doesn't exist in Smaugfuss, so I'm assuming it's outdated unnecessary code I have that is being set at 0 and then being close errornously. Removing it will be okay, yes?
EDIT: On further inspection, I noticed it is initalized as -1. After hotboot, I don't believe it'd be set, and end up as 0. Then when they quit, the check would tell it to go ahead and close it. Amiright?
EDIT: Verified that was what was happening, and removing auth_fd and auth_inc harmed nothing and fixed everything. Thank you all for the help!
#25 Mar 1, 2010 6:19 pm
Last edited Mar 1, 2010 6:20 pm by Samson
Black Hand
GroupAdministrators
Posts3,697
JoinedJan 1, 2002
Looks like you found something still in your code that's been taken out of the Smaug branch past 1.4a. Somewhere along the way it looks to have been removed from SWRFUSS/SWFOTEFUSS as well, there is no sign of auth_fd in there. I had to go back through my archives and only found auth_id specified in Smaug 1.02a and older.
You should find it in mud.h, remove it there, then compile and remove it from anywhere else the codebase is using it.
You should find it in mud.h, remove it there, then compile and remove it from anywhere else the codebase is using it.
#26 Mar 1, 2010 6:28 pm
Last edited Mar 1, 2010 6:29 pm by Banner
Magician
GroupMembers
Posts169
JoinedNov 29, 2005
Samson said:Yeah, it was being set to -1 in init_descriptor() and being referenced in that ifcheck but that was it. auth_id wasn't being set anywhere. I was about to remove auth_state but that held authorization states for names, and was the only one being used.
Looks like you found something still in your code that's been taken out of the Smaug branch past 1.4a. Somewhere along the way it looks to have been removed from SWRFUSS/SWFOTEFUSS as well, there is no sign of auth_fd in there. I had to go back through my archives and only found auth_id specified in Smaug 1.02a and older.
You should find it in mud.h, remove it there, then compile and remove it from anywhere else the codebase is using it.
I wish little changes like that were posted somewhere so I'd know about these things.
#27 Mar 1, 2010 7:42 pm
Black Hand
GroupAdministrators
Posts3,697
JoinedJan 1, 2002
Since it doesn't show up in Smaug 1.4a, it wouldn't have had reason to be in the changelogs for SmaugFUSS. What I'm not sure about is when it got removed from the SWR side since it's missing from both of the FUSS packages there but still present in the original Smaug 1.02a code they were based on. I don't have untouched copies of the original SWR bases lying around.
#28 Mar 1, 2010 8:12 pm
Magician
GroupMembers
Posts132
JoinedJan 29, 2006
Samson said:
Since it doesn't show up in Smaug 1.4a, it wouldn't have had reason to be in the changelogs for SmaugFUSS. What I'm not sure about is when it got removed from the SWR side since it's missing from both of the FUSS packages there but still present in the original Smaug 1.02a code they were based on. I don't have untouched copies of the original SWR bases lying around.
The ident code is present in original SWR 1.0, but removed in SWR 1.0 FUSS (from Tyche's ftp archive).
#29 Mar 1, 2010 8:28 pm
Black Hand
GroupAdministrators
Posts3,697
JoinedJan 1, 2002
Must have been one of those things taken out in the early days of the project then when we didn't have revision control in place.
#30 Mar 2, 2010 1:41 am
Off the Edge of the Map
GroupAdministrators
Posts1,200
JoinedMar 21, 2006
auth_* was part of the Ident code with the pipe breaking and what not. As far as I know it was one of the first things removed from the FUSS bases. They haven't been present at all since I joined the project as a volunteer, or a maintainer.