10 messages in com.mysql.lists.plusplusRe: BadConverion::what()=Tried to con...| From | Sent On | Attachments |
|---|---|---|
| Drew Vogel | 11 Dec 2005 10:15 | |
| Drew Vogel | 11 Dec 2005 10:42 | |
| Warren Young | 12 Dec 2005 06:06 | .patch |
| Drew Vogel | 12 Dec 2005 06:33 | |
| Warren Young | 12 Dec 2005 07:48 | |
| Drew Vogel | 12 Dec 2005 10:37 | |
| Warren Young | 12 Dec 2005 13:51 | |
| Drew Vogel | 12 Dec 2005 14:01 | |
| Drew Vogel | 15 Dec 2005 18:21 | |
| Chris Frey | 19 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?
Drew Vogel





.patch