Re: [PyQt] memory leak on a Mac

2011-01-28 Thread Danny Shevitz 

 I don't have those problems. How did you install PyQt? I use MacPorts (using
Python 2.7). 

Arne,

thanks for the MacPorts tip. I have installed pyqt through MacPorts and it works
just fine. No memory leak anymore. After figuring out how to get through our
firewall and making the MacPorts python the current python, it worked great.

D

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] memory leak on a Mac

2011-01-27 Thread Danny Shevitz 
Howdy,

I have an app that works just fine on the one click windows distro. 

I just tried to run the same app on a Mac for the first time. I am nobody's
Mac expert, but I did manage to get the latest PyQt4, Sip, QScintilla working.

When I run my app on the Mac, I get the following:

macshev:elm3 shev$ python elm3.py
2011-01-27 09:02:06.705 Python[16663:613] *** _NSAutoreleaseNoPool(): Object
0xae0e30 of class NSCFNumber autoreleased with no pool in place - just leaking
Stack: (0x97805f4f 0x97712432 0x97714c3a 0x22c36b7 0x232ecca 0x232f126 0x1e60363
0x1e65287 0x1023d6 0x4f49a6 0x497caa 0x53a916 0x53da4b 0x53eb8b 0x53ed42
0x562c4b 0x563a53 0x574248)

The app still runs, but evidently I am leaking memory. My app is pure PyQt, no
C is involved. I can't even begin to guess how to diagnose this problem.
Does anyone have any ideas? 

MacOs 10.5.8
Python 2.6.2
sip 4.12.1
PyQt 4.8.3
QScintilla 2.4.6

thanks,
Danny


___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] memory leak on a Mac

2011-01-27 Thread Arne Schmitz 
Am 27.01.2011 um 18:12 schrieb Danny Shevitz:

 Any PyQt application generates the same message. If I run something from the
 samples directory, I get the same memory leak, so it is nothing in my code.


I don't have those problems. How did you install PyQt? I use MacPorts (using 
Python 2.7). 

Regards,

Arne

-- 
Dipl.-Inform. Arne Schmitz  Phone   +49 (0)241 80-21817
Computer Graphics Group Mobile  +49 (0)151 29145947
RWTH Aachen University  Fax +49 (0)241 80-22899
Ahornstrasse 55, 52074 Aachen, Germany  http://www.rwth-graphics.de

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] memory leak on a Mac

2011-01-27 Thread Danny Shevitz 
Arne Schmitz arne.schmitz at gmx.net writes:

 
 Am 27.01.2011 um 18:12 schrieb Danny Shevitz:
 
  Any PyQt application generates the same message. If I run something from the
  samples directory, I get the same memory leak, so it is nothing in my code.
 
 I don't have those problems. How did you install PyQt? I use MacPorts (using
Python 2.7). 
 
 Regards,
 
 Arne
 
I got the gzipped tarball, unpacked it. cd'ed to the directory. Then I 
ran:
python configure.py
make
make install.

I had to do this for sip as well.

D




___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] memory leak using QMainWindow.removeToolBar

2010-08-17 Thread Phil Thompson 
On Mon, 16 Aug 2010 22:59:22 + (UTC), danny shev...@lanl.gov wrote:
 thanks,
 
 your solution works, and stops my code from seg faulting. I'm curious
 why mine doesn't work. In the documentation for QMainWindow
 

http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qmainwindow.html#addToolBar-3
 
 The third overloading of the addToolBar method, was what I was using.
 
 It should be equivalent, but I must be missing something.

There does seem to be a bug. Even though addToolBar() takes ownership of
the toolbar, removeToolBar() doesn't change the current ownership.

It will be fixed in tonight's snapshot. The consequence is that you have
to do extra work to really delete a removed toolbar, ie. reparent it to
None.

Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] memory leak using QMainWindow.removeToolBar

2010-08-16 Thread danny 
Howdy,

I have run into this curious problem that I think is caused by a memory leak
or improper reference counting related to toolbars in 
QMainWindow.removeToolBar. 
The problem appears when you remove a toolbar but keep an instance variable
maintaining a reference to the toolbar. I am aware that removeToolBar only
hides the toolbar and does not delete it. I also am aware that the following
code may seem foolish, but it does show the bug. The code below is a minimal
example demonstrating the problem. It is 34 lines long. Simply run the app, and
close via the close box. The app will not close gracefully, but rather seg 
fault.
This has been validated on windows and Linux.  I don't believe the following
code is doing anything stupid enough to justify a seg fault. The problem
disappears is you remove the instance reference to the toolbar 
(self.editToolBar = editToolBar). Notice that the code is intended to reside
within an SDI framework app like Mark Summerfield uses in his excellent PyQT
book. The instances variables probably keep additional references around that
are part of the problem. Explicitly removing the attribute, gets rid of the 
problem.

Included below is the source code. Please let me know if this is a bug or
my own stupidity.

I am running python 2.5.1, pyqt 4.7.3

thanks,

Danny

#%
import sys
from PyQt4 import QtGui,  QtCore,  QtSql

def isAlive(qobj):
import sip
try:
sip.unwrapinstance(qobj)
except RuntimeError:
return False
return True

class MyApp(QtGui.QMainWindow):
NextId = 1
Instances = set()

def __init__(self, parent=None):
super(MyApp, self).__init__(parent)
self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
MyApp.Instances.add(self)
self.editToolBar = self.addToolBar(Edit)
self.removeToolBar(self.editToolBar)
# delattr(self,  'editToolBar') # this gets rid of the seg fault
self.destroyed.connect(MyApp.updateInstances)
self.setCentralWidget(QtGui.QWidget()) 

@staticmethod
def updateInstances(qobj):
MyApp.Instances = set([window for window \
in MyApp.Instances if isAlive(window)])

if __name__=='__main__':
application = QtGui.QApplication(sys.argv)
MyApp().show()
application.exec_()


___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] memory leak using QMainWindow.removeToolBar

2010-08-16 Thread Baz Walter 

On 16/08/10 18:27, danny wrote:

Howdy,

I have run into this curious problem that I think is caused by a memory leak
or improper reference counting related to toolbars in QMainWindow.removeToolBar.
The problem appears when you remove a toolbar but keep an instance variable
maintaining a reference to the toolbar. I am aware that removeToolBar only
hides the toolbar and does not delete it. I also am aware that the following
code may seem foolish, but it does show the bug. The code below is a minimal
example demonstrating the problem. It is 34 lines long. Simply run the app, and
close via the close box. The app will not close gracefully, but rather seg 
fault.
This has been validated on windows and Linux.  I don't believe the following
code is doing anything stupid enough to justify a seg fault. The problem
disappears is you remove the instance reference to the toolbar
(self.editToolBar = editToolBar). Notice that the code is intended to reside
within an SDI framework app like Mark Summerfield uses in his excellent PyQT
book. The instances variables probably keep additional references around that
are part of the problem. Explicitly removing the attribute, gets rid of the
problem.

Included below is the source code. Please let me know if this is a bug or
my own stupidity.

I am running python 2.5.1, pyqt 4.7.3

thanks,

Danny

#%
import sys
from PyQt4 import QtGui,  QtCore,  QtSql

def isAlive(qobj):
 import sip
 try:
 sip.unwrapinstance(qobj)
 except RuntimeError:
 return False
 return True

class MyApp(QtGui.QMainWindow):
 NextId = 1
 Instances = set()

 def __init__(self, parent=None):
 super(MyApp, self).__init__(parent)
 self.setAttribute(QtCore.Qt.WA_DeleteOnClose)
 MyApp.Instances.add(self)
 self.editToolBar = self.addToolBar(Edit)
 self.removeToolBar(self.editToolBar)
 # delattr(self,  'editToolBar') # this gets rid of the seg fault
 self.destroyed.connect(MyApp.updateInstances)
 self.setCentralWidget(QtGui.QWidget())

 @staticmethod
 def updateInstances(qobj):
 MyApp.Instances = set([window for window \
 in MyApp.Instances if isAlive(window)])

if __name__=='__main__':
 application = QtGui.QApplication(sys.argv)
 MyApp().show()
 application.exec_()


i don't think it is a bug. the real problem is with how the toolbar is 
being created, not with how it's being destroyed.


try something like this:

import sys
from PyQt4 import QtGui,  QtCore

class MainWindow(QtGui.QMainWindow):
def __init__(self, parent=None):
QtGui.QMainWindow.__init__(self, parent)
self._toolbar = QtGui.QToolBar('Edit', self)
self.addToolBar(self._toolbar)
self.removeToolBar(self._toolbar)

if __name__=='__main__':
app = QtGui.QApplication(sys.argv)
win = MainWindow()
win.show()
sys.exit(app.exec_())

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] memory leak using QMainWindow.removeToolBar

2010-08-16 Thread danny 
thanks,

your solution works, and stops my code from seg faulting. I'm curious
why mine doesn't work. In the documentation for QMainWindow

http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qmainwindow.html#addToolBar-3

The third overloading of the addToolBar method, was what I was using.

It should be equivalent, but I must be missing something.

thanks,
D

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak

2008-07-06 Thread Giovanni Bajo 
On Sat, 2008-07-05 at 23:04 +0100, Phil Thompson wrote:
 On Thu, 03 Jul 2008 16:04:42 +0200, Giovanni Bajo [EMAIL PROTECTED]
 wrote:
  Hi Phil,
  
  with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0:
  
  
  import sip
  import weakref
  from PyQt4.Qt import *
  
  class MyWidget(QWidget):
   def sizeHint(self):
   return QSize(900, 700)
  
  app = QApplication([])
  
  ws = MyWidget(None)
  wr = weakref.ref(ws)
  
  L = QVBoxLayout(None)
  L.addWidget(ws)
  L.activate()
  del L
  del ws
  
  import gc
  gc.collect()
  
  assert wr() is None
  
  
  The assert triggers, meaning that the object of type MyWidget is not 
  released.
 
 This appears to be a Qt problem. Although the docs say that a layout takes
 ownership of the widget when addWidget() is called it leaves the
 destruction of the widget to the eventual owner of the layout and doesn't
 call the widget's dtor itself.
 
 If the layout is never used (ie. never passed as an argument to
 QWidget.setLayout()) then all the widgets in the layout will leak.
 
 An equivalent C++ version behaves in the same way.
 
 I could change addWidget() so that the layout doesn't take ownership of the
 widget (ie. to match the implementation rather than the documentation) but
 that will break any code that creates a populated layout and returns it
 from a function.

I believe that it's more correct if you fix this code not to have any
memory leak. Either that, or you get smarter wrt when the ownership is
transferred from Python to C++ (that is, when the layout is reparented
to a widget, if ever). And in any case, you should probably raise this
issue with Trolltech (it's at least a documentation issue, I'd say).

Anyway, it turns out that I had reduced the testcase a little too much:
it was not the actual memory leak I was seeing in my application.

The correct testcase is this one:


#!/usr/bin/env python
import sip
import weakref
from PyQt4.Qt import *

class MyWidget(QWidget):
   def sizeHint(self):
   return QSize(900, 700)

app = QApplication([])

ww = QWidget(None)
ws = MyWidget(None)
wr = weakref.ref(ws)

L = QVBoxLayout(ww)
L.addWidget(ws)
L.activate()
del L
del ws
del ww

import gc
gc.collect()

assert wr() is None


This memory leak is related to the sizeHint() method (if you comment it,
there's no leak anymore) and to the fact that it is actually called at
least once (if you comment the .activate() call, there's no leak
anymore).
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com


___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak

2008-07-06 Thread Phil Thompson 
On Sun, 06 Jul 2008 15:18:10 +0200, Giovanni Bajo [EMAIL PROTECTED]
wrote:
 On Sat, 2008-07-05 at 23:04 +0100, Phil Thompson wrote:
 On Thu, 03 Jul 2008 16:04:42 +0200, Giovanni Bajo [EMAIL PROTECTED]
 wrote:
  Hi Phil,
  
  with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0:
  
  
  import sip
  import weakref
  from PyQt4.Qt import *
  
  class MyWidget(QWidget):
   def sizeHint(self):
   return QSize(900, 700)
  
  app = QApplication([])
  
  ws = MyWidget(None)
  wr = weakref.ref(ws)
  
  L = QVBoxLayout(None)
  L.addWidget(ws)
  L.activate()
  del L
  del ws
  
  import gc
  gc.collect()
  
  assert wr() is None
  
  
  The assert triggers, meaning that the object of type MyWidget is not 
  released.
 
 This appears to be a Qt problem. Although the docs say that a layout
 takes
 ownership of the widget when addWidget() is called it leaves the
 destruction of the widget to the eventual owner of the layout and
 doesn't
 call the widget's dtor itself.
 
 If the layout is never used (ie. never passed as an argument to
 QWidget.setLayout()) then all the widgets in the layout will leak.
 
 An equivalent C++ version behaves in the same way.
 
 I could change addWidget() so that the layout doesn't take ownership of
 the
 widget (ie. to match the implementation rather than the documentation)
 but
 that will break any code that creates a populated layout and returns it
 from a function.
 
 I believe that it's more correct if you fix this code not to have any
 memory leak.

I disagree, I don't work around Qt bugs in PyQt.

 Either that, or you get smarter wrt when the ownership is
 transferred from Python to C++ (that is, when the layout is reparented
 to a widget, if ever).

The reason I'm not going to do this is that it would break lots of code (at
least, lots of my code).

 And in any case, you should probably raise this
 issue with Trolltech (it's at least a documentation issue, I'd say).

Agreed.

 Anyway, it turns out that I had reduced the testcase a little too much:
 it was not the actual memory leak I was seeing in my application.
 
 The correct testcase is this one:

Fixed in tonight's SIP snapshot.

Phil

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak

2008-07-06 Thread Giovanni Bajo 
On Sun, 2008-07-06 at 17:29 +0100, Phil Thompson wrote:
 On Sun, 06 Jul 2008 15:18:10 +0200, Giovanni Bajo [EMAIL PROTECTED]
 wrote:
  On Sat, 2008-07-05 at 23:04 +0100, Phil Thompson wrote:
  On Thu, 03 Jul 2008 16:04:42 +0200, Giovanni Bajo [EMAIL PROTECTED]
  wrote:
   Hi Phil,
   
   with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0:
   
   
   import sip
   import weakref
   from PyQt4.Qt import *
   
   class MyWidget(QWidget):
def sizeHint(self):
return QSize(900, 700)
   
   app = QApplication([])
   
   ws = MyWidget(None)
   wr = weakref.ref(ws)
   
   L = QVBoxLayout(None)
   L.addWidget(ws)
   L.activate()
   del L
   del ws
   
   import gc
   gc.collect()
   
   assert wr() is None
   
   
   The assert triggers, meaning that the object of type MyWidget is not 
   released.
  
  This appears to be a Qt problem. Although the docs say that a layout
  takes
  ownership of the widget when addWidget() is called it leaves the
  destruction of the widget to the eventual owner of the layout and
  doesn't
  call the widget's dtor itself.
  
  If the layout is never used (ie. never passed as an argument to
  QWidget.setLayout()) then all the widgets in the layout will leak.
  
  An equivalent C++ version behaves in the same way.
  
  I could change addWidget() so that the layout doesn't take ownership of
  the
  widget (ie. to match the implementation rather than the documentation)
  but
  that will break any code that creates a populated layout and returns it
  from a function.
  
  I believe that it's more correct if you fix this code not to have any
  memory leak.
 
 I disagree, I don't work around Qt bugs in PyQt.

Depends on whether you consider it a bug in the Qt documentation or a
bug in the Qt implementation. If it's the former, probably something
should be changed in PyQt as well. If it's the latter, then yes, leave
it to the Trolltech guys.

  Either that, or you get smarter wrt when the ownership is
  transferred from Python to C++ (that is, when the layout is reparented
  to a widget, if ever).
 
 The reason I'm not going to do this is that it would break lots of code (at
 least, lots of my code).

You can wait a major version to apply this breaker, but it's still
worthwhile. I think that explicitly breaking code is better than
implicitly causing memory leaks which hard to find and debug.

  Anyway, it turns out that I had reduced the testcase a little too much:
  it was not the actual memory leak I was seeing in my application.
  
  The correct testcase is this one:
 
 Fixed in tonight's SIP snapshot.

Many thanks!
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com


___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak

2008-07-05 Thread Phil Thompson 
On Thu, 03 Jul 2008 16:04:42 +0200, Giovanni Bajo [EMAIL PROTECTED]
wrote:
 Hi Phil,
 
 with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0:
 
 
 import sip
 import weakref
 from PyQt4.Qt import *
 
 class MyWidget(QWidget):
  def sizeHint(self):
  return QSize(900, 700)
 
 app = QApplication([])
 
 ws = MyWidget(None)
 wr = weakref.ref(ws)
 
 L = QVBoxLayout(None)
 L.addWidget(ws)
 L.activate()
 del L
 del ws
 
 import gc
 gc.collect()
 
 assert wr() is None
 
 
 The assert triggers, meaning that the object of type MyWidget is not 
 released.

This appears to be a Qt problem. Although the docs say that a layout takes
ownership of the widget when addWidget() is called it leaves the
destruction of the widget to the eventual owner of the layout and doesn't
call the widget's dtor itself.

If the layout is never used (ie. never passed as an argument to
QWidget.setLayout()) then all the widgets in the layout will leak.

An equivalent C++ version behaves in the same way.

I could change addWidget() so that the layout doesn't take ownership of the
widget (ie. to match the implementation rather than the documentation) but
that will break any code that creates a populated layout and returns it
from a function.

Phil

___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak

2008-07-04 Thread Sundance 
Giovanni Bajo wrote:

 The assert triggers, meaning that the object of type MyWidget is not
 released.

Hi Giovanni,

Yes, this is a known bug: SIP keeps a hard reference to bound methods in 
its method cache (the bound method being ws.sizeHint in your example). 
Since bound methods keep a reference to the object they're bound to, 
your object is never freed and its memory is leaked.

I understand Phil is already on it.

-- S.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak

2008-07-04 Thread Giovanni Bajo 
On Fri, 2008-07-04 at 10:48 +0200, Sundance wrote:
 Giovanni Bajo wrote:
 
  The assert triggers, meaning that the object of type MyWidget is not
  released.
 
 Hi Giovanni,
 
 Yes, this is a known bug: SIP keeps a hard reference to bound methods in 
 its method cache (the bound method being ws.sizeHint in your example). 
 Since bound methods keep a reference to the object they're bound to, 
 your object is never freed and its memory is leaked.
 
 I understand Phil is already on it.

It's a rather new regression, though. It wasn't happening 6 months ago.
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com


___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] Memory leak

2008-07-03 Thread Giovanni Bajo 

Hi Phil,

with SIP 4.7.6, PyQt 4.2.2, Qt 4.4.0:


import sip
import weakref
from PyQt4.Qt import *

class MyWidget(QWidget):
def sizeHint(self):
return QSize(900, 700)

app = QApplication([])

ws = MyWidget(None)
wr = weakref.ref(ws)

L = QVBoxLayout(None)
L.addWidget(ws)
L.activate()
del L
del ws

import gc
gc.collect()

assert wr() is None


The assert triggers, meaning that the object of type MyWidget is not 
released.

--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-24 Thread Noam Raphael 
Hurray! Thanks to Justin Noel on the qt-interest list, the following
code now works and doesn't leak!

Noam

===
#!/usr/bin/env python

import sys
from PyQt4 import QtCore, QtGui
from PyQt4.QtCore import Qt

class TableModel(QtCore.QAbstractTableModel):
def rowCount(self, index):
return 1000 if not index.isValid() else 0

def columnCount(self, index):
return 1000 if not index.isValid() else 0

def data(self, index, role):
if index.isValid() and role == Qt.DisplayRole:
return QtCore.QVariant(str((index.row(), index.column(
else:
return QtCore.QVariant()

def headerData(self, col, orientation, role):
if orientation == Qt.Horizontal and role == Qt.DisplayRole:
return QtCore.QVariant(str(col))
if orientation == Qt.Vertical and role == Qt.DisplayRole:
return QtCore.QVariant(str(col))
return QtCore.QVariant()


def main():
app = QtGui.QApplication(sys.argv)

model = TableModel()
tableView = QtGui.QTableView()
tableView.setModel(model)

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

if __name__ == '__main__':
main()
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-23 Thread Noam Raphael 
2007/12/23, Phil Thompson [EMAIL PROTECTED]:
  Is there anything that can be done?

 Not if I can't reproduce the problem. I'm using current SIP and PyQt snapshots
 and Qt 4.3.3.

It also works for me on windows, using the latest binary. But have you
tried it on linux? I'm using ubuntu 7.10, which uses gcc 4.1.3.

Noam
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-23 Thread Andreas Pakulat 
On 23.12.07 13:59:30, Noam Raphael wrote:
 2007/12/23, Phil Thompson [EMAIL PROTECTED]:
   Is there anything that can be done?
 
  Not if I can't reproduce the problem. I'm using current SIP and PyQt 
  snapshots
  and Qt 4.3.3.
 
 It also works for me on windows, using the latest binary. But have you
 tried it on linux? I'm using ubuntu 7.10, which uses gcc 4.1.3.

Works fine here on Debian unstable, with a bit older PyQt4(I think from
November) and Qt4.3.2. Yes the memory usage increases when starting to
scroll, but not that much. After scrolling from one end to the other on
both bars the python process is still under 30MB of res-memory according
to top.

Andreas

-- 
Time to be aggressive.  Go after a tattooed Virgo.
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-23 Thread Phil Thompson 
On Sunday 23 December 2007, Noam Raphael wrote:
 2007/12/23, Phil Thompson [EMAIL PROTECTED]:
   Is there anything that can be done?
 
  Not if I can't reproduce the problem. I'm using current SIP and PyQt
  snapshots and Qt 4.3.3.

 It also works for me on windows, using the latest binary. But have you
 tried it on linux?

Yes.

 I'm using ubuntu 7.10, which uses gcc 4.1.3. 

Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-23 Thread Noam Raphael 
2007/12/23, Andreas Pakulat [EMAIL PROTECTED]:
 Works fine here on Debian unstable, with a bit older PyQt4(I think from
 November) and Qt4.3.2. Yes the memory usage increases when starting to
 scroll, but not that much. After scrolling from one end to the other on
 both bars the python process is still under 30MB of res-memory according
 to top.

 Andreas

If you enlarge the window and scroll slowly, does it increase any
more? I think that every displayed cell leaks something, so if you
display more cells, you leak more memory.

Noam
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-23 Thread Phil Thompson 
On Sunday 23 December 2007, Noam Raphael wrote:
 2007/12/23, Andreas Pakulat [EMAIL PROTECTED]:
  Works fine here on Debian unstable, with a bit older PyQt4(I think from
  November) and Qt4.3.2. Yes the memory usage increases when starting to
  scroll, but not that much. After scrolling from one end to the other on
  both bars the python process is still under 30MB of res-memory according
  to top.
 
  Andreas

 If you enlarge the window and scroll slowly, does it increase any
 more? I think that every displayed cell leaks something, so if you
 display more cells, you leak more memory.

I see that behaviour, but a C++ version behaves in the same way so it's not a 
PyQt problem.

Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-22 Thread Noam Raphael 
2007/12/21, Phil Thompson [EMAIL PROTECTED]:
 Works fine for me with current versions.

 Phil

Ok, I now compiled by myself PyQt 4.3.3 with sip 4.7.3. I have qt
4.3.2 installed. The memory still leaks.

Is there anything that can be done?

Noam
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-22 Thread Phil Thompson 
On Saturday 22 December 2007, Noam Raphael wrote:
 2007/12/21, Phil Thompson [EMAIL PROTECTED]:
  Works fine for me with current versions.
 
  Phil

 Ok, I now compiled by myself PyQt 4.3.3 with sip 4.7.3. I have qt
 4.3.2 installed. The memory still leaks.

 Is there anything that can be done?

Not if I can't reproduce the problem. I'm using current SIP and PyQt snapshots 
and Qt 4.3.3.

Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyQt] Memory leak when using QAbstractTableModel

2007-12-21 Thread Phil Thompson 
On Thursday 20 December 2007, Noam Raphael wrote:
 Hello,

 I created a simple program which uses QAbstractTableModel to display a
 table with 1000x1000 cells. It works, but if I enlarge the window and
 scroll a little bit the memory consumption of the program jumps to the
 skies (If I weren't careful, my system would have stuck.)

 Here's the program. I'm using PyQt 4.3-2ubuntu7 on Ubuntu 7.10.

 ==
 #!/usr/bin/env python

 import sys
 from PyQt4 import QtCore, QtGui
 from PyQt4.QtCore import Qt

 class TableModel(QtCore.QAbstractTableModel):
 def rowCount(self, index):
 return 1000

 def columnCount(self, index):
 return 1000

 def data(self, index, role):
 return QtCore.QVariant(str((index.row(), index.column(

 def headerData(self, col, orientation, role):
 if orientation == Qt.Horizontal and role == Qt.DisplayRole:
 return QtCore.QVariant(str(col))
 if orientation == Qt.Vertical and role == Qt.DisplayRole:
 return QtCore.QVariant(str(col))
 return QtCore.QVariant()


 def main():
 app = QtGui.QApplication(sys.argv)

 model = TableModel()
 tableView = QtGui.QTableView()
 tableView.setModel(model)

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

 if __name__ == '__main__':
 main()
 ==

 Is there some way I can solve this?

Works fine for me with current versions.

Phil
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

[PyQt] Memory leak when using QAbstractTableModel

2007-12-20 Thread Noam Raphael 
Hello,

I created a simple program which uses QAbstractTableModel to display a
table with 1000x1000 cells. It works, but if I enlarge the window and
scroll a little bit the memory consumption of the program jumps to the
skies (If I weren't careful, my system would have stuck.)

Here's the program. I'm using PyQt 4.3-2ubuntu7 on Ubuntu 7.10.

==
#!/usr/bin/env python

import sys
from PyQt4 import QtCore, QtGui
from PyQt4.QtCore import Qt

class TableModel(QtCore.QAbstractTableModel):
def rowCount(self, index):
return 1000

def columnCount(self, index):
return 1000

def data(self, index, role):
return QtCore.QVariant(str((index.row(), index.column(

def headerData(self, col, orientation, role):
if orientation == Qt.Horizontal and role == Qt.DisplayRole:
return QtCore.QVariant(str(col))
if orientation == Qt.Vertical and role == Qt.DisplayRole:
return QtCore.QVariant(str(col))
return QtCore.QVariant()


def main():
app = QtGui.QApplication(sys.argv)

model = TableModel()
tableView = QtGui.QTableView()
tableView.setModel(model)

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

if __name__ == '__main__':
main()
==

Is there some way I can solve this?

Thanks a lot,
Noam
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt

Re: [PyKDE] PyQT Memory Leak (new)

2005-03-25 Thread Phil Thompson 
On Wednesday 23 March 2005 3:51 pm, Nahuel Greco wrote:
 Hi, I think that I have found a memory leak in the latest PyQT snapshot.
 When you create forms, if the form constructor connects their signals,
 after his destruction a weakref object remains in memory. Note the
 attached logs:

without_signal_connections.log: For this log I only pressed the second
 button, so the forms were created without connecting their signals. Python
 objects count remains constant, as you can see in the gc debug messages.
 Also the memory used don't increases.

connecting_signals.log: Here I only pressed the first button, the forms
 were created connecting their signals. This case leaks, the memory
 increased after each run, and you can see in the gc debug messages that for
 each created form an object of type 'weakref' remains without beign
 collected.

Amazing - that bug's been there since day one. Fixed in the next snapshot.

Thanks,
Phil

___
PyKDE mailing listPyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde

[PyKDE] PyQT Memory Leak (new)

2005-03-23 Thread Nahuel Greco 

Hi, I think that I have found a memory leak in the latest PyQT snapshot. When 
you
create forms, if the form constructor connects their signals, after his 
destruction
a weakref object remains in memory. Note the attached logs:

   without_signal_connections.log: For this log I only pressed the second 
button,
   so the forms were created without connecting their signals. Python objects 
count
   remains constant, as you can see in the gc debug messages. Also the memory 
used
   don't increases.

   connecting_signals.log: Here I only pressed the first button, the forms were
   created connecting their signals. This case leaks, the memory increased after
   each run, and you can see in the gc debug messages that for each created form
   an object of type 'weakref' remains without beign collected.


Saludos,
Nahuel Greco.




Saludos,
Nahuel Greco.



without_signal_connections.log
Description: Binary data


connecting_signals.log
Description: Binary data
#!/usr/bin/python
# -*- coding: iso-8859-1 -*-

import sys, os, time, gc
from qt import *

sys.stderr = sys.stdout

# Query Memory Usage Functions 
def report(s):
print s
sys.stdout.flush()

def presentMemData(s=):
vmsize = vmrss = 0 
for l in open('/proc/self/status','r').readlines():
if l.startswith('VmSize:'):
vmsize = int(l.split()[1])
elif l.startswith('VmRSS:'):
vmrss  = int(l.split()[1])
report(s+VmSize: %d Kb VmRss: %d Kb % (vmsize,vmrss))


class SimpleForm(QDialog):
def __init__(self, connect_signal=True):
# Note, I'm using None as the parent
QDialog.__init__(self, None)
   
self.button = QPushButton(self, Button)

if connect_signal:
self.connect(self.button, SIGNAL('clicked()'), self.buttonHandler)

def buttonHandler(self):
pass

   
class Main(QMainWindow):
def __init__(self):
QMainWindow.__init__(self)
self.last_gc_types = None

l = QVBoxLayout(self,3,3)

self.button1 = QPushButton(self)
self.button1.setText(1- Construct Forms connecting their signals)
self.button2 = QPushButton(self)
self.button2.setText(2- Construct Forms without connect their signals)
self.lab = QLabel(self)
self.lab.setText((Check console output for Memory Usage information))

l.addWidget(self.button1)
l.addWidget(self.button2)
l.addWidget(self.lab)

self.connect(self.button1, SIGNAL('clicked()'), self.button1Handler)
self.connect(self.button2, SIGNAL('clicked()'), self.button2Handler)

def button1Handler(self):
self.construct(True)

def button2Handler(self):
self.construct(False)

def construct(self, connect_signals):
global app
NUM_FORMS = 1000
   
report(-- %s - Constructing %d SimpleForm's, connecting signals=%r % \
   (time.strftime(%H:%M:%S), NUM_FORMS, connect_signals))

for x in xrange(NUM_FORMS):
s = SimpleForm(connect_signals)
#s.exec_loop()
s = None

#report(-- End Construction - Forcing GC with lowest thresholds)

old_thresholds = gc.get_threshold()
gc.set_debug(gc.DEBUG_LEAK | gc.DEBUG_STATS)
# After this setting, gc.collect() will check all the generations
gc.set_threshold(1,1,1)

col = gc.collect()

gc.set_threshold(*old_thresholds)
gc.set_debug(0)

uncol = len(gc.garbage)
if col or uncol:
report(-- GC Collected: %d Uncollected: %d % (col, uncol))

# Count instances by type
#lobj = None
reference_counts_by_type = {}
for obj in gc.get_objects():
t = type(obj)
if reference_counts_by_type.has_key(t):
reference_counts_by_type[t] += 1
lobj = obj
else:
reference_counts_by_type[t] = 1
#if lobj:
#report(REFERRS: %r %  gc.get_referrers(lobj))

# Dont press the button too fast, this line is for ensuring that
# the xlib memory is deallocated. 
app.processEvents()

# Print the types that now have more instances
if self.last_gc_types:
report(-- Types of python objects whose number of instances increased from last command:)
for k,v in self.last_gc_types.items():
if reference_counts_by_type.has_key(k) and reference_counts_by_type[k]  v:
report(\t%r instances count: %r (+%d) % (k,v, reference_counts_by_type[k] - v ))


self.last_gc_types = reference_counts_by_type
presentMemData(-- Memory Usage: )
report()


app = QApplication(sys.argv)
w = Main()
app.setMainWidget(w)
w.show()

report(QT