Bug #60169 | Have memory leak then trying to connect to the database fails | ||
---|---|---|---|
Submitted: | 18 Feb 2011 15:25 | Modified: | 19 Feb 2011 9:11 |
Reporter: | Dmitry Vs | Email Updates: | |
Status: | Unsupported | Impact on me: | |
Category: | MySQL++ | Severity: | S2 (Serious) |
Version: | 3.0.9 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | Connection, Contribution, Leak, Memory |
[18 Feb 2011 15:25]
Dmitry Vs
[18 Feb 2011 15:54]
Valeriy Kravchuk
MySQL++ is not developed and not supported by MySQL/Oracle for many years already. Please, report you bug and suggested fix at: http://gna.org/bugs/?group=mysqlpp
[18 Feb 2011 15:57]
MySQL Verification Team
Hi! Thank you so much for creating this bug in our system, but MySQL++ is not our product for many years now. For several years already, we have our own product, which is Connector/C++, that you can read about on our Connector's pages. I would recommend that you write about this problem to MySQL++ mailing list. As you are probably aware, it's home page is on tangentsoft site. That being said, I am curious why do you think that this is a memory leak ??? Destructor properly deletes the objects. delete operator frees all the memory. Why do you have to go into MySQL++ and change internal allocator ??? How did you diagnose memory leak and what object is leaking memory ??? Once again, I do recommend that you write to the mailing list.
[18 Feb 2011 20:55]
Dmitry Vs
> Destructor properly deletes the objects. delete operator frees all the memory. They allocate new DBDriver object in constructor {{{ Connection::Connection(const char* db, const char* server, const char* user, const char* password, unsigned int port) : OptionalExceptions(), driver_(new DBDriver()), copacetic_(true) { connect(db, server, user, password, port); } }}} and "connect" throw the exception, have no destructor call after that i think > How did you diagnose memory leak and what object is leaking memory ??? I just use linux "top".