incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matevž Bradač <mate...@gmail.com>
Subject Re: [RFC] File descriptor overflow running the test suite WAS: [BEP-0003] #355 - Summary of the work done towards multi-product support (2013-02-16)
Date Wed, 20 Feb 2013 07:50:06 GMT
I thought I saw the "etilqs" somewhere else, so after a bit of googling it rang a bell.
It's "sqlite" in reverse, and the files created seem to originate from calling sqlite3_open()
and providing NULL/empty string as the filename. From http://www.sqlite.org/c3ref/open.html:
=====
If the filename is an empty string, then a private, temporary on-disk database will be created.
This private database will be automatically deleted as soon as the database connection is
closed.
=====

And looking at the sqlite3 sources, the following can be observed:
[…]
** 2006-10-31:  The default prefix used to be "sqlite_".  But then
** Mcafee started using SQLite in their anti-virus product and it
** started putting files with the "sqlite" name in the c:/temp folder.
** This annoyed many windows users.  Those users would then do a 
** Google search for "sqlite", find the telephone numbers of the
** developers and call to wake them up at night and complain.
** For this reason, the default name prefix is changed to be "sqlite" 
** spelled backwards.  So the temp files are still identified, but
** anybody smart enough to figure out the code is also likely smart
** enough to know that calling the developer will not help get rid
** of the file.
*/
#ifndef SQLITE_TEMP_FILE_PREFIX
# define SQLITE_TEMP_FILE_PREFIX "etilqs_"
#endif
[…]

I'm not sure how trac creates the db for tests, but it seems not all db's are of in-memory
type.

--
matevz


On 20. Feb, 2013, at 0:08, Olemis Lang wrote:

> On 2/19/13, Branko Čibej <brane@wandisco.com> wrote:
>> On 19.02.2013 20:35, Olemis Lang wrote:
>>> - Does anybody have a clue about what is this about ? Thanks in
>>> advance for your comments .
>> 
>> Clearly we're leaking file handles, yes?
> 
> Yes , that's a fact ...
> :'(
> ... but I don't know whether it is BH code or Trac
> 
>> The first order of business is
>> to figure out where they're created and why they're in scope so long.
> 
> Yes , but I don't get it ... how can they be (deleted) and still
> descriptor active ?
> o.O
> 
>> Could be an artefact of using Python's tempfile mechanism.
>> 
> 
> Yes . I'm looking into this ... though it seems that module would
> create files under /tmp folder by default , but of course , a few args
> and that may be changed
> 
> Thanks .
> 
> -- 
> Regards,
> 
> Olemis.


Mime
View raw message