Re: Is method "const ColData Row::at(size_type i) const" leaking memory?

The version is 2.3.2.

I had messed up the source. Npw I have re-downloaded the source tarball and
recompiled it.

Please find here the correct valgrind message:


==10964== 111 bytes in 6 blocks are definitely lost in loss record 3 of 7
==10964==    at 0x4020628: operator new[](unsigned)
(vg_replace_malloc.c:197)
==10964==    by 0x40660FF: mysqlpp::Row::at(unsigned) const
(const_string.h:110)==10964==    by 0x4066316: mysqlpp::Row::operator[](char
const*) const (row.cpp:92)
==10964==    by 0x8061FFD:
btau::DBSession::retrieveLastLinkingitem(std::vector<btau::LinkingItemData,
std::allocator<btau::LinkingItemData> >&) const (DBSession.cpp:590)
==10964==    by 0x8076395:
btau::ApplicationDataLogicManager::saveTimestampAndLinkingItem(btau::TimeStampData&)
(ApplicationDataLogicManager.cpp:388)
==10964==    by 0x8089436:
btau::TSUMessageProcessingThread::manageTimeStampsaveRequest(TSURequest*)
(TSUMessageProcessingThread.cpp:526)
==10964==    by 0x8089D6D: btau::TSUMessageProcessingThread::Run()
(TSUMessageProcessingThread.cpp:402)
==10964==    by 0x809F402: Thread::StartThread(void*) (Thread.cpp:106)
==10964==    by 0x369432: start_thread (in /lib/libpthread-2.4.so)
==10964==    by 0x1C9A1D: clone (in /lib/libc-2.4.so)

could you please tell me if this allocated memory is not actually freed?

I am instantiating a "mysqlpp:Row" object without using the new operator
the way I showed in the previous message which is similar to this:

//...a function
//............
mysqlpp:Row row;
//..........

std::string mystring(row["row_name"]);//<<<<<<<<<<this line causes the
valgrind message showed above.

//....end of function



Many thanks.





--------- Original Message --------
        Da: plusplus@xxxxxxxxxxxxxxx
        To: MySQL++ Mailing List <plusplus@xxxxxxxxxxxxxxx>
        Oggetto: Re: Is method "const ColData Row::at(size_type i) const"  
leaking
memory?
        Data: 22/11/07 02:28
        
        > 
> 
> 
> Thunder0 wrote:
> > ==22261== 111 bytes in 6 blocks are definitely lost in loss record 3 of
7
> 
> A 111 byte memory leak wasn't a big deal even back in my DOS days...
> 
> > ==22261==    by 0x404B05F: mysqlpp::Row::at(unsigned) const
> > (const_string.h:123)==22261==    by 0x404B3E6:
mysqlpp::Row::operator[](char
> > const*) const (row.cpp:115)
> 
> This completely confuses me.  There is no Row::operator[](const char*) 
> at line 115 in row.cpp in any of the major past MySQL++ versions: 
> 1.7.40, 2.0.7, 2.1.1, 2.2.3, or 2.3.2.  The operator exists, but it is 
> in a different place in all these versions.  What version are you running?
> 
> > std::string value(row["ID_N"]);// >>>>>> line 590 mentioned in valgrind
> 
> Yes, this does allocate a bit of memory.  The operator referenced in the 
> previous quote calls ResUse::field_num(const std::string&), which 
> allocates a FieldNames() object to handle the translation between field 
> name and field index.  But, it's destroyed when the ResUse/Result object 
> gets destroyed, so the only way you should be seeing a leak is if your 
> code isn't disposing of the MySQL++ objects it creates.
> 
> -- 
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe:    http://lists.mysql.com/plusplus?unsub=thunder0@xxxxxxxx
> 
> 
> 
>  
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Utilizza l'email marketing di Email.it, oltre 2 milioni di utenti
registrati tra cui trovare i tuoi futuri clienti
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7148&d=20071126



-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx