[CC 1.51/SMP 1.5] Infinite loop xmitting messages can actually crash the minecraft server

This code will break correctly with the usual "too long without yielding" message. Alas, if there is one listener out there in a recieve loop, the server will immediately crash, and will never come back (Well, not for 4 minutes, which is when users started complaining)

Why would you want to transmit junk in an infinite loop? Well, you wouldn't. But I wouldn't want griefers around…


bosschannel = 10001 – updates to boss on this
clientchannel = 1001 – command to clients on this
local event,modemSide,senderChannel
local replyChannel,msg,dist

local modem = peripheral.wrap("top")
modem.open(bosschannel)
modem.open(clientchannel)
while true do
local blob = {}
blob.cmd="move"
blob.data = {0,64,290}
modem.transmit(clientchannel, bosschannel, textutils.serialize(blob))
end

I've tried to reproduce this crash time and time again and I just can't. What are the symptoms of the crash? Do you get an error log? What platform is the server?

Cloudy, on 18 March 2013 - 02:58 PM said:

I've tried to reproduce this crash time and time again and I just can't. What are the symptoms of the crash? Do you get an error log? What platform is the server?

Better yet, how much RAM is the server being provided?

SuicidalSTDz, on 18 March 2013 - 03:02 PM said:

Cloudy, on 18 March 2013 - 02:58 PM said:

I've tried to reproduce this crash time and time again and I just can't. What are the symptoms of the crash? Do you get an error log? What platform is the server?

Better yet, how much RAM is the server being provided?

If you don't have anything to contribute, why post non-content? Cloudy already asked that: "What platform is the server?" That covers all of the hardware/software specifications in one easy question.

Lyqyd, on 18 March 2013 - 03:14 PM said:

If you don't have anything to contribute, why post non-content? Cloudy already asked that: "What platform is the server?" That covers all of the hardware/software specifications in one easy question.

I was specifically asking about the RAM, Cloudy was asking about the entire server platform in general. That could be the operating system, the computer system's coordinating program, the hardware that performs logic operations and manages data movement in the computer, etc. If the server is only being provided 512MB of RAM, that doesn't do anyone justice. I guess what i'm trying to say is that it's more likely a RAM shortage, granted I could have worded my post 'better'.

The ram is unimportant.

Cloudy, on 18 March 2013 - 04:16 PM said:

The ram is unimportant.

If the server cannot keep itself running for more than a second, then it is fairly important. Of course this is not the case. The RAM, now that I think about it, is fairly unimportant in this case. It is of course, still a factor.

Um. Important or not, here are the details:
Ubuntu 12.04.01 (LTS), 64 bit "server" install. The Java process is afforded 2GB of RAM, and minecraft is essentially the only thing running. The server itself has 16GB, of which 14GB are free. Yes, that includes disk caching - this server is *bored*. The CPU is an I7-3820, and, symptomic of minecraft, it is in turbo mode almost all the time (7 cores idle, 1 core auto-overclocked).
This server normally has about 1-6 people online at any given time, and generally doesn't … do… much…
The slave code is:
——————-
– declare our channel from boss
bosschannel = 10001 – updates to boss on this
clientchannel = 1001 – command to clients on this
local event,modemSide,senderChannel
local replyChannel,msg,dist
local modem = peripheral.wrap("right")
modem.open(bosschannel)
modem.open(clientchannel)
while true do
event,modemSide,senderChannel,replyChannel,msg,dist = os.pullEvent("modem_message")
print("ev:" ..event.." side:" ..modemSide.." chan:" ..senderChannel.." rep@:"..replyChannel.." msg:"..msg.." d:"..dist)
end
———————–
Unfortunately, there is no error code in any log. "Crash" in this case, doesn't imply a core dump and sudden java death. "Crash" specifically means:
a) the NANO-SECOND i start the xmit program, I cannot open chests or look at any other turtle or, really, do anything at all. I can move about, but to little avail
B)/> around 10 seconds later (I really haven't timed this) the server boots everyone off, and nobody can reconnect.
c) the server stays this way for a protracted period (like I said, users actually phoned me and complained before I let my patience end)
d) Oddly, the java process drops from using its normal 60% of a single CPU load, to about 2%. Java is still there, but needs to be killed with a SIGKILL (-9) rather than the usual SIGQUIT.
Java is:
java version "1.7.0_15"
Java™ SE Runtime Environment (build 1.7.0_15-b03)
Java HotSpot™ 64-Bit Server VM (build 23.7-b01, mixed mode)
Minecraft is launched on the server with:
java -jar -Xincgc -Xms2G -Xmx2G minecraftforge-universal-1.5-7.7.0.582.jar nogui

Just for clarity's sake, since there was a lot of fuss about this thread: I expect no support whatsoever, and anything above 0% support is extra appreciated. Additionally, I'm your bitch - what else can I do to help?

The only other mods I have are ironchest v "288" and of course, that forgemodloader thingie (v 582) in both client .jar file and server (as a separate .jar file that is launched instead of minecraft to run the server).
P.S. for what it's worth, the sender is a computer, and the receiver is a "naked" turtle.
P.P.S: I should probably also submit that I've crashed the server 3 times in a row doing this, looking for permutations. I have not tried a fourth, which implies I've not managed to make the xmit program NOT crash. Yes, users aren't happy, but science must trump convenience :)/> The interesting thing is as the original post implied, when there's no receiver, the xmit script DOES terminate, with no ill (visible) consequences to the server.
Cloudy: Need access to the server?

Please send a SIGQUIT to the process (kill -3) and pastebin the resulting console log.

Didn't know you could do that.
http://pastebin.com/p1rxsGSa
There's… um…. something you should know.

THIS CRASHES SERVER:
[truncated other code for brevity]
while true do
local blob = {}
blob.cmd="move"
blob.data = {0,64,290}
modem.transmit(clientchannel, bosschannel, textutils.serialize(blob))
end


THIS DOES NOT:
local blob = {}
while true do
blob.cmd="move"
blob.data = {0,64,290}
modem.transmit(clientchannel, bosschannel, textutils.serialize(blob))
end

…Both while the receiver is listening and everything else is equal.

As expected, it is a deadlock. I'll look into fixing it. Can you reproduce it in Singleplayer?

Yes. It's totally reproducible in SMP.
I don't know why, but every time I log into this forum, I can't shake the mental image of a stunned Summer Glau saying "…I swallowed a bug…" in Serenity.

Funny.

I said Singleplayer, not SMP :P/>

I meant single player. The S threw me.
LOOK!! OVER THERE!! AN EAGLE!!
(edwin emphatically points o'er yonder and runs away)
[NO CARRIER]

Would you mind creating a test world which demonstrates this and zipping it up for me?

I PMed you. I … don't want the whole world seeing my tighty whiteys ;)/>

Got the PM, thanks!

For extra info:
in SSP I tried the world I PMed you about on my P7-2770, also with 16GB RAM, but this time in Windows 7. I launch the JVM with:
javaw -Xmx4096m -Xms2048m -jar "C:\users\e\appdata\roaming\.minecraft\minecraft.exe"
I use Java 1.7.0_17-b02 (64 bits) for this, too, in case that's at all relevant.

Out of interest, are you using turtles or computers?

I believe I have found a piece of code that runs fine on computers, but when executed on turtles causes a hang in singleplayer. This is in the FTB pack, CC 1.5, I don't know if anything related to this changed with the update.


Sender:

modem = peripheral.wrap("right")

while true do
  for i = 1, 1000 do
    modem.transmit(1,1,"test")
  end
  sleep(0.01)
end

Receiver:

modem = peripheral.wrap("right")
modem.open(1)

while true do
  e = os.pullEvent()
end

I have been given some code which reproduces it - now to fixing it!

Yay! Labcoat effect be damned.
Abdiel : The transmitter in my case was a computer, and the receiver was a turtle. Having turtles be both still crashes, but I never tried with computers being both.