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.
any suggestions?
Sure:
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.
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.
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.
Related
When running my asmjs\emscripten application, compiled from C++, it has suddenly started to log: "run() called, but dependencies remain, so not running" to the web console, and nothing more happens.
I've added some cout's at the absolute start of my main, but even they aren't reached.
The application executed successfully before, but suddenly this started to happen and I don't know what change triggered this.
Does anyone know how to debug this?
Update
After removing as much source code as I could, this happens as soon as I #include , even due my main simply consists of a single cout.
Ideally you would have the entire environment when it was running in version control, and build every version since to see where it broke.
You might have your code in version control, but perhaps not Emscripten itself. If you've updated Emscripten, this could lead to differences in behaviour. I would try going back to whatever version you used when it was running. Note that sometimes various cache directories survive an Emscripten version change, and might need to be cleared manually (I forgot which exactly).
The dependencies remaining could mean that you are trying to do something before Emscripten has loaded any other files it needs to, say files requested by --preload-file or --memory-init-file. Note that according to https://kripken.github.io/emscripten-site/docs/getting_started/FAQ.html#faq-when-safe-to-call-compiled-functions you should not try to run any Emscripten functions, until the C++ main function has run. To detect this, you can, for example, call your own Javascript function from main (there are other ways).
The fact this wasn't causing a problem before could have been something that seems quite unrelated: a change or update in the web browser, changing limits of concurrent downloads, or a change in the web server this is running from. You could look in the Network tab in the browser to see if anything leaps out at you as being different or suspicious.
However, as main isn't even reached, then it might not be that. I would try commenting out virtually all of your code, and make it so you have practically nothing but a hello-world program. Perhaps you don't have a correct setting in the Module object, or maybe the request for the memory initialization file is failing (you can check in the Network tab in the browser for that one). If your basic hello world program still isn't working, then you could post again, with its code, in a separate question.
This can also happens when the browser runs out of memory. Unfortunately, the browser's memory handling is not in our control so there isn't much you can do beside reducing your payload. This includes code size, preload content size, etc. Basically anything that can reduce the total memory consumption of your program will help fixing this. Browser vendors are constantly working to improve this, but it's going to take a while still.
I think you haven't given enough information to really know for sure. But it might be for instance that your js suddenly crossed some memory threshold which exceeds what the browser wants to allocate to it. You could try reducing the amount of memory used / streaming some assets instead of preloading them / ship less code / use -Os optimization level?
I have a simple C++ program (command line with Boost libraries) that I developed under Visual Studio Community 2013. I want to deploy it on other Windows computers, so I am testing InstallShield LE in Visual to do so (I am new with InstallShield). I added an InstallShield project in the current solution and I managed to create a setup.exe.
When I test it on another computer, setup seems OK but when I try the application, I have weird error:
MyProgramm.exe --help
Sends correct result (but it is not really interesting).
MyProgramm.exe -i InputDirectory -o OutputDirectory
Fails with a Windows displaying this message:
A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available.
What did I miss?
I built Release configuration only. How can I be sure that I have checked all the merge modules or InstallShield prerequisite ?
You will have to identify what is going wrong. Typically the symptom you describe indicates that an exception caused the process to terminate. One common source of such exceptions is misuse of an invalid pointer.
But why does it work on one computer and not another? Depending on the code it could be random incidental things. But as long as this repeats every time, it's more likely to be environmental. This could mean a missing data file, a missing registry key, a missing service, or a missing .dll dependency.
Because you can run the program at least one way, you know it's not a static dependency. If it were, you'd get a message about an inability to load some file or one of its dependencies. But instead in some execution paths you see a crash. So if it's a dependency, it's what InstallShield calls a dynamic dependency. I'm not personally a big fan of it (I'd much rather be told exactly what might be required), but there is a dynamic dependency scanning wizard that can help identify such files and include them into the project.
That will only help if the problem stems from something like this:
HMODULE hMod = ::LoadLibrary(TEXT("SomeFunky.dll"));
SOMEPROC proc = (SOMEPROC)::GetProcAddress(hMod, "SomeFunkyProc");
int result = proc(some, args);
Or maybe from a COM-related variant of that that looks something like this:
CComPtr<ISomeFace> spSomeFace;
HRESULT hr = spSomeFace.CoCreateInstance(CLSID_SomeFace);
hr = spSomeFace->SomeMethod(some, args);
The common problem here is that neither of these blocks of code verifies the function it's calling is safe to call. In the first case, proc (or even hMod) could be null; in the second, spSomeFace might not have been successfully created an instance. While the code can (and should) prevent these scenarios from crashing, fixing the crash will not get your application to actually do what it's supposed to, and you'll still have to fix the reason that the procedure, dll, or instance could not be initialized as desired.
It's also possible that you're missing a data file or registry key that at some point is being used in an incorrect fashion. For example, the code may assume a data file exists, build a pointer from data it reads, and fail to work correctly because the file wasn't available and thus the buffer it read into was never actually initialized.
So in short, to solve this, if it's not a dependency scenario that the dynamic dependency scanner can assist with, you may have to debug the code in question. You could try tools like Process Monitor and look for errors that involve your application shortly before the crash. If you have source and symbols, you could try running the program under WinDbg to figure out exactly what was crashing, and then try to figure out why it does so in one environment but not another. But from just the information you've already provided, there's nobody that can tell you the answer.
I am trying to compile a rather big application on Solaris. Compiling it on AIX caused a problem that the command line buffer was too small (ARG_MAX).
On Solaris it compiles most of application successfullym but then it just hangs and without any error hangs an do nothing for at least an hour.
I am running it on SunOS 5.10 Sparc 32 bit.
Any ideas on how to find out what's going on or what might be causing such behavior?
I can't tell if the compilation is hanging, or your app itself.
If the app is hanging just follow the usual debugging steps: Either run it in your debugger and watch when it dies, or add print statements.
If the compiler dies, does it always die on the same file? If you compile that file by itself does it still hang? If so, try trussing the compiler when you try to build the file that hangs. You may find that it's blocking on I/O waiting for some nonexistant file or something similar.
What you may have to do is:
Comment out or delete 99% of the code and compile that
Add around 5% of the code back in and compile that
if the last thing you added caused the hour hang then split it up
Back to step 2
Just for those who encounter this in future.
The problem was optimization flag causes it to take a REALLY long time to compile. I am talking 1+ hour for one cpp file.
This is big project.
In addition there was an issue with Sys Admin on SUN box not giving me enough CPU share.
Increasing that solved this problem, well made it quicker and within reasonable time bounds.
I hope this helps
I have a C++ windows service that sometimes crashes when I call the system() function to shell out a command. I've run the exact text of the command in the windows command-line, and it runs just fine, but for some reason it fails when system() is run.
To make matters worse, I can't seem to get any information as to why system() is failing. There doesn't seem to be an exception raised, because I'm doing a catch(...) and nothing's getting caught. My service just stops running. I know that it's the call to system() that is failing because I've put logging information before and after the call, and anything after just doesn't log anything.
So, is there a different way that I can shell out my command? At the very least, something that will give me some information if things go wrong, or at least let me handle an exception or something.
I belive system() is technically part of the C standard library, and therefore wouldn't throw exceptions. You should be able to check the return code or the ERRNO variable to get some information about what happened. This MSDN link has some information about the possible return codes on Windows.
I've also seen system() fail for other external reasons, such as virus scanners, so you might investigate that as well.
I don't know of a better way to run shell commands, but I could be wrong.
EDIT: If it still just seems to crash for no reason, you might try using process monitor to see what is going on at a lower level. Since the output from process monitor can be kind of overwhelming, a trick I like to use is to add a statement right before the call to system() to your program to open a nonexistent file like "C:\MARKER.TXT" or something, then you can search the process monitor output for the name of the file and look at the entries right afterward that may have something to do with the problem.
Ordinary catch() will not catch fatal exceptions (e.g. segmentation fault). You have to use structured exception handling. Better yet, enable post-mortem debugging; this article explains how you can enable post-mortem debugging of services.
You could use fork/exec, but I think that is what the system is doing.
I think your problem could be the user account associated on your service.
Either there's an environment problem (missing entry in path) or the account the service is using to run doesn't have the rights to exec whatever you're trying to run.
Run services.msc and look at the properties for your service.
On the logon page, as a test, change the setup so it uses your account to run the service. If it succeeds, you know what the problem is.
Another thing to look at is the path while inside the service. Use getenv( "PATH" ) and see if a path you might be reliant on is missing.
Hope this helps...
I ended up using CreateProcess. It's been working out so far.
I am debugging an Iphone program with the simulator in xCode and I have one last issue to resolve but I need help resolving it for the following reason: when it happens the program goes into debugging mode but no errors appear (no BAD ACCESS appears) and it does not show where the code fails. Putting some variables as global helps me to see their values to start pin pointing where the bug is but before I go into this fully I would like to know what techniques/tools you guys use to debug these situations.
If it helps Im debugging the following: I merged some code into the SpeakHere demo. The code was added in the C++ modules of the program (AQRecorder.h and .mm). I seem to have pinpointed the problem code in a function I wrote.
My favourite is always to add debugging code and log it to a file. This allows me so report any and all information I need to resolve the issue if the debugger is not working properly.
I normally control the debugging code by use of a flag which I can manipulate at run time or by the command line.
If the error is (and it probably is) a memory management issue, printing log entries is really not going to help.
I would reccomend learning how to use Instruments, and use its tools to track down the memory leak when it occurs rather than waiting until the application crashes later on.