10 messages in com.mysql.lists.plusplusRe: BadConverion::what()=Tried to con...
FromSent OnAttachments
Drew Vogel11 Dec 2005 10:15 
Drew Vogel11 Dec 2005 10:42 
Warren Young12 Dec 2005 06:06.patch
Drew Vogel12 Dec 2005 06:33 
Warren Young12 Dec 2005 07:48 
Drew Vogel12 Dec 2005 10:37 
Warren Young12 Dec 2005 13:51 
Drew Vogel12 Dec 2005 14:01 
Drew Vogel15 Dec 2005 18:21 
Chris Frey19 Dec 2005 12:09 
Subject:Re: BadConverion::what()=Tried to convert "0.00P\uffffI" to a "d
From:Drew Vogel (dvo@intercarve.net)
Date:12/15/2005 06:21:29 PM
List:com.mysql.lists.plusplus

Drew Vogel wrote:

Warren Young wrote:

Drew Vogel wrote:

If I select all of the columns in the table (named, not using *), the last column (wpc_bludgeoning) is corrupted. When I select just the four wpc_* columns, the data in the third column (wpc_chopping) corrupted. In both scenerios, it corrupts the data in the last or third rows, respectively, for both rows in the result set.

Sounds like you have a memory bug somewhere. While it's possible that it is in MySQL++, you'd think that someone else would have run into something this blatant before.

If you're running on a Linux or OS X machine, try running your program under valgrind. If on Windows, you may only have the choice of commercial programs like Bounds Checker.

I'm not sure I actually solved this, but it went away. I went over the execution path once more today (think fresh eyes might catch something new). I realized that the Connection object was never closed or deleted. I added a call to ->close() and a delete statement. Now the data corruption is gone.

I am using the State Threads library, but the library never actually creates a new thread (the exception was being thrown in the startup code, before new threads are needed) so it is unlikely that this was causing a problem. Any ideas how closing or not closing the Connection object (well after the conversion is made) could have any effect on the conversion? If anything, I would think that the data corruption would happen if the conversion happened _after_ the connection was closed.

After running into this same memory corruption again, I did a bit more debugging. Through trial and error, I've determined that it only happens when I declare a row object and then initialize it later:

mysqlpp::Row row; while (row = res.fetch_row()) { ... }

The memory corruption does not appear if I declare the row object inside the loop condition:

while (mysqlpp::Row row = res.fetch_row()) { ... }

The tutorial examples clearly imply that the first form is legitimate. What am I missing here?