Pronterface locks up while printing, inconsistent line in GCODE, can re-create #405
Description
Summary
After moving my laptop from Ubuntu 12.10 32bit to Ubuntu 13.04 64bit, I am suffering pronterface lockups while printing after a little under an hour of printing. The printer will stop in place, the Pronterface GUI is desaturated by my desktop to indicate it is not responding.
Setup
I am using pronterface from: 80e313d
My printer is a Mendel with Gen7 1.4 electronics using Marlin from: ErikZalm/Marlin@2c0fa34
My laptop is a Lenovo X121e with the i3 dual core with hyper-threading (4 logical cores). 2GB memory. Ubuntu 13.10 64bit
Debug
The lockup is never at the same place in GCODE, one was at line 65375.
Once the lockup occurs it appears to be total and permanent. Once only pronterface is re-strarted and reconnected, my printer responds.
Once locked up the python process's waiting channel is always "futex_wait_queue_me".
I am able to re-create the lockup very quickly by:
- Comment temp set commands in GCODE.
- Use M220 S1000 to accelerate print job in Marlin to 1000%
- Un-power my motors.
- Print.
This moved through the gcode very quickly with "cold extrusion prevented" happening for every E move. It typically produces an identical lockup in under 1 minute, usually now under Line 1000 in GCODE.
With this re-create in place I ran with debug on as suggested in the reprap IRC channel: "!self.p.loud = not self.p.loud". Here's the STDOUT/STDERR: https://gist.github.com/brackendawson/5880949
How about just one CPU? I ran with "taskset 0x00000001 ./pronterface.py" and it seems fine so far. I guess there can be a deadlock on machines with multiple cores. I don't know why what I've done has summoned this issue, could be more to it than a window? But I guess I have my workaround.
If you can't re-create this I'm happy to test and happy to attempt more debug. I'm not a python programmer, I've been trying to get a stack traceback but I don't know how.