Norbert,
Thank you for your response.
I was thinking that it was not OpenDBX but perhaps the backend or FreeTDS, or
even some other lower level driver.
We also connect to a PostGres database in another application but have yet to
see this problem which reinforces it being below OpenDbx.
We do call Conn::unbind().
We found that if we call Conn::finish() the application crashes as follows:
If we call Result::finish(), Conn::unbind() no crash.
When we call Result::finish(), Conn::unbind(), Conn::finish() all three calls
complete correctly, When the function is exited the OpenDBX::Result object goes
out of scope and the destructor is called.
In the destructor, OpenDBX::~Result(), the delete m_impl; crashes the
application with a segmentation fault, I assume because the m_impl was already
deleted in Conn::finish()?
Back to the /dev/urandom open descriptor problem, another interesting finding
is:
When we use a local OpenDBX::Conn object, (on stack) the file descriptor is not
closed so each call to the function leaves another one open ultimately
resulting in a "Too Many Open Files" crash.
However if we use a global (statically allocated) OpenDBX::Conn object there is
only one /dev/urandom file descriptor left open.
I also did a test where I added the Conn::finish() call and then in
OpenDBX::~Result() I used the debugger to skip over the delete m_impl;
statement so the application doesn't crash.
The /dev/unrandom file descriptor is still left open for each call so I do not
think a call to Conn::finish() would fix this issue.
Regards,
Adam
Hi Adam
> We are using OpenDbx (C++) with MSSQL, on Ubuntu 12.04. Our
> application is long running with many calls to the database. Our
> application uses a local OpenDBX::Conn object to connect (bind),
> retrieve result, finish results, unbind and then the local
> OpenDBX::Conn object goes out of scope when function returns.
>
> After a period of time our program crashes, with the usual error
> being "too many open files". Our process open file limit is the
> default 1024. After some debugging we found that a file descriptor
> to /dev/urandom is left open for each connection we made to the
> data base. Of course after roughly 1024 connections to the database
> the application crashes with the above error as would be expected.
/dev/urandom is not used by OpenDBX directly but I think by FreeTDS if
you are using the MSSQL backend.
> Has anyone experienced this? Is there a workaround or patch? Are
> we using the library correctly?
Can you please have a look if you call Conn::unbind() and
Conn::finish() before the objects go out of scope? This is important
as the cleanup can't be done by the destructor of the class.
Norbert
Adam
____________________________________________________________
This e-mail (including attached documents) may contain confidential or
proprietary
information intended only for use by the named recipient(s). Use by persons
other than the named recipient(s), further dissemination, or copying of this
email is prohibited unless authorized by the sender.
------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
libopendbx-devel mailing list
libopendbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
http://www.linuxnetworks.de/doc/index.php/OpenDBX
