Python-light Memory Leak/ Python garbage collector not being called
-
A background python task is resulting in the process VMZ value going up and up, till there's a crash after ~ 30 min.
I'm using spidev and onionGpio libraries to read an SPI device.
Any ideas?
-
Do you have the code to the python task that's running?
Seems to me like there's a memory leak in the code of one of the underlying libraries. Maybe you can figure out exactly the line(s) of python that causes the leak, then we can fix the C library.
-
This is what I'm doing:
import spidev import onionGpio ... def __init__(self): try: self.spi = spidev.SpiDev(32766,1) self.spi.max_speed_hz=100000; self.spi.mode = 1; self.ready = onionGpio.OnionGpio(0,1); r = self.ready.setInputDirection(); ... def _drdy(self): try: while self.ready.getValue()[0] == '1': continue; except: self.ready._freeGpio(); print(traceback.format_exc()); def getReadings(self): self._drdy(); v1 = self.spi.xfer3([self.CMD_WMUX,0x00,self.MUX_AN0_AN1,self.CMD_SYNC,self.CMD_WAKEUP,self.CMD_RDATA],3); self._drdy(); v2 = self.spi.xfer3([self.CMD_WMUX,0x00,self.MUX_AN2_AN3,self.CMD_SYNC,self.CMD_WAKEUP,self.CMD_RDATA],3); self._drdy(); v3 = self.spi.xfer3([self.CMD_WMUX,0x00,self.MUX_AN4_AN5,self.CMD_SYNC,self.CMD_WAKEUP,self.CMD_RDATA],3); self._drdy(); v4 = self.spi.xfer3([self.CMD_WMUX,0x00,self.MUX_AN6_AN7,self.CMD_SYNC,self.CMD_WAKEUP,self.CMD_RDATA],3); return [self._getVal(v1),self._getVal(v2),self._getVal(v3),self._getVal(v4)]; ... #### THE LOOP #### .... while True: try: if not lock: time.sleep(0.005); weights = adc.getReadings(); display_count += 1; if display_count > 20: display_count = 0; client.publish(MQTT_TOPIC,"{\"weight\":%6.2f,\"adc1\":%d,\"adc2\":%d,\"adc3\":%d,\"adc4\":%d}" % (weight,weights[0],weights[1],weights[2],weights[3])); except KeyboardInterrupt: print(stamp()+" :Exiting, interrupt"); sys.exit(1); except: print(traceback.format_exc());
-
https://stackoverflow.com/questions/21524477/python-memory-leak
"So here is what I have found out: the py-spidev module (or some part of spidev itself) seems to be the problem. besides the memory leak, py-spidev is incredibly slow I've now got rid of py-spidev and write to /dev/spidev0.0 directly via file handle. No more excessive memory usage and SPI communication now needs about two seconds, that's about a tenth of the time it needed before." - answered Feb 3 '14 at 20:14 tungl
-
@christian-lacdael Will you be able to follow suit and write to /dev/spidev_ directly? This seems simple enough.
-
I compiled a simple spi C program, as per: http://linux-sunxi.org/SPIdev#In_the_user_space
PID PPID USER STAT VSZ %VSZ %CPU COMMAND 3768 1816 root R 900 1% 65% ./spi
The %VSZ value remains constant.
while (1==1){ buffer=(char *)spi_read(0x10,0x0A,11,file); //reading the address 0x100A for (i =0; i < 11; i++) { printf("%X ",buffer[i]); } }
I am planning to make a daemon C program that stores reads from the SPI device in a /tmp/buffer file. Then I can read the file with Python.