trying to make a mod, accidentally crashed my whole computer

[ArderBlackard]

*Any* and I mean *ANY* program you run has the capability to crash your entire computer. There's nothing that can be done about that short of not running any program.

Uhm what? A userspace process should certainly not be able to take down the entire system.

In a perfect world - yes But nothing is perfect. There are bugs in OSes, drivers, services which can be triggered by any program either intentionally or not. One cannot just blindly hope that everything will be OK everywhere right after writing the code without some testing. And during testing all kind of magic can happen

[silverkitty23]

Some Operating Systems handle this better than others, as well. It's hard to get Linux to crash with a bad process (though quite possible - if you fill the partition /tmp is on, or slow it down so hard that you can't get at the console to issue the kill command), but somewhat easier to get Windows to blue screen.

[Divran]

I updated my first post because it was terrible.

[bNarFProfCrazy]

Lets work through the checklist.
Is the bug reproducible on other (people's) systems?
If No, then your system is just somehow broken. Not factorio's fault.
If Yes, then collect the OS and get to the next step.

Which kind of crash is it?
Does the computer stop responding? (Allocating memory takes infinitely long).
Does the computer suddenly reboot/bluescreen? (Please make a screenshot , photo or write down the error message)

If 1) Then well a memory warning would be cool, but since its a very rare case it should simply be ignored, because the other alternative would be crashing Factorio.
If 2) then Factorio is allocating/writing to anothers processes memory, which should not be possible (TM). Unfortunately I don't know how this can be prevented except the default OS protection. Factorio staff should check their code whether they can do anything about it, but otherwise have to ignore it.

[Divran]

I didn't see that this thread was moved to modding help. Please move it back to the bug reports subforum. It belongs there. If you are a moderator, please re-read the first post, because I've rewritten it.

[Rseding91]

I didn't see that this thread was moved to modding help. Please move it back to the bug reports subforum. It belongs there. If you are a moderator, please re-read the first post, because I've rewritten it.

No. We're not going to spend time working on trying to prevent mods from making infinite loops.

[Divran]

I didn't see that this thread was moved to modding help. Please move it back to the bug reports subforum. It belongs there. If you are a moderator, please re-read the first post, because I've rewritten it.

No. We're not going to spend time working on trying to prevent mods from making infinite loops.

This isn't about infinite loops. Infinite loops are only one way that this can happen. This issue will show up again in the future (mark my words) but in a much less obvious form. Minecraft mods have had this issue for as long as there have been mods. The minecraft server will run more slowly over time until it simply dies. It's true that this is the mod author's fault, and all of the mods in minecraft that have this problem have been fixed at one time or another. The point being that minecraft mods can't crash your entire computer, only its own process. Later, when mods in factorio start becoming more complex, it's not impossible that someone will make a similar mistake. Only this time, your whole computer will crash, and not only the process, unlike minecraft.

My opinion is that a process being able to bring down an entire computer is never okay, no matter what caused it (honest mistake or intentional abuse, doesn't matter). The cause is irrelevant. I already mentioned this in the new OP.
Writing efficient code is my responsibility as a modder. Preventing the game from crashing the entire computer is your responsibility as a developer.

My mistake was creating this thread and not putting any effort into the opening post, and if you had read my new OP you would have seen that I have apologized for that.

(By the way, when the mod portal is added, someone could probably make a mod that instantly crashes the computer of anyone who joins, just to be annoying. If the crashed person was, let's say, writing an important essay at the same time, they might be a little upset.)

EDIT: Also, checking the ram usage of the process (at the correct time) won't slow it down at all, and is easy to do.

[FPtje]

No. We're not going to spend time working on trying to prevent mods from making infinite loops.

Your incompetence is preventing you from seeing the underlying issue here, more importantly, you don't seem to understand who's responsible for what. The underlying issue is not Lua developers creating inefficient mods. The underlying issue is the game being so shit at dealing with this that it crashes not only the game, but the entire device.

This is an exploit in the sense that you can use it to crash servers. Servers might not only be running this game, so the incompetence of the developers refusing to fix this will affect other games running on the system. You may try every responsibility absolving argument in your book, but none of them will justify that both ignorant and malicious Lua scripters have such power over the devices that run their scripts.

And to get back to your earlier argument,

There's nothing that can be done about that short of not running any program.

Nothing? Absolutely nothing to solve this issue? Surely if this issue is unsolvable, other games with Lua interpreters would have the exact same issue, which is that Lua scripts can crash the device running the game. Garry's mod is quite a famous game with a Lua interpreter. Since, according to you, nothing can be done to solve this problem, Lua code that fills the memory would crash the device running GMod.

Yet it doesn't. Unlike you, the developers of Garry's mod are competent enough to understand that Lua scripts should not have any power beyond the game, since that's a huge security risk. Any exploits found where Lua scripts do have such powers, are fixed ASAP. As a simple result of this, filling the memory with a Lua script might crash Garry's mod, but NEVER EVER will it crash the entire device.

We're not asking you to solve the damn halting problem here. We're not asking you to make it impossible to make infinite loops. We're asking you to take your damn responsibility to fix a serious exploits that give modders the ability to crash an entire device.

[prg]

Your incompetence is preventing you from seeing the underlying issue here, more importantly, you don't seem to understand who's responsible for what. The underlying issue is not Lua developers creating inefficient mods. The underlying issue is the game being so shit at dealing with this that it crashes not only the game, but the entire device.

Maybe you should fix your operating system if a userspace process requesting memory is able to bring it down completely.

[Divran]

Your incompetence is preventing you from seeing the underlying issue here, more importantly, you don't seem to understand who's responsible for what. The underlying issue is not Lua developers creating inefficient mods. The underlying issue is the game being so shit at dealing with this that it crashes not only the game, but the entire device.

Maybe you should fix your operating system if a userspace process requesting memory is able to bring it down completely.

Well you're not wrong, but it's not like microsoft is going to listen.

[Rseding91]

No. We're not going to spend time working on trying to prevent mods from making infinite loops.

Your incompetence is preventing you from seeing the underlying issue here, more importantly, you don't seem to understand who's responsible for what. The underlying issue is not Lua developers creating inefficient mods. The underlying issue is the game being so shit at dealing with this that it crashes not only the game, but the entire device...

Did you even try to reproduce the issue? It doesn't crash the computer. In fact I'm typing this right now as the process is using 99% of my available RAM for the past 5 minutes and the computer's running just fine.

[ratchetfreak]

No. We're not going to spend time working on trying to prevent mods from making infinite loops.

Your incompetence is preventing you from seeing the underlying issue here, more importantly, you don't seem to understand who's responsible for what. The underlying issue is not Lua developers creating inefficient mods. The underlying issue is the game being so shit at dealing with this that it crashes not only the game, but the entire device...

Did you even try to reproduce the issue? It doesn't crash the computer. In fact I'm typing this right now as the process is using 99% of my available RAM for the past 5 minutes and the computer's running just fine.

Still having a runaway allocation loop is something that that can be tracked (assuming that the lua engine lets you track the allocations) and then if allocation numbers go insane you can abort cleanly without first having to bring the OS to its knees.

[DedlySpyder]

No. We're not going to spend time working on trying to prevent mods from making infinite loops.

Your incompetence is preventing you from seeing the underlying issue here, more importantly, you don't seem to understand who's responsible for what. The underlying issue is not Lua developers creating inefficient mods. The underlying issue is the game being so shit at dealing with this that it crashes not only the game, but the entire device...

Did you even try to reproduce the issue? It doesn't crash the computer. In fact I'm typing this right now as the process is using 99% of my available RAM for the past 5 minutes and the computer's running just fine.

Still having a runaway allocation loop is something that that can be tracked (assuming that the lua engine lets you track the allocations) and then if allocation numbers go insane you can abort cleanly without first having to bring the OS to its knees.

But then the problem becomes that Factorio has to constantly check for this thing. The game starts to chug with large factories, the more checks that the game makes, the smaller you can make a factory.

I'd rather Wube spends their time improving a beautiful game than stopping people from doing something dumb

[Divran]

No. We're not going to spend time working on trying to prevent mods from making infinite loops.

Your incompetence is preventing you from seeing the underlying issue here, more importantly, you don't seem to understand who's responsible for what. The underlying issue is not Lua developers creating inefficient mods. The underlying issue is the game being so shit at dealing with this that it crashes not only the game, but the entire device...

Did you even try to reproduce the issue? It doesn't crash the computer. In fact I'm typing this right now as the process is using 99% of my available RAM for the past 5 minutes and the computer's running just fine.

I wouldn't have posted the thread if my computer hadn't crashed. Are you using linux? Linux probably handles memory better than windows.

But then the problem becomes that Factorio has to constantly check for this thing. The game starts to chug with large factories, the more checks that the game makes, the smaller you can make a factory.

I'd rather Wube spends their time improving a beautiful game than stopping people from doing something dumb

Checking for memory usage takes pretty much no time at all. It would be the difference between having 999 999 999 robots instead of 1 000 000 000 or something

[Rseding91]

I wouldn't have posted the thread if my computer hadn't crashed. Are you using linux? Linux probably handles memory better than windows.

Windows 7 SP1 x64.

[Divran]

Alright guys I just tested this in linux, inside a VM. I deliberately created an infinite loop that placed new values into a table. It seems Factorio already has exactly the thing I've been trying to get you to add. After a few seconds, a popup appeared inside factorio telling me that I didn't have enough memory. The second time I tested it, the factorio process closed (maybe linux closed it automatically) without showing the popup. So it's possible that this check that creates the popup simply doesn't work properly, but the functionality is already there. So, Rseding91, this has now changed from me requesting a new feature, to me requesting you fix a feature that already exists. What do you say about that?

Currently I'm downloading a windows 10 iso to test that in vmware as well.

I wouldn't have posted the thread if my computer hadn't crashed. Are you using linux? Linux probably handles memory better than windows.

Windows 7 SP1 x64.

I'm using windows 10

EDIT: Windows iso is downloaded. Currently installing.

[bNarFProfCrazy]

@Divran

Are you able to reproduce the full computer crash on your system (where you encountered it last time)?

Could you provide a test plugin/mod that reproducible crashes your computer so others can test it as well?
(Please make the mod as light-weight as possible, so there isn't any testing overhead or distraction from the issue you encounter)
I had a broken RAM module once that crashed my computer when I tried to use a fixed but small section of it (usually in high load situations).

[Divran]

@Divran

Are you able to reproduce the full computer crash on your system (where you encountered it last time)?

Could you provide a test plugin/mod that reproducible crashes your computer so others can test it as well?
(Please make the mod as light-weight as possible, so there isn't any testing overhead or distraction from the issue you encounter)
I had a broken RAM module once that crashed my computer when I tried to use a fixed but small section of it (usually in high load situations).

I would prefer to not crash my computer again, which is why I'm installing windows 10 in a VM. It's finished installing now and I'm about to test it.
As you say, it's not entirely impossible that I do have a broken ram module. It would help if someone else could test it as well to be sure. I would be nothing but very happy if I'm proven wrong here and factorio already has the memory checks in place.

EDIT: I managed to get the windows 10 VM to crash. First time I ran the infinite loop, factorio showed the popup, and everything was fine. Then, without restarting factorio, I tried starting a new game. It showed the popup again. After that, I tried to open task manager inside the VM, to see how much memory factorio was using. Windows showed a popup saying that I didn't have enough space in the swap file to open task manager. I tried opening task manager again, and then the screen turned black. The VM had crashed. Kinda weird how that works, but you know, it's windows.
If my ram has an actual physical problem in it, would that not cause my computer to crash even if the VM was using the memory? It didn't crash my computer though, only the VM.

EDIT 2: I should clarify that factorio failed to clear its memory after the popups appeared, which may very well be the cause of the problem. The factorio process eats all of your memory and then keeps it forever, until you manually close factorio. Pretty sure this shouldn't happen.

[bobingabout]

Yeah, I think I've noticed some memory leaks in factorio myself as well.

And even thought a few times.. "Nah, surely factorio must have something in place to prevent memory leaks in the background".

For example... tables.

one of the things in my ores mod is a table for autoplace, the table holds the information required to create a proper autoplace using my functions.

this autoplace table is generated under a local. then once the function is complete... ore.autoplace = autoplace.

what that last instruction does is replace the table in the ore definition table (used to create the entity), with the local. in this case, both ore.autoplace and local autoplace contain a table. when I do ore.autoplace = autoplace, I see that ore.autoplace simply has it's pointer changed to point to the local variable.

Now here is my issue. If it is true that it is POINTING to a local variable, then when the function ends, the local should deconstruct cleanly and not exist anymore, therefore ore.autoplace should point to an invalid object, which isn't the case.

Therefore, you must assume one of 3 scenarios:
1. The instruction doesn't just change the pointer, it clones the entire table in this one instruction and deletes the old one, so when the function ends, the original table is deconstructed cleanly.
2. The instruction does just change the pointer, but the only reason why it doesn't break is because the local table isn't being deconstructed when the function ends.
3. Highly unlikely, but it's possible the game actually tracks which tables are being used by what, so it knows that this specific table is still being used, and isn't collapsed when the function ends, where other tables that might of been created, and the one originally in ore.autoplace that is replaced with the local table created in this fuction are collapsed and deconstructed cleanly.

Now, given that memory leaks are being observed, I'd rule out scenario 3, I mean, a highly unlikely scenario to begin with, I sure as hell wouldn't want to try programming that in if this was my game. This leaves us to either scenario 1 or 2. Given the fact that table.deepcopy exists, a function that appears to explicitly copy a table, my inclination is that scenario 2 is correct, meaning tables are not cleanly destroyed when not used anymore.

I know for a fact that my techsave mod, the one that tracks the progress of a research and restores it when swapping active researches, constantly creates and replaces new tables, this was done because I couldn't figure out a clean way to remove a table entry via it's name (table.remove wants an index number, when all I have is the index name), so instead recreates the entire table minus this entry, then saves that instead. The instances of the recreated tables is actually few (Every time research completes, every time a force is merged, and possibly during version change if researches have been removed from the game), but knowing my mods contribute to memory leakage is disturbing.



Now to put this in context of this discussion. you run an infinite loop that creates an endless table, end the game, but don't exit the game, and start a new game, well, the table still exists from the previous session because it wasn't deconstructed cleanly, and is just leaking memory.

[prg]

Now here is my issue. If it is true that it is POINTING to a local variable, then when the function ends, the local should deconstruct cleanly and not exist anymore, therefore ore.autoplace should point to an invalid object, which isn't the case.

This is not C++. Making a variable local changes where its name is visible, it does not get scheduled for deconstruction when it falls out of scope.

3. Highly unlikely, but it's possible the game actually tracks which tables are being used by what, so it knows that this specific table is still being used, and isn't collapsed when the function ends, where other tables that might of been created, and the one originally in ore.autoplace that is replaced with the local table created in this fuction are collapsed and deconstructed cleanly.

You've just discovered how garbage collectors work.

Now to put this in context of this discussion. you run an infinite loop that creates an endless table, end the game, but don't exit the game, and start a new game, well, the table still exists from the previous session because it wasn't deconstructed cleanly, and is just leaking memory.

Trying to stuff an infinite amount of data into a table is not a memory leak. Also if you've got an infinite loop in your Lua code, you can't exit the game and start a new one anymore because it's just frozen.