*** ajmitch has quit IRC
*** havoc has quit IRC
*** ajmitch has joined #gnuenterprise
*** mnemoc has quit IRC
*** btami has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** dcmwai has quit IRC
*** dcmwai has joined #gnuenterprise
*** sjc has quit IRC
*** sjc has joined #gnuenterprise
*** nickr has quit IRC
*** reinhard has joined #gnuenterprise
*** dcmwai has quit IRC
*** johannesV has joined #gnuenterprise
<johannesV> hello again ... :)
<kilo> good morning Austria
<johannesV> hi kilo
<reinhard> johannesV!
<reinhard> the return of the king!
<reinhard> :-)
<johannesV> :)
<johannesV> i've already read all those irc-logs ...
<kilo> where have you been?
<johannesV> it was quite a lot
<johannesV> i had an operation ...
<kilo> oh
<johannesV> and my nose is still *big*
<johannesV> and the doctor told me not to work at my computer for about a week ... :(
<johannesV> but i'd say about half an hour of gnue is better then the medicine ... :)
<kilo> whisky is the only medicine for any disease 8-)))
<johannesV> :)
<johannesV> i'm off for today ..
<johannesV> bye
*** johannesV has quit IRC
*** holycow has joined #gnuenterprise
*** reinhard has left #gnuenterprise
*** reinhard has joined #gnuenterprise
*** havoc has joined #gnuenterprise
<btami> bbl
*** btami has quit IRC
*** havoc has quit IRC
*** havoc has joined #gnuenterprise
*** mnemoc has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> hm, found something weird in GDataSource/appserver.data ...
<johannesV> we create a lot of 'uncollectable' garbage with DataSourceWrapper () instances ....
<kilo> hmmm, found something weird in Designer code...
<kilo> no, the whole Designer code is weird 8-)))
<reinhard> lol
<johannesV> well, in data.py we create instances of DataSourceWrapper which won't be available anywhere
<johannesV> but these instances do have references to objects which are available
<reinhard> erm
<reinhard> DataSourceWrapper is a function :)
<reinhard> not a class
*** sjc has quit IRC
<reinhard> and returns a DataSource object
<johannesV> but it creates an instance of _DataSourceWrapper
<reinhard> yes
<reinhard> that are more or less normal DataSource instances
<chillywi1ly> bah
<reinhard> (_DataSourceWrapper is a descendant of GDataSource)
<johannesV> correct
<johannesV> look at all that sequences and dictionaries defined in a GDataSouce ...
<johannesV> all these migth contain references ending up in ref-cycles
<johannesV> s/migth/might/
<johannesV> and, in fact, there are a lot of such cycles ...
<reinhard> wasn't that exactly what we took care of when we did the first memory leak fix round?
<johannesV> no, i don't think so
<johannesV> there we fixed closing result- and recordsets
<reinhard> so did anything change about the number of DataSources we create?
<reinhard> lekma claims that the version of february 12 is memory leak clean
<johannesV> i'm not sure, but i'd say no
<johannesV> i did the following: geasRpcServer got anohter signal-handler (sigusr1)
<johannesV> if it catches this signal, gc is asked to collect everything
<johannesV> all 'uncollectable' stuff get's dumped into a file
<johannesV> so after starting the appserver and sending him a sigusr1 (without anything in between)
<johannesV> i get a quite huge file, holding a lot of datasource-stuff
<reinhard> ok
<johannesV> after starting a script (against appserver) the file grows
<reinhard> the diff between the files would be interesting
<johannesV> and - now it get's interesting - it has another big bunch of datasouce-stuff
<johannesV> with all that things the script does
<johannesV> right :)
<reinhard> well this might become a bit complicated
<johannesV> to me it looks like all data fetched by a datasource remains in memory (cause it get's somehow unreachable)
<johannesV> reinhard, true, it already *is* complicated ....
<reinhard> but could you save your current diff (adding the SIGUSR1 handler) to a file
<reinhard> then reset to 12 february version
<reinhard> apply that SIGUSR1 patch to that version
<reinhard> and see wheter it already was that bad at that time?
<johannesV> hmm, one major problem with a diff are those memory addresses ...
<johannesV> i can do a diff of two logs from the same process ...
<reinhard> sorry misunderstanding
<reinhard> i meant
<reinhard> do svn diff > file
<reinhard> svn update -R <version of 12 february>
<reinhard> patch < file
<reinhard> then test again
<reinhard> I would like to verify the claim that there was no memory leak at 12 february
<reinhard> of course not demanding anything, just proposing, knowing you are officially still "out of order" for this week
<johannesV> hmm, i can revert the gnue code on my boston to rev 7018, so i do not need to diff my current svn
<johannesV> i'm working on my notebook....
<johannesV> and
<johannesV> i'm in bed ... :)
<johannesV> so the doctor can't say anything *lol*
<reinhard> johannesV: but you would need the SIGUSR1 code to test, wouldn't you?
<johannesV> of course, but that's about 5 lines :)
<reinhard> uh
<reinhard> sounded much more complicated :)
<johannesV> ok, maybe 10 :)
<reinhard> johannesV: gotta love your wlan, don't you? ;-)
*** mnemoc has quit IRC
<johannesV> reinhard, i have a rj45 box in every room, so i don't need the wlan :)
<johannesV> currently i'm using a wire ...
<johannesV> it's faster :)
<reinhard> wow
<chillywi1ly> wi-fi rules
<kilo> i remember people on the university who worked in the microwave labs were all fat, bold, and had only daughters... 8-))))
<reinhard> hrmm
* reinhard has only daughters
<johannesV> johannesV, has both :)
<chillywi1ly> kilo: what are you implying?
*** jamest has joined #gnuenterprise
<kilo> nothing. but the less waves around the better you are...
<chillywi1ly> pfft, what doesn't kill you only makes you stronger ;)
<johannesV> reinhard, same leak seems to be in rev. 7018
<kilo> chillywi1ly: lol. whisky is the clue 8-))
<chillywi1ly> maybe I should go into the office now
<chillywi1ly> coding in your underwear is so productive though ;)
<havoc> go to work already
<chillywi1ly> why? all they do is call me and ask stupid questions there?
<kilo> and is coding in your underwear in your office productive?
<chillywi1ly> s/there?/there/
<johannesV> ok, rev 7018 has the same number of unreachable objects/instances as the current svn has
<kilo> chillywi1ly: and is coding in someone else's underwear productive? 8-))
<reinhard> strange
<johannesV> well, i don't think it's strange ...
<johannesV> i think we should solve this problem in common
*** mnemoc has joined #gnuenterprise
<johannesV> this way remaining unreachables are easier to find :)
<johannesV> i think a datasource should have some mechanism to get 'cleared for removal'
<chillywi1ly> kilo: probably not ;)
<johannesV> where all internal refs (to resultsets, field-collections, listeners and the like) are cleared
<johannesV> so no cycles remain
<reinhard> johannesV: maybe the other way around could be easier
<reinhard> checking which other object still references the DataSource
<johannesV> well, i can try to find this out (maybe cyclops is helpful for this ...)
<johannesV> # objects in root set: 1
<johannesV> # distinct structured objects reachable: 92
<johannesV> # distinct structured objects in cycles: 36
<johannesV> # cycles found: 20
<johannesV> # cycles filtered out: 0
<johannesV> # strongly-connected components: 2
<johannesV> # arcs examined: 638
<johannesV> this is the dump of a *single* datasouce returend in data.py
<johannesV> :)
<johannesV> it's the DataObject having a pointer to the datasource
<johannesV> 2-element cycle
<johannesV> 0x40ac956c rc:2 instance gnue.common.datasources.drivers.postgresql.Base.DataObject.DataObject_Object
<johannesV>     repr: <gnue.common.datasources.drivers.postgresql.Base.DataObject.DataObject_Object instance at 0x40ac956c>
<johannesV>     this._dataSource ->
<johannesV> 0x40a9182c rc:19 instance gnue.common.datasources.GDataSource._DataSourceWrapper
<johannesV>     repr: <gnue.common.datasources.GDataSource._DataSourceWrapper instance at 0x40a9182c>
<johannesV>     this._dataObject ->
<johannesV> 0x40ac956c rc:2 instance gnue.common.datasources.drivers.postgresql.Base.DataObject.DataObject_Object
<johannesV>     repr: <gnue.common.datasources.drivers.postgresql.Base.DataObject.DataObject_Object instance at 0x40ac956c>
<kilo> bbl
*** kilo has quit IRC
<reinhard> looks like a GDataSource.close() would indeed make sense
<johannesV> maybe we can break the link in an existing close
<reinhard> that sets _dataObject to None
<johannesV> like in Base/ResultSet.close ()
<johannesV> where _dataObject is set to None
<johannesV> just before that we could set _dataObject._dataSource to None
<johannesV> to make sure we clear the link
<reinhard> no
<reinhard> I don't think we may do that
<reinhard> we can close the resultset and still want to keep the datasource and the dataobject
<reinhard> hmmm... I think....
<reinhard> but I'm not entirely sure
<reinhard> bad thing is in data.py we don't have the datasource...
<johannesV> right, as i've said before
<johannesV> we have no ref to the datasource we create resultsets of
<reinhard> there are times when I think that gnue-commons datasource system is unnecessarily complex and bloated
<reinhard> but that's only when I have a bad day I think
<reinhard> ;-)
<johannesV> *lol*
<reinhard> johannesV: I think we can do it like you said
<johannesV> hmm, i've said a lot of things .... :)
<reinhard> johannesV: like in Base/ResultSet.close ()
<reinhard> johannesV: where _dataObject is set to None
<reinhard> johannesV: just before that we could set _dataObject._dataSource to None
<johannesV> ah
<johannesV> well, but this would mean if there are two resultsets of the same datasource we might get into troubles ... don't we ?
<reinhard> *can* a datasource have more than one resultset?
<johannesV> not in our case (appserver)
<johannesV> but if i think of trigger-code in forms it might
<reinhard> alternatively
<johannesV> we could keep track of all datasources created
<johannesV> and in data.connection.close () we could resolve the links
<reinhard> we could in data.py where we call the resultSet.close() also do a resultSet._dataObject._dataSource.close()
<reinhard> actually
<reinhard> I would wonder if a resultset can survive without a datasource
<reinhard> that would be the nicest thing
<reinhard> then we could kill both datasource and dataobject immediately after creating the resultset
<johannesV> right
<johannesV> i think there are some triggers fired (like on-new-record and the like ...
<johannesV> )
*** jcater has joined #gnuenterprise
<reinhard> yes
<reinhard> and dataObject is used quite often AFAICT
<reinhard> then again
<reinhard> I think nobody except appserver calls ResultSet.close() anyway
<jcater> I think resultset.close() was added as appserver developers didn't like the warning messages :)
<jcater> we just haven't gotten around to using the function in the other tools yet
<jcater> :-/
<reinhard> jcater: no, resultset.close() was created to clean up memory leaks
<reinhard> or, better put, cyclic object references that would otherwise result in memory leaks
<jcater> I must be thinking of connection.close() then
<reinhard> yes, that was that
<johannesV> ok, if i add a reference-breaking code into Base/ResultSet.close () some cyclic refs are removed
<johannesV> but there are still 116 left (after appserver's startup)
<reinhard> so we have other cycles as well
<reinhard> ?
<johannesV> right
<johannesV> a lot of them :)
<reinhard> question is a lot of different ones or a all of the same kind :)
<johannesV> there are instances of DBSIG2.ResultSets
<johannesV> as well as a lot of dicts and sequences
<johannesV> it's hard to tell ... though
<johannesV> and a lot of bound methods !??
<johannesV> will try something different .... (adding a close () function to GDataSource)
<johannesV> wohoo .. only 45 left
<johannesV> ok, now all unreachable are gone (after appserver's startup)
<johannesV> reinhard, if we keep track of all datasources created in data.py and deleting them in connection.close ()
<johannesV> there's no need of a change in common
<johannesV> but, we'd have to keep track of datasources per connection (data.py) -instance
<johannesV> anyway, if i execute 'dirty.py' (in appserver's sample/testing) 2003 unreachable instances are left (after sending a sigusr1)
<johannesV> so there must be other leaks in there too
<reinhard> johannesV: to delete the datasource instances on connection close seems a bit late to me
<reinhard> there might be connections open for several days
<reinhard> so I'd prefer to delete the datasource whenever the matching recordset is deleted
*** titopbs has joined #gnuenterprise
<johannesV> well, so we still need to keep track of the datasources created
<reinhard> yes of course
<reinhard> even more detailed
<johannesV> as i see things we should 'use' the datasource instead of the resultset in data.py
<johannesV> instead of 'silently dropping' it
<reinhard> maybe yes
<reinhard> so not work with the resultset but with the datasource
<johannesV> like _createEmptyResultSet () function ... it creates another datasource and returns only a resultset
<reinhard> yes
<reinhard> actually my understanding is that you should be able to do everything you want through the datasource
<reinhard> not caring about all the different objects lying below
*** johannesV_ has joined #gnuenterprise
<reinhard> bbl
*** johannesV has quit IRC
*** holycow has quit IRC
*** nickr has joined #gnuenterprise
*** johannesV_ has quit IRC
*** wendall911 has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** dcmwai has quit IRC
*** sjc has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** johannesV has quit IRC
*** kilo has joined #gnuenterprise
*** btami has quit IRC
<reinhard> night all
*** reinhard has quit IRC
*** kilo has quit IRC
*** jcater has quit IRC
*** jamest has quit IRC
*** titopbs has quit IRC
*** nickr has quit IRC
*** nickr has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** jcater has quit IRC
*** jamest has joined #gnuenterprise
*** sjc has quit IRC
*** tiredbones has joined #gnuenterprise
*** holycow has quit IRC
*** titopbs has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** holycow has quit IRC
*** holycow has joined #gnuenterprise
*** wendall_away has left #gnuenterprise
*** holycow has quit IRC
*** holycow has joined #gnuenterprise
*** havoc has quit IRC
*** havoc has joined #gnuenterprise
*** holycow has quit IRC
*** titopbs has quit IRC
*** dcmwai has joined #gnuenterprise
*** tiredbones has quit IRC