**Comment from Launchpad by: Brian Fraser on: 27-08-2012 04:58:28

Ryan: Ah, that's really helpful, thank you! To keep things a bit more organized, I've opened a new bug report for the second crash (https://bugs.launchpad.net/percona-toolkit/+bug/1042036). With some luck, this will get a fix by the time 2.1.4 rolls out in the next week or two.

**Comment from Launchpad by: Ryan Brothers on: 23-08-2012 19:16:11

Brian - interesting, I just noticed that I can only reproduce it with MySQL 5.5.25a from mysql.com. If I try it with Percona Server 5.5.25a, it works fine. Attached is the PTDEBUG output from running against MySQL 5.5.25a from mysql.com.

I am running:

pt-table-sync --execute h=localhost,P=3306,u=test,p=test,D=db1,t=table1 D=db2

**Comment from Launchpad by: Brian Fraser on: 23-08-2012 18:32:52

Ryan, unfortunately, no dice, the second sql didn't reproduce the bug for me. Since it does for you, mind sending the command line and if possible, the PTDEBUG output?

For the division by zero bug, admittedtly, that would be ideal, but by the time the base==1 case comes up, we're deep inside the tool, and because of some design limitations changing the algorithm just isn't feasible; pt-table-sync is long due an overhaul, but that's not going to happen in the near future, I'm afraid.
(Although personally, I think it's a bit of a blessing in disguise: The tools are already quite magical, so being explicit about the algo earns points in my book.)

**Comment from Launchpad by: Ryan Brothers on: 23-08-2012 15:01:49

Brian - thanks for checking into the issues. I actually was able to create a reproduce script for the 2nd bug and I posted it above in comment #3 in reproduce2.sql. Does that reproduce the problem for you?

For the division by zero bug, rather than returning an error to pick a different algorithm, could pt-table-sync itself just recognize this scenario and pick a different algorithm on its own? In my call to pt-table-sync, I'm not specifying the --algorithm, so I don't have a preference about which algorithm is used, so I prefer in this case just for pt-table-sync to pick the correct algorithm so the data gets synced. Thanks.

**Comment from Launchpad by: Brian Fraser on: 22-08-2012 19:34:44

The second bug is.. odd. The only way I can think of triggering the second bug is by having your mysql's latin1 charset be different from the standard charset. I'm really at loss for how to test or avoid it; it's one of those "shouldn't happen" scenarios. Ryan, could you post a PTDEBUG=1 of the "Use of uninitialized value in join or string" error? It would really help in getting this fixed.

Daniel & I discussed the division by zero bug, and the consensus was that if base was equal to one, then the chunking algorithm wasn't able to handle the table, so the tool will just exit and suggest picking a different algorithm; We'll add a note in the documentation about cases like this.