names appear as garbage in "UDP up" messages

NOTE: this is an informal bug post place ONLY. Real bugs should be posted on GitHub
Post Reply
Beardy
Private First Class
Private First Class
Posts: 50
Joined: Tue Nov 22, 2011 2:33 pm

names appear as garbage in "UDP up" messages

Post by Beardy » Sun Feb 26, 2012 9:27 pm

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 ?

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Re: names appear as garbage in "UDP up" messages

Post by JeffM » Sun Feb 26, 2012 10:19 pm

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.
ImageJeffM

Beardy
Private First Class
Private First Class
Posts: 50
Joined: Tue Nov 22, 2011 2:33 pm

Re: names appear as garbage in "UDP up" messages

Post by Beardy » Mon Feb 27, 2012 10:22 am

JeffM wrote:Yeah, looks like the UDP message is sent before the call-sign is set.
Thats what I thought too.
JeffM wrote:The call-sign is inited to an empty string in PlayerInfo so it just won't show in the logs.
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:I have removed the callsign from the log message in the current code.
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.

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.

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Re: names appear as garbage in "UDP up" messages

Post by JeffM » Mon Feb 27, 2012 5:21 pm

The bug list is on sourceforge. https://sourceforge.net/tracker/?group_id=3248
ImageJeffM

Beardy
Private First Class
Private First Class
Posts: 50
Joined: Tue Nov 22, 2011 2:33 pm

Re: names appear as garbage in "UDP up" messages

Post by Beardy » Tue Feb 28, 2012 11:53 am

JeffM wrote:The bug list is on sourceforge.
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 ...


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());
I also did set, in PlayerInfo::PlayerInfo, the first character of the field 'callSign' to the value 33 (exclamation-mark).

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));
to

Code: Select all

nethandler->setPlayer(&player, _playerIndex));
and whatdoyouknow, the callsign got displayed correctly (without the garbage). Problem fixed ?

User avatar
blast
General
General
Posts: 4791
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: names appear as garbage in "UDP up" messages

Post by blast » Tue Feb 28, 2012 12:11 pm

Beardy wrote:
JeffM wrote:The bug list is on sourceforge.
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 ...
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.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

Beardy
Private First Class
Private First Class
Posts: 50
Joined: Tue Nov 22, 2011 2:33 pm

Re: names appear as garbage in "UDP up" messages

Post by Beardy » Tue Feb 28, 2012 1:24 pm

blast wrote:If you didn't file a bug report on our bug tracker, then why would there be a bug report there?
I do hope you are not serious there. You really have no idea ? :(

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 ....
blast wrote:Perhaps I'm missing your point, though.
I think you did, in more ways than one :
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 ...
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 ?

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).

User avatar
Bullet Catcher
Captain
Captain
Posts: 556
Joined: Sat Dec 23, 2006 7:56 am
Location: Escondido, California

Re: names appear as garbage in "UDP up" messages

Post by Bullet Catcher » Tue Feb 28, 2012 4:19 pm

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 ?
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.

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.

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Re: names appear as garbage in "UDP up" messages

Post by JeffM » Tue Feb 28, 2012 5:53 pm

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?
ImageJeffM

User avatar
blast
General
General
Posts: 4791
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Re: names appear as garbage in "UDP up" messages

Post by blast » Tue Feb 28, 2012 6:11 pm

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).
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.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

Beardy
Private First Class
Private First Class
Posts: 50
Joined: Tue Nov 22, 2011 2:33 pm

Re: names appear as garbage in "UDP up" messages

Post by Beardy » Tue Feb 28, 2012 6:41 pm

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,
My apologies if I offended you (or anyone else) by what I said in the above posts.

... 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.
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.
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: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.
So my describing of the negative effects of "do not ensure ..." does not mean anything to you ? Bummer ...

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.
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.
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 SourceForge tracker lists all of the documented bugs,
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:but there may be other bugs that are known.
And what about already fixed bugs not in that list ?

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.
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.
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:As far as I know, no one else was already looking at the GameKeeper inconsistencies you have found.
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 ?

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).
Bullet Catcher wrote:I hope you will continue to explore them and let us know the results.
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.

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.

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5193
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Re: names appear as garbage in "UDP up" messages

Post by JeffM » Tue Feb 28, 2012 6:54 pm

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).
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).

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.
ImageJeffM

Post Reply