MightyPirates / OpenComputers

Home of the OpenComputers mod for Minecraft.
https://oc.cil.li
Other
1.59k stars 430 forks source link

crash too many components connected #1908

Closed Nex4rius closed 6 years ago

Nex4rius commented 8 years ago

I'm sometimes getting this error but if I just restart the computer it works fine for a while (a week or so) before I get this error again. But when I run this to check all connected components. I'm only getting 20 components. And my computer should be able to have 36 attached components. I've already posted this in the Forum a week ago but nobody answered so I assume its not something that I'm doing wrong but instead its a bug in OpenComputers.

I'm experiencing this in the InfiTech 2 modpack v.3.2.9 which has OpenComputers-MC1.7.10-1.5.22.46-universal in it while playing on a server.

xarses commented 8 years ago

shift right click with a scanner tool to see how many components it self identifies with. given you seem to have a large network, my guess is that something is changing state, and when it does it produces more components :looks at stargate:. If you activate any of these do you end up with more components? Also keep in mind, that throwing a tablet in a charger creates a component and the like

Nex4rius commented 8 years ago

This is the shift right click with the analyzer on the computer The analyzer actually sees only 16 components while my programm sees 20 (what happend to those 4 components?).

I don't have a charger connected to my computer which means it cannot add any extra components and an active stargate also doesn't add any components

I also thought that maybe something was adding more components that is the reason I've added the component bus because it should be highly unlikly that something is suddenly adding more than 16 components.

xarses commented 8 years ago

Uh, I don't see a easy way to attempt to reproduce this. please draw a network topology map (check for cable loops [even though that's not supposed to be a problem]) and include a list of mod's providing components, maybe someone can figure something out.

As an aside, you don't have painted cable next to this network that might overload the network? or another server with a similar number of components in the rack?

Nex4rius commented 8 years ago

I'm playing on a server where I have 10+ stargate that all have a computer and my programm (if thats important) running and this crash only happens once a week (to only one of the 10+ computers) so it will be hard to reproduce this reliably.

Here are some screenshots of my setup.

It just happend again to one of the other stargate computers which has a much smaller system without any computronic colorfullamp so they are not responsible for this. You can see the entire computer system in this screenshot.

The only block that is not from OpenComputers is the "OpenComputers Stargate Interface" from SGCraft-1.11.2-mc1.7.10.

xarses commented 8 years ago

Hrm, something is spamming components, I'm still looking at the stargate as the common component here, and knowing nothing about the mod I'm taking a swag as how to trouble shoot here.

Lets hope that components are being iteratively added (and not spammed all at once), assuming so we can log the components after every cycle, and preferably to disk.

Lets start with just a dumb for loop over the component changed event. Then we would need to manually execute every operation combination with the stargate with the controller connected, then since this is an over time issue, lets also forcibly load and unload the chunk. Here we are looking for any change in the components, even if it's just the same count but a UUID changed, it would be relevant to debugging further.

The next step would be running the prior in the background as some kind of event responder with the rc functions, and repeating all of the functions while controlling the SG with the computer.

The final iteration would probably being switching out for a creative server since it has the most number of components and see if you can catch who is spamming the components bus.

As a final desperate measure, someone can modify OC to log the components information when the too many components error is raised and we can troubleshoot further.

Nex4rius commented 8 years ago

I do know that sometimes the UUID of the stargate changes but when that happend only my programm crashed without the too many components error.

Nex4rius commented 8 years ago

I've made this programm that records when components are being added or removed. The programm with the stargate is in the nether and im dialling from the overworld. I did that several times but nothing happend.

The next step would be running the prior in the background as some kind of event responder with the rc functions, and repeating all of the functions while controlling the SG with the computer.

What are the rc functions?

OK I've modified my programm so it will now also write added and removed components into a file. I'm now going to update all computer on the server and lets see what the file contains once I get the next error.

I've tested it again in singleplayer with the programm and this is the result:

It added 4 stargates even though there is only 1 stargate connected to the computer if this is sometimes happening with even more stargates added it could explain the crashes.

edit: also happens on server multiple stargate (I've seen up to 10 so far) are being added and then removed again

fnuecke commented 8 years ago

Sounds like something is wonky in the OC integration of the mod adding the Stargates then.

payonel commented 8 years ago

Actually, I'm seeing something just like this in the BTM world, and with oc-only components. I don't have a good repro, but I have 4 large (multiblock) screens and instead of 4, I often see more than 10 screens when listing components.

I even have a machine right now in the booth with 1 single screen (a 1x1 block, not a multiblock) that is reporting 10 screens. In the image below, the tiny screen off to the left is the only screen connected to the machine.

the setup list of components analyzer

payonel commented 8 years ago

when i rebuilt the multiblock fully (removed ALL blocks) the screen was again just 1 component

maybe this has to do with HOW the multiblocks connect?

that single screen that was acting like 10 screens was originally part of the buggy multiblock

fnuecke commented 8 years ago

It's more of a limitation of the system, since screens can't immediately reconnect into a multiblock after load, there's a bit of a delay. If the computer executes before that...

Will need to look at the screen connecting code again to see if there was a fixed delay or so, in that case bumping the start-after-load-delay should fix this well enough.

Nex4rius commented 8 years ago

I've found this in the configs. It sounds like its made exactly for this kind of problem.

The time in seconds to wait after a computer has been restored before it continues to run. This is meant to allow the world around the computer to settle, avoiding issues such as components in neighboring chunks being removed and then re-connected and other odd things that might happen. startupDelay=0.25

Aedda commented 7 years ago

I've been recently having this bug as well. Always when I am away from the computer. I however am not using stargates and not doing anything fancy with the setup. In a row I have an Assembler, Tier 3 Screen, Tier 3 Case, Charger. A single EIO power conduit comes from the ceiling connected to the Case.

The Case contents are: EEPROM (Lua BIOS) Graphics Card (Tier 3) CPU (Tier 3) 2 x Memory (Tier 3) HDD (Tier 3) OpenOS Floppy in disk slot

The Analyzer reports: Number of connected components: 5/16

After the problem occurs, each time has been while I've been away, the error light flashes on the Case and the Analyzer reports: Last error: Too many components connected to the computer. Number of connected components: 5/16

Using version: OpenComputers-MC1.10.2-1.6.2.7

payonel commented 6 years ago

there is a CHANCE this is fixed with f8bfbf55b153b1efd3e83d06d46d5e0657ad40ef That commit fixed an issue with tesla calling inventory methods too early but, it exposed a race condition we had with component arrays and component limits being undefined when accessed too early. I've added some lazy loading of this data so that the wrong limits and bad arrays are not created before the metadata has been loaded