"You are not attached to this Computer" Bug

[thebrightspark]

EDIT: Using following versions of mods: OpenModsLib 1.7.10-0.8 OpenPeripheralCore 1.7.10-1.2 OpenPeripheralAddons 1.7.10-0.4 OpenPeripheralIntegration 1.7.10-0.3 ComputerCraft 1.74

This seems to happen randomly, but when it happens, the program I'm trying to run crashes with the following error: "Java Exception Thrown: java.lang.RuntimeException: You are not attached to this Computer"

So far this has happened with two programs I have written. One on a gold turtle, and one on a normal computer. Both use blocks wrapped as peripherals - gold turtle has a vanilla chest and a Blood Magic Blood Altar, and the computer has an EnderIO Fluid Tank.

Here are the respective programs, for your reference: Gold Turtle -> http://pastebin.com/0wm0B5gB Normal Computer -> http://pastebin.com/k8KmTZNL

It's quite annoying as a bug, and happens much more frequently for the turtle program than the computer,

Here's also screenshots of the two computers with the crash shown:

[nevercast]

Always provide version numbers for our mods please :smile:

[Builderb0y]

Getting this issue too, and was able to reproduce it with a single line of code:

while true do peripheral.call("back", "getAllStacks") sleep(0) end

Using a vanilla chest as the peripheral, and opening the chest will usually cause the error.

Using open mods lib version 1.7.10-0.8, and open peripheral version 1.7.10-AIO-5. The versions.txt file says Addons is 1.7.10-0.4-snapshot-216, Core is 1.7.10-1.2-snapshot-247, and Integration is 1.7.10-0.3-snapshot-75.

Also seems to be a multiplayer-only bug, as I can't reproduce it in singleplayer using the same code.

[8BrickDMG]

@nevercast

@thebrightspark is using the following on our server

OpenPeripheralAddons v0.4 OpenPeripheralCore v1.2 OpenPeripheralIntegration v0.3

[thebrightspark]

Sorry, and thanks @8BrickDMG I've updated the original post with the version.

[nevercast]

Thank you. Can you post the error log from the server also?

[Builderb0y]

It doesn't generate any errors in the console, or the fml-server-latest.log file. It only shows the error in the GUI of the computer. The error can be caught with pcall, but that's not always something you can work with because sometimes what happens is that after the error is thrown once, it will happen again every time you try to call a method on the peripheral after that (this is more common when using asynchronous code). When this happens, you can't use the peripheral for ANYTHING after that. Re-wrapping the peripheral doesn't fix it, and neither does using peripheral.call instead of wrap. Breaking and replacing the computer or the peripheral will fix it, but that's not exactly a good solution either, as computers don't continue running where they left off when broken and replaced, and many blocks loose their contents or stored power when broken.

In the case of the chest from earlier, opening and closing the chest again will, oddly enough, un-jam it after it gets into the "constantly erroring" state (despite being the same thing to cause it in the first place). Having an autonomous activator constantly clicking on the chest works too, though I can't confirm this will work for other peripherals as some blocks from other mods don't exactly like being clicked on by fake players.

Also, I was able to reproduce the error in singleplayer by removing the sleep(0) from my line of code from earlier.

[boq]

Something in CC (most probably race condition) causes our sanity check to randomly fail after block updates (block change, redstone signal, etc).

I'm going to report this bug in CC forums. EDIT: done

[boq]

No confirmation yet, but I got hint that may reduce probability of this bug occurrence.

[dtorgy]

I can reproduce this pretty easily using extra utilities solar generator and a computer:

1. place solar generator
2. place computer on top
3. a=peripheral.wrap("bottom") while true do powerLevel=a.getEnergyStored() print(powerLevel) os.sleep(10) end
4. let it run twice :)

[rahangar]

Has anyone found a work-around for this? I'm seeing it too, but with much less frequency... just one computer (out of a dozen or so) that generate this error after AFK'ing for several hours. It is very annoying since the computer is controlling a very complex set of processes.

Is there any way for me to, without crashing, programatically detect (within my program), if the computer is not attached so that I can wrap it again?

[boq]

Are you using snapshot? This should be more or less fixed in yet-to-be-released version.

[rahangar]

Not sure what you mean by snapshot. But if you're asking about the version I'm using, it is as follows:

OpenModsLib-1.7.10-0.8 OpenPeripheral-1.7.10-AIO-5

I can appreciate the fact that it is fixed, but I still would like to know if there is a way of detecting the condition (within my code) so that I can try to re-wrap before I get my hands on the fix.

[boq]

I suggest using pcall.

[thebrightspark]

Just to add though, as others have found before, even using pcall, re-wrapping the peripheral isn't enough to get around the issue. You'd have to break and replace either the computer or the block you have as the peripheral. So I guess you could automate that?

[boq]

What about os.reboot()?

[thebrightspark]

I can't remember... I've not run into this issue for a while. But I remember needing to replace the computer every time, so I don't think it will work. But always worth a try. Unfortunately I am unable to test due to being away from my computer for Christmas.

[rahangar]

I will try checking via this method: http://www.computercraft.info/wiki/Peripheral.isPresent

I'm guessing it should work. Otherwise, I'll look into pcall.

Thanks!

[rahangar]

Well Peripheral.isPresent seems to return true, but the call to getStackInSlot() still results in "You are not attached to this Computer" java exception. This means my wrap instruction never gets called. I'm going to wrap unconditionally in every loop just as a test, to see if wrap prevents it.

[boq]

isPresent checks, if there is any peripheral under given name, not if it's in valid state. I think that pcall is only option. It should be fairly easy to implement - exceptions propagate, so just wrap whole problematic part of code in function and call with pcall.

[rahangar]

Yep; it looks like pcall detects it. But it seems re-wraping doesn't fix it. Once the problem happens, the loop below runs indefinitely.

while not pcall(getInscriberState(inscriber)) do
     print ("pcall returned error")
     sleep(0.25)
     inscriber = peripheral.wrap("front")
end

Any other ideas?

BTW, thanks for your replies; I've learned a lot from this discussion.

[boq]

Ah, that's what you meant by rewrapping.peripheral.wrap is fully Lua side and does nothing with actual peripheral state. I think only os.shutdown has (slight) change to correct it.

[boq]

BTW, you can see how peripheral.wrap works by opening ComputerCraft jar file (as normal zip) and looking into assets\computercraft\lua\rom\apis\peripheral. It's just wrapper over peripheral.getMethods and peripheral.call.

[thebrightspark]

I suggest detect the issue happening using pcall to then trigger the computer to be replaced using external automated means triggered by a redstone signal from the computer, and then have the program start on startup.

[boq]

Bit extreme, isn't it? I plan to release fixed version very soon.

[rahangar]

I've tried replacing the computer manually, but that didn't seem to help... saw the issue even with the new turtle.. I have nearly 200 computers, and a random error like this is a bit cumbersome to deal with. Right now I'm able to reproduce it pretty consistently on one of the turtles. I guess I'll wait for the new release and hope :-). The only thing that seems to make a bit of a difference, is to quit the game and restart the world. In those cases the problem just moves to different computer(s).

[rahangar]

BTW, I've been rebooting the computer and I still see the issue. I'm guessing reboot does an os.shutdown(), so do you still think I should try os.shutdown()?

[thebrightspark]

Yeah I agree it's a bit extreme. And tbh I imagined it for just a single or few cases in a world and this was just a temporary work around that I see would work.

Anyways, if rebooting the computer uses os.shutdown() or at least similar code, then how would just using os.shutdown() be any different?

[rahangar]

Not sure if this help, but the turtle is inputiing to, and outputing from 4 AE inscribers. When the problem happens, the problem consistently happens on that inscriber... until I make a change to the inscriber - as trivial as removing the press and putting it back. Then the problem goes away. I'm not sure if that constitutes the "block update" you indicated before.... but just wanted to pass this information in case it helps.

[rahangar]

Just an update. I did a few mod upgrades today, including upgrade to OpenModsLib-1.7.10-0.9.jar and OpenPeripheral-1.7.10-AIO-6.jar.

For the first time ever I have not seen any computer (from over 75 computers) generate the error. Whatever you did seems to have a positive effect. Hopefully this is not a fluke. :-)

Thanks again!

[g1xb17]

I just got this error again when trying to wrap an ender_chest part of some much larger code. I'm using the AIO-7 and lib 0.9.1

I'm not sure how to debug this so i can figure out what caused it. I don't know if this is super rare, this is the first time it's happened.