Interesting! I'll take a look and see what I can find. It's unlikely to make the next release because I'm buttoning that up, but we'll see about the one after that.

The fact that shell() is implicated is a big deal also, as it might shed light on why shell() is a known bad actor on repeated calls.
BS12 does not use shell(), at least not in its current configuration. It has a call in the code, but that code is only hit if the IRC bot needs the Python comms script for messages, which the current bot doesn't (it uses a world.Export() HTTP request instead).

I don't think shell() is the culprit here; it may be related, but I don't think it's causing it.
Something appears to be wrong with that source; a great many of the files are missing.
I didn't actually include the source here, I tried to send you just the files necessary to run because I wanted to decrease the file size to send to you, but I'll repackage everything and send it to you. I'll have to put in on a dropbox account though instead since its too big for puu.sh.

Ginjaninja this isn't a BS12 source though it may resemble one as it is a downstream fork, I guess I cant say for sure how related it may or may not be.
Alright, this should include all parts of the source
https://www.dropbox.com/s/oyeqr93aj5rs8bg/full.rar?dl=0

Also I did a recompile recently, and I tested out this same method and it occurred again. This time with a different replacement.

Runtime in Server will shut down for an automatic update in a few seconds.,11: Safety violation: tried to use shell()
proc name: ext python (/proc/ext_python)
Runtime in Server will shut down for an automatic update in a few seconds.,11: Safety violation: tried to use shell()
proc name: ext python (/proc/ext_python)
Do you have the direct download link for that? Dropbox has been really flaky for me lately and isn't letting me download from that link.
I'm looking up how to create a direct link, can you try this however?
https://www.dropbox.com/s/oyeqr93aj5rs8bg/full.rar?dl=1
which should auto download when you open it.

Edit: this should be the direct download link actually. Works when I log out of my account.
That's downloading.
If that turns out to be too large and I can consistently reproduce it like I did earlier today I may be able to make a much much smaller map that it also appears on for you.
Just as a side note: we see this in the goonstation branch of SS13 a lot too. There hasn't been any rhyme or reason to it thus far but I can say that we don't have any shell() calls.
Something smaller is a much better option, if you can still get the problem to happen. This version has way too large a memory footprint and takes almost literally forever to start up. I've had it starting up for some time now and it still isn't done--to the point where I'm simply giving up on it. That's just not manageable when trying to find a bug.
Okay fantastic news I created an entirely new map thats just 10x10x1 tiles and it starts up instantly and has relatively negligible memory impact and it still triggers the error so I'll upload that in the next 10-15 minutes. Edit: dropbox is slow
There we go, this should actually be debuggable
https://www.dropbox.com/s/v494pzw0zxlo5mj/minimal.rar?dl=1
In response to Clusterfack
Clusterfack wrote:
Ginjaninja this isn't a BS12 source though it may resemble one as it is a downstream fork, I guess I cant say for sure how related it may or may not be.

My "BS12 does not use shell()" was in response to this:

Lummox JR wrote:
The fact that shell() is implicated is a big deal also, as it might shed light on why shell() is a known bad actor on repeated calls.

BS12 gets the same errors occasionally, and we don't use shell().
Ah I see what you mean, well either way it seems to be a fairly reliably way to trigger this.
Oh gads. All that time compiling and it turns out the problem is simply that DD reads the file name ID from the instruction code as 2 bytes when it should be looking for 4. Literally the entire problem was a type cast that got overlooked.
Lummox JR resolved issue with message:
The filename listed in a runtime error was sometimes incorrect in very large projects, using a different string instead.
Hurrah
Now if only I could be so lucky in triggering the appearance replacement bug. I wonder if that is caused by something similar.
Page: 1 2