names appear as garbage in "UDP up" messages
names appear as garbage in "UDP up" messages
As in the subject actually: on both Windows and Linux I see garbage playernames appear to the messages "inbound UDP up" and "outbound UDP up" (bzflag 2.4.0).
The playername is retrieved with the command "netplayer[id]->info->getCallsign()" (inside the "nethandler.cxx" -> "nethandler::udpReceive" function). I somehow get the feeling that the 'info' part might not be initialized. Alas, that is as far as my current knowledge brings me. I tried to track the place where it goes awry, but could not find it.
Questions:
Is this already known, and if so whats the solution ?
I searched the forum for the problem, but could not find anything. Is there a bug-list available (for 2.4.0) and if so where ?
The playername is retrieved with the command "netplayer[id]->info->getCallsign()" (inside the "nethandler.cxx" -> "nethandler::udpReceive" function). I somehow get the feeling that the 'info' part might not be initialized. Alas, that is as far as my current knowledge brings me. I tried to track the place where it goes awry, but could not find it.
Questions:
Is this already known, and if so whats the solution ?
I searched the forum for the problem, but could not find anything. Is there a bug-list available (for 2.4.0) and if so where ?
Re: names appear as garbage in "UDP up" messages
Yeah, looks like the UDP message is sent before the call-sign is set. It's just a log message so it doesn't affect anything really. The call-sign is inited to an empty string in PlayerInfo so it just won't show in the logs.
The UDP stuff has changed since it was created, it used to be optional but was eventually made mandatory so it was sent sooner in the connection process and that log message just never got changed.
I have removed the callsign from the log message in the current code.
The UDP stuff has changed since it was created, it used to be optional but was eventually made mandatory so it was sent sooner in the connection process and that log message just never got changed.
I have removed the callsign from the log message in the current code.
JeffM
Re: names appear as garbage in "UDP up" messages
Thats what I thought too.JeffM wrote:Yeah, looks like the UDP message is sent before the call-sign is set.
I was looking at that (PlayerInfo) too, but did not see how I could set the callsign in there (too little knowledge in regard to C++ programming I'm afraid). How did you ?JeffM wrote:The call-sign is inited to an empty string in PlayerInfo so it just won't show in the logs.
That was my idea too, until I remembered that the "inbound UDP up" is not under control of the game-Server. Its a response to a message send by the Client, and can appear much later on. In such a case displaying the callsign is not a bad idea.JeffM wrote:I have removed the callsign from the log message in the current code.
One question remains though: Is there a bug-list available, and if so where ? As I'm currently able to recompile the whole thing I can as well incoorporate a few fixes for already-known problems ...
Edit
I'm not sure if I did it right, but I added the line 'setCallSign("<ghost>");' as a test to the 'GameKeeper::Player::Player' functions. Now I see that name plus garbage infront of it ... The garbage (most always four chars) seems to be part of the callsign (used "[%s]" to test).
In short: to me it looks like its an string-offset problem, not one of the callsign not being initialized.
Edit-edit
Just thought of replacing the "getCallSign()" call with the "getMotto()" call. That one did what its supposed to to: return a blank string. Wierd ...
Edit #3
Scratch the above, I initialized the motto with a string, and got nothing back.
Re: names appear as garbage in "UDP up" messages
The bug list is on sourceforge. https://sourceforge.net/tracker/?group_id=3248
JeffM
Re: names appear as garbage in "UDP up" messages
Alas, its not quite complete I'm afraid. I've reported a bug (http://forums.bzflag.org/viewtopic.php?f=32&t=17544) and read that it was fixed, but its not mentioned anywhere there. I can imagine that other bug-fixes have gone the same way ...JeffM wrote:The bug list is on sourceforge.
But back to the "garbage callsign" problem. I've done a few more tests and get results that I can't quite interpret. In the second GameKeeper::player::player procedure I've added some debug-messages printing a few values:
Code: Select all
logDebugMessage(0,"(%X) (%X) [%S]", this, ((PlayerInfo*)this)->getCallSign(), ((PlayerInfo*)this)->getCallSign());
logDebugMessage(0,"(%X) (%X) [%S]", &player, player->getCallSign(), player->getCallSign());
The results where :
(8589460) (858947C) [t() !]
(8589464) (8589480) [!]
As you can see the GameKeeper::Player and player classes seem to overlap with a offset of 4 bytes, and that can't be right.
I've currently got no idea how to proceede from here, but I get the feeling it could be connected to the 'nethandler->setPlayer(...)' line, where "this" is stored as PlayerInfo. If "this" is of the PlayerInfo class, than what is "player" ? They do not seem to be the same ...
P.s.
I've remarked-out (removed) the first GameKeeper::player::player procedure without getting any errors on compile. Maybe its superfluous ?
Edit
What the heck, whats the worst thing that can happen when I just change the code to what I think it should be ? A crashing 'puter ...
So, I canged the above-mentioned line from
Code: Select all
nethandler->setPlayer((PlayerInfo*)this, _playerIndex));
Code: Select all
nethandler->setPlayer(&player, _playerIndex));
Re: names appear as garbage in "UDP up" messages
If you didn't file a bug report on our bug tracker, then why would there be a bug report there? They don't appear just because you tell someone that there's a bug. Perhaps I'm missing your point, though.Beardy wrote:Alas, its not quite complete I'm afraid. I've reported a bug (http://forums.bzflag.org/viewtopic.php?f=32&t=17544) and read that it was fixed, but its not mentioned anywhere there. I can imagine that other bug-fixes have gone the same way ...JeffM wrote:The bug list is on sourceforge.
Re: names appear as garbage in "UDP up" messages
I do hope you are not serious there. You really have no idea ?blast wrote:If you didn't file a bug report on our bug tracker, then why would there be a bug report there?
What about: The person who added the bugfix put it in there. You know, just to keep that bugfixes list consistent -- so that already fixed bugs would not be posted again (and re-fixed, wasting somebodies time).
Ugh... I can't believe I needed to explain that ...
But that means that there is no full list of solved (in 2.4.0) bugs available ? What a mess ....
I think you did, in more ways than one :blast wrote:Perhaps I'm missing your point, though.
You pointed me to that sourceforge list even though it contains next to nothing ... How is that list supposed to be usefull for what I requested it for ?Beardy wrote:One question remains though: Is there a bug-list available, and if so where ? As I'm currently able to recompile the whole thing I can as well incoorporate a few fixes for already-known problems ...
Edit
I did just find an interresting one on sourceforge : OFFA does not have observer teamchat.
Alas, the only thing thats mentioned there is that "r22139 fixes it". No link to whatever that "r22139" might be, nor any indication to the location of, what the problem was, or what the solution is. Not really usefull (understatement).
- Bullet Catcher
- Captain
- Posts: 564
- Joined: Sat Dec 23, 2006 7:56 am
- Location: Escondido, California
Re: names appear as garbage in "UDP up" messages
Beardy, you have expressed several expectations for the BZFlag project that have not been met. Yes, in 19 years of development we failed to anticipate your specific needs, but your difficulty in accepting that simple unchangeable truth seems to be a major obstacle to the contributions you seem willing to provide.Beardy wrote:that means that there is no full list of solved (in 2.4.0) bugs available ? What a mess ....
... How is that list supposed to be usefull for what I requested it for ?
The BZFlag developers do not ensure that there is a bug report for every change they make, and whining about it won't make it happen. The closest thing there is to what you asked for is the Subversion revision history hosted at SourceForge. Going forward from http://bzflag.svn.sourceforge.net/viewv ... sion=22054 is the complete set of changes since 2.4.0 was released.
The best way to ensure that you are not chasing solved problems is to work with the latest Subversion revision (currently 22385) of the software. The SourceForge tracker lists all of the documented bugs, but there may be other bugs that are known. Again, the fact that someone may be aware of a bug but has not added it to the tracker is something that you'll have to learn to deal with.
As far as I know, no one else was already looking at the GameKeeper inconsistencies you have found. I hope you will continue to explore them and let us know the results.
Re: names appear as garbage in "UDP up" messages
Yes, I did not post a bug report for the change for the callsigns in the log message, All I did was add a commit comment. This is how this project works. I'm sorry if it is not how you would run your own project. We build a changelog from the the SVN comments before each release. Perhaps you should not assume so much about how other people do things and accept that they are different from how you would do it. If you are unable to do that then these will not be productive conversations.
In my testing I did not find any examples of garbage callsigns I simply saw that it was not set. The string is set to all nulls when the player is created so calling printf on it should not be a problem as it will return a pointer to null and not print anything. My fix was to simply remove the item from the log. It is of little use anyway, at that low level the developer will care more about the slot number.
I do not understand what you are saying about the GameKeeper::Player and it's PlayerInfo object. I do not do much assembly and do not get your notation. If you are asking why the PlayerInfo object is 4 bytes ahead of the start of the Player object, then that is because the PlayerInfo object is contained in the Player object and is the second member in the class, so yes it will be offset by that amount. This is just how C++ compiles things. I do not see any problem with how it is defined.
What exact problem are you trying to track down? or is this all just things you see and are confused about as you poke around the code randomly?
In my testing I did not find any examples of garbage callsigns I simply saw that it was not set. The string is set to all nulls when the player is created so calling printf on it should not be a problem as it will return a pointer to null and not print anything. My fix was to simply remove the item from the log. It is of little use anyway, at that low level the developer will care more about the slot number.
I do not understand what you are saying about the GameKeeper::Player and it's PlayerInfo object. I do not do much assembly and do not get your notation. If you are asking why the PlayerInfo object is 4 bytes ahead of the start of the Player object, then that is because the PlayerInfo object is contained in the Player object and is the second member in the class, so yes it will be offset by that amount. This is just how C++ compiles things. I do not see any problem with how it is defined.
What exact problem are you trying to track down? or is this all just things you see and are confused about as you poke around the code randomly?
JeffM
Re: names appear as garbage in "UDP up" messages
We use a VCS, specifically SVN, so r22139 refers to revision 22139. This is standard notation to refer to revisions in SVN, and possibly CVS (I forget how CVS works). A DVCS like git or mercurial would use a hash to indicate a specific changeset.Beardy wrote:I did just find an interresting one on sourceforge : OFFA does not have observer teamchat.
Alas, the only thing thats mentioned there is that "r22139 fixes it". No link to whatever that "r22139" might be, nor any indication to the location of, what the problem was, or what the solution is. Not really usefull (understatement).
Re: names appear as garbage in "UDP up" messages
My apologies if I offended you (or anyone else) by what I said in the above posts.Bullet Catcher wrote:Beardy, you have expressed several expectations for the BZFlag project that have not been met. Yes, in 19 years of development we failed to anticipate your specific needs,
... The problem is that, as far as I can tell, I asked a simple question, for which the reply didn't hold an answer to it. Not funny.
And that "unchangable truth" might be ... what exactly ? The failure of the bug-report system as sourceforge to provide usable info ? Thats not much of an "unchangable truth", if I may take the development of products like it over the years as an example.Bullet Catcher wrote:but your difficulty in accepting that simple unchangeable truth seems to be a major obstacle to the contributions you seem willing to provide.
So my describing of the negative effects of "do not ensure ..." does not mean anything to you ? Bummer ...Bullet Catcher wrote:The BZFlag developers do not ensure that there is a bug report for every change they make, and whining about it won't make it happen.
But thank you for that link. At least now I have something actually to look at. One remark though : Would it be an idea to let the bug-tracker list directly link to such a page ? Or at least mention how to get to them ? Novices like me would definatily benefit from it.
And that latest version is "just" 2.4.0" with bug-fixes, or is it actually 2.4.x , which would make me a part of the "just update it for the very-best performance" circus ? I would really hate that you know.Bullet Catcher wrote:The best way to ensure that you are not chasing solved problems is to work with the latest Subversion revision (currently 22385) of the software.
Very funny: documented means that they must be in that tracker-list, which makes it a self-fulfilling prophecy. Or is there another list ?Bullet Catcher wrote:The SourceForge tracker lists all of the documented bugs,
And what about already fixed bugs not in that list ?Bullet Catcher wrote:but there may be other bugs that are known.
Read this thread again. I've posted a link to another one in which War Pig wrote down a bug I found and it solution. A few posts down its said the fix is incoorporated in the tree. In other words: It is fixed, but not mentioned in that tracker-list.
That was not the problem. The problem was the above : a fixed problem with no paperwork attached to it. It makes it easy to suspect that more have gone the same way. And that makes the tracker-list next to worthless for someone like me.Bullet Catcher wrote:Again, the fact that someone may be aware of a bug but has not added it to the tracker is something that you'll have to learn to deal with.
My apologies if this seems blunt, but how would you know ? bug-fixes to the tree do apparently not have to be mentioned in that tracker-list. Do you maybe have another method/list ?Bullet Catcher wrote:As far as I know, no one else was already looking at the GameKeeper inconsistencies you have found.
Not being able to check which changes have been made to the sourcecode is what I would call "a mess".
Also, JeffM was aware of the effects of the problem. He just did choose not to post it. He however did solve it in his own way (by removing the visible effects rather than the root cause).
The post you replied to has it in full. A change of one argument in one line of the code. See the "edit" at the bottom.Bullet Catcher wrote:I hope you will continue to explore them and let us know the results.
Mind you, I do not know if its the correct solution (have only started programming & compiling this OO C++ (or whatever its called) language a few weeks ago), so do me a favour and check it out before eventually comitting it.
Re: names appear as garbage in "UDP up" messages
Please do not put words in my mouth, specially when you do not seem to know what you are talking about (by your own admission).Beardy wrote: Also, JeffM was aware of the effects of the problem. He just did choose not to post it. He however did solve it in his own way (by removing the visible effects rather than the root cause).
I tested what you described and did NOT see any problem, just an empty string, not garbage. The change I made was simply because an empty string is pointless in that case. This was not a bug, but an undesired feature (the output of an empty string for a callsign). As I have stated several times the string is initialized to null. That was all I could see based on your poor explanation. The change simply removed a function that was not doing anything, it does not hide any root cause.
If you are finding memory corruption then please post a test case for how I can duplicate it with the current SVN code, if you would like to also post a SF bug for it that would help as well. Please provide as much information as you can.
If you are unable or unwilling to do that then this is just wasting all our time.
JeffM