ID:1326123
 
BYOND Version:499
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 27.0.1453.116
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
This is a phantom bug occuring in SS13, during logout, a message is spewed to the log file. This message will at seemingly random times goes to world instead. This is quite uncommon and pretty much impossible to reproduce, but will usually happen multiple times in a row.

There is another version of this, theres a message that prints to all admins during logout, it will also randomly mix up players with eachother (so non-admins get the log message)
You're gonna need more information for this.
That's literally all there is. It probably only affects 1 in 100 logouts.

It doesn't seem to be affecting more than the << operator.
Its not that its a big problem, but it may as well be related to some other slew of bugs considering how odd and random this is
But if you want atleast some people being confused you can look here: https://github.com/tgstation/-tg-station/issues/664
In response to Tobba
Tobba wrote:
Its not that its a big problem, but it may as well be related to some other slew of bugs considering how odd and random this is

Very rarely for my game when outputting text to world, some people won't get the message.
In response to Murrawhip
Murrawhip wrote:
Tobba wrote:
Its not that its a big problem, but it may as well be related to some other slew of bugs considering how odd and random this is

Very rarely for my game when outputting text to world, some people won't get the message.

Same for Eternia, along with other output weirdness-- similar to the problems outlined in Tobba's github link.
The not being outputted thing is entirely the fault of the output() proc, if you use << to output to a default control it'll always display.

output() on the other hand has random instances where it won't output anything to certain clients but output fine to others during the same call. I think it's something to do with lag causing the message to get lost.

I think it's been reported before but I'm not having much luck finding it -- has nothing to do with this report though, so perhaps someone should make a new topic?
In response to Nadrew
I use <<.
Bringing this back from the dead because it seems nobody ever explained this in full.

In ss13, we open a file a world start and assign its reference to a global variable we call dairy.

This is the main log file for shit that happens throughout the round.

A proc we have, called logaccess, logs all mob logins and logouts. it just takes the information, and does

dairy << "ACCESS: LOGIN|LOGOUT [mob.name] [ckey] [ip] [cid]"

or something like that.

Well, randomly, since like ever, this will output to world rather than the file.


I checked, there is no other line that has ACCESS: like that in the entire code base. so its not some legacy code getting called for some reason.

Now, a lot of things log to the diary, but it seems that only the ACCESS one gets set to world, more so its only the logout one suggesting this byond bug is that the pointer or whatever is used internally in file variables is some how being seen as pointing to world shortly when timed right from a client's disconnection.

HEY ITS NOT LIKE 2 YEARS IS A LOT, IM PROBABLY OVERASKING, BUT AN ANSWER WOULD BE COOL
In response to Aranclanos
This is the second time recently that you've shouted to bring up an old bug report. I understand you're frustrated, but my patience with this is thin. You can simply ask if there's been any progress without having to shout. Please use a little courtesy.

I would be happy to investigate this bug if I had something to investigate. As the OP said, this is intermittent and basically impossible to reproduce. No one has provided more than a single line of code to look at. The issue Tobba pointed to at least shows the proc where this happens, but without context: I have no idea what the diary var is or where it's defined, and diving into the source of a recent SS13 build to go searching for it isn't worthwhile. At this point I can't even rule out that it's a bug in the codebase rather than BYOND, because SS13's source is massive.
var/diary
var/list/admins = list() //when mobs login, depending on their ckey, they are added to this list

/world/New()
diary = file("ayylmao.log")

/proc/log_access(text)
diary << "ACCESS: [text]" // this is sent to world randomly

/mob/Logout()
log_access("Logout: [ckey]")
if(admin) //only admins are alerted if another admin logs out
message_admins("Admin logout: [ckey]")

/proc/message_admins(text)
text = "ADMIN LOG: [text]" // this is sent to world randomly
admins << text


This is basically the ss13 code that makes this error happen. You have two cases, the "diary" var that is a file and the admins list.
Its important to point that this only happens inside of the mob Logout() proc.
It only happens on when clients disconnect.

It will instead output to world.

The path to trace this bug is clear, look at how these << pointers work in code, and look at what cases would cause this to point to world.

Most likely, my guess would be this happens when a client disconnects, removing its pointer from the table, at the same time something else modifies the pointer table.

Maybe it may be only when a client then connects at the exact same time.

This most likely relates to the bug report about lines not getting shown to users randomly.

Just go take a look at that code, and the code that modifies the table of whatever it is that << uses when a client disconnects.

Than start asking yourself, what would have to go wrong in this code to make << output to world when it isn't suppose to.


Edit:

as an aside:

Lummox JR wrote:
I have no idea what the diary var is or where it's defined, and diving into the source of a recent SS13 build to go searching for it isn't worthwhile.

Yes, you do, because I explained this in my post months ago:

MrStonedOne wrote:
In ss13, we open a file a world start and assign its reference to a global variable we call dairy.
</<></<></<>
In response to MrStonedOne
Keep in mind my memory is not perfect; if it's not here on this thread or there's no link to it, I don't have a frame of reference. I have no doubt you told me about this a while back, but I need something handy for reference. The code Aranclanos posted is helpful.

I'm not sure the theory about the client list being modified holds water, because concurrency isn't something that happens in DD. Nothing should modify the clients list while another command is running. And even if so, it should be treated as null and skipped over.

The question at hand: Is it at all possible that the diary var is altered anywhere else, at any time? Same for the admins var.

You can also test the var integrity by adding \ref[diary] to the log_access() call. That would help clarify what the var is changing to. Also, does this keep happening once it starts, or is it a one-off thing? I would recommend doing the same check with the admins var, except I'd also add something to look for any var that isn't a user.

The BayStation code I have is a little more complex in all of these procs.
The admins list constantly gets clients removed and added, but it doesn't ever stop being a list or non-clients datums getting added to it.
The diary var never changes.

The code it is a bit more complex, I simplified it because I didn't feel like the rest was important at all. But by all means, check it by yourself to make sure. https://github.com/tgstation/-tg-station by ctrl-f'ing mob/Logout you can follow the rest. Mid-right of the page you have a "download-zip" button.

This doesn't keep happening once it triggers once, but I don't know if it CAN happen again once it does because of the low probability of happening. It seems to be completely random.

In the issue report https://github.com/tgstation/-tg-station/issues/664, there's an image in one of the comments, where it shows the text sent to the admins list but it doesn't show the text sent to the diary, worth to mention.
To add to that, when i first started coding for tgstation13, in an attempt to gain some "street cred" so to speak, I researched this hoping i could bust it.

Nothing modifies diary outside of world/New(). (I even looked for = where a == was suppose to be in ifs and the like).

Nothing else outputs the lines in question.

And this only happens on things that use << in mob/logout (or procs it calls)
Is there anything else you need?
I still have no way to reproduce this, nor any detailed info from when it happens that would provide a clue where to look. (I've looked at the output routines, and nothing there can explain a mix-up) The \ref suggestions I made would be helpful if nothing else.
Page: 1 2