mysql++ connections always returning 0 rows ever since reboot

Question

this might be something obvious but i cannot for the life of me figure it out. Ever since we did a server reboot, a C++ program using mysql++ to connect to our database has just returned 0 rows for all queries instantly. My first thought was that my.cnf might not have been loaded correctly but it appears that it was, after checking show variables and comparing.

any suggestions? is it possible that some directory setting is failing to find some .so needed for mysqlpp that I don't know about?

any advice appreciated.

Answer 1

any suggestions?

Sure:

1. Ensure that you're checking all error code returns if you've disabled exceptions.

   If you haven't disabled exceptions, check that each catch block that could be involved isn't just quietly eating the error.

   The MySQL C API library (and therefore MySQL++) is probably trying to tell you what went wrong, and you're suppressing it or ignoring it somehow.

2. Build and run the examples. If they fail in the same way as your program, it means the problem is broad in nature. The examples have good diagnostics, so they may guide you to the problem.

   If the examples work fine, then the problem is specific to your program or its data. So, separate the cases:

   • Does the program work on a different machine against a DB with the same structure as the problem machine, but different contents?

   • If so, does it still work on that machine when you load a copy of the problem DB into the second machine?

   • And if that still works, does it work when you access the remote machine's DB directly from the system that does work? (Be careful with this one. You want to have SSL set up on the MySQL DB connection itself, or have some kind of secure channel to it, like a VPN or SSH tunnel.)

   If you run that gauntlet successfully, it means the problem is with the program itself on the original machine, or with the program's environment. Libraries or permissions, as you've speculated, are one possibility.

3. Run your program under a debugger.

   Try gdb first, because what we're interested in is whether the debugger sees any exceptions or signals thrown. Maybe the program is core dumping, for example.

   If gdb gives the program a clean bill of health, try valgrind. If Valgrind complains about your program, chances are good that it's complaining about something legitimate; maybe harmless, but legitimate. If you get complaints, and you found above that the problem is specific to one machine, I recommend re-trying the Valgrind run on the system where the program runs successfully. Fix those problems, or at least rule out the harmless warnings before continuing debugging on the original problem machine.

is it possible that some directory setting is failing to find some .so needed for mysqlpp that I don't know about?

It's easy to check:

$ ldd myprogram

You should get a report listing all the shared libraries your program is linking to, including their full paths. Any that are missing or unreadable by the user running ldd will be indicated.