#171 Memory leak in taurustrend

[marc]

EDIT: please note that even if this bug is fixed in Taurus, there is still a possibility of being affected by a mem leak from the underlying Qwt library if one customises the lines of a plot to be thicker than 1pt. See commit 26dd3450

How to reproduce (it can be reproduced both using tango or using eval):

For example launching:
taurustrend 'eval://sin(rand())' -r 10 -b 1000

or launching:
taurustrend sys/tg_test/double_scalar -r 10 -b 1000

and then monitoring the memory of the taurustrend process (use your own pid of the taurustrend process instead of 12000):
ps u -p 12000 | awk '{sum=sum+$6}; END {print sum}'

--

The leak appears after some minutes (from 1 to 10 minutes).

---

To be noted:
Bug appears in suse 11.1 and 12.1 (in 32 and 64 bits).
Bug does NOT appear on suse 13.2

[Carlos Pascual]

Reproduced on a debian 9 using:

taurustrend 'eval://rand()' -r 1 -b 100 &
export TTREND_PID=$!                                     
ps u -p $TTREND_PID | awk '{sum=sum+$6}; END {print sum}'

[Sergi Rubio]

Many thanks for the effort!

Sergi

On 07/01/2015 02:45 PM, Carlos Pascual wrote:

Reproduced on a debian 9 using:

taurustrend 'eval://rand()' -r 1 -b 100 &
export TTREND_PID=$!
ps u -p$TTREND_PID | awk '{sum=sum+$6}; END{print sum}'

---

[tickets:#171] http://sourceforge.net/p/tauruslib/tickets/171
Memory leak in taurustrend

Status: waiting
Milestone: Jul15
Created: Wed Jul 01, 2015 11:04 AM UTC by marc
Last Updated: Wed Jul 01, 2015 11:04 AM UTC
Owner: nobody

How to reproduce (it can be reproduced both using tango or using eval):

For example launching:
taurustrend 'eval://sin(rand())' -r 10 -b 1000

or launching:
taurustrend sys/tg_test/double_scalar -r 10 -b 1000

and then monitoring the memory of the taurustrend process (use your
own pid of the taurustrend process instead of 12000):
ps u -p 12000 | awk '{sum=sum+$6}; END {print sum}'

--

The leak appears after some minutes (from 1 to 10 minutes).

---

To be noted:
Bug appears in suse 11.1 and 12.1 (in 32 and 64 bits).
Bug does NOT appear on suse 13.2

---

Sent from sourceforge.net because
tauruslib-devel@lists.sourceforge.net is subscribed to
https://sourceforge.net/p/tauruslib/tickets/
https://sourceforge.net/p/tauruslib/tickets

To unsubscribe from further messages, a project admin can change
settings at https://sourceforge.net/p/tauruslib/admin/tickets/options.
Or, if this is a mailing list, you can unsubscribe from the mailing list.

---

Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/

---

Tauruslib-devel mailing list
Tauruslib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tauruslib-devel

[Carlos Pascual]

mrosanes reports that the mem leak also apears using TaurusPlot (so we can rule out problems with the trends circular buffers).

I am now trying to reproduce with pure qwtplot

[Carlos Pascual]

It can be reproduced in debian9 and suse11 with:

taurusplot --taurus-polling-period=100  "eval://"{1..50}"*rand()*{sys/tg_test/1/wave}" &
export TTREND_PID=$!
watch -n 1 'ps u -p $TTREND_PID | awk "{sum=sum+\$6}; END {print sum}"'

while the following code using just PyQwt does not yield any leak in the same systems:

from PyQt4 import Qt, Qwt5
import sys
import numpy

def update_data():
    r = numpy.random.rand(NUM_CURVES, NUM_POINTS)
    for i,c in enumerate(curves):
        c.setData(x, r[i,:])
    p.replot()

NUM_CURVES = 20
NUM_POINTS = 1000
PERIOD = 100
app = Qt.QApplication([])

p = Qwt5.QwtPlot()
t = Qt.QTimer()
x = numpy.arange(NUM_POINTS)

curves = [Qwt5.QwtPlotCurve() for i in xrange(NUM_CURVES)]
for c in curves:
    c.attach(p)

Qt.QObject.connect(t, Qt.SIGNAL('timeout()'), update_data)
t.start(PERIOD)

p.show()
sys.exit(app.exec_())

Conclusions: the problem seems to come from TaurusPlot (neither TaurusTrend, nor QwtPlot)

[Carlos Pascual]

Problem located. The memory leak is in the Qwt library. More specifically, in the QwtScaleEngine.transformation() method. It can be reproduced with the following code:

import sys
from PyQt4 import Qt, Qwt5

class MyCurve(Qwt5.QwtPlotCurve):
    def myupdate(self):
        tr = self.plot().axisScaleEngine(self.xAxis()).transformation()

app = Qt.QApplication([])
p = Qwt5.QwtPlot()
curves = [MyCurve() for i in range(50)]
t = Qt.QTimer()
for i,c in enumerate(curves):
    c.attach(p)
    Qt.QObject.connect(t, Qt.SIGNAL('timeout()'), c.myupdate)
t.start(10)
p.show()
sys.exit(app.exec_())

Possible solution:
The problematic call is used in several parts of taurus to get the type of scale. Among them, in each update of the data. I will try to send a patch that puts the transformation type in a cache to avoid calling the leaking method repeteadly.

[Zbigniew Reszela]

Patches proposed by Carlos Pascual were integrated in the develop branch.

[Carlos Pascual]

Please note that, while the main cause of mem leak was the scale issue and that has been fixed, we found another memleak related to thick lines which we can only work around by making the default line width=1, but which will be triggered if you customise the line width to be thicker