There is a multithreaded program that operates simultaneously with a device via COM port based communication and remote (IP) video stream. The program also uses OpenCV library to process the data.
The trouble is that it shuts down without any signals (neither run-time, nor any other errors are caught; log file has no anything useful as well). The most top level application error event handler is set and still there are no any signs of the program crash. It just closes after awhile.
The biggest difficulty is that it works fine on all our PCs for days non-stop. But fails on customers PCs so that testing process is very slow. Customer is in a different country (Asian localization, whilst ours is European), but the program is built with Unicode support.
So far we have got some assumptions about localization issues and antivirus activity... but it gives nothing in result.
The program is written with MinGW 4.4.x C++ and wxWidgets 2.9.3
Any suggestions of the probable origin would be appreciate.
Solved.
The problem was inside OpenCV build 2.3.1, that we use. The function cv::imdecode(...) uses stdio.h`s tempnam() function to generate temporary file during decoding. Under x86 Windows systems this function fails after 32767 new names for temporary file. Under x64 Windows systems it returns some nonsense string, but it still works.
So the solution I came with was to change the way of receiving-decoding images from our device.
Thanks everybody for comments.
Related
For my work, I am currently working on a existing system (C++) that communicates with a beckhoff PLC. This PLC reads the current speed of the process and controls a light.
This program needs an update to work with the new thickness measurement. The code for this new measurements works, we tested it on another computer.
The problem is that the communication between the beckhoff and the computer is not working anymore. This problem starts when we rebuild (a part of) the program. To check what went wrong, we used wireshark to check the communication.
In the figure below, you can see the correct communication with the Beckhoff PLC (with Ethercat).
In this figure, you can see the communication after we build the new program.
Of course, we tested a lot of option to elimate this problem but at the moment we cannot think of any other method to get the communication back.
Things we tried:
Compile the old code to see if the communication still works. This doesn't work. Only the originale .exe file works.
Go a few version back to test the communication. This also doesn't work.
We check the hardware configuration and the mac adress of the Beckhoff PLC. This is all correct.
It would be great if someone knows a solution for this problem. Please, don't hesitate to ask question for more information about the problem.
We have an unmanaged C++ application (MFC framework, Windows CE) that closes on us at seemingly random moments.
There is no error message and no C++ exception, it just vanishes.
I presume something bad must have happened and the C run-time or OS decided to kill the program. But I'm not sure where to continue searching.
Question: is it possible to see somewhere in Windows CE why the application terminated in the first place?
Does Windows CE collect basic crash information? Perhaps then one can at least see if it was an Access Violation, an Out of Memory situation, kernel/driver panic or perhaps some other kind of internal or external event that forced the application to close?
On a regular x86 PC one would break out the debugger, application verifier, Windows Error Reporting tools, WinDbg etc. But how to (start) analyze a Windows CE application crash?
What I've tried so far:
Creating global C++ exception handlers at tactical locations in the application. These build and transmit a simple UDP packet containing minimal exception info. these are then viewed on another machine running Wireshark.
Adding the SEH exception compiler switch (/EHa), to be able to catch even those non C++ exceptions, like Access Violation and such.
Connecting the Visual Studio 2008 debugger via TCP/IP with the Smart Device (connects to smart device successfully MSVS says, but debugger doesn't see any remote processes. The Attach to process VS window gives the following error: Unable to Connect to ''.)
Retarget the application so it runs on a regular x86 PC (but then it runs fine, so no "luxury" of debugging the issue there either)
I've tested the exception handler by forcing an Access Violation.
The expected UDP message the arrives at the machine running Wireshark perfectly. But when the real issue occurs, it stays completely silent.
The platform: MS Windows Embedded Compact 7.02 running on a Texas Instruments processor (ARM A8).
The application itself implements a rudimentary VNC viewer. It uses sockets and relies on a third party binary called zlib CE (ZLIBCE.DLL) for decompressing VNC data.
It hasn't been verified if the zlib binary has been built against the exact same compiler (and/or compiler settings).
Settled for a poor man's debugging solution. Now sending application state values to a memory mapped file. The idea is that a specially crafted helper program runs along the main application. This program opens the memory mapped file, displays values it reads from it. And the main program writes to it. If anything fatal happens to the main app, the helper program has the latest state info. Since it is shared memory it doesn't impact performance much. This way found the section of the program where the fault occurs.
I am working on a C++-based MIDI sending app and it's the first time I'm working with MIDI.
I chose the RtMidi library because it seems to be the most complete library around, but I'm open to suggestions.
The OS that I'm working on is Windows 7 and I have an USB-MID interface installed and it's working with other programs (i.e. Roland UM-One).
Now I may be way off-track, but I'd expect that when you do a search for ports, it should show this device.
When compiling the example code for RtMidi i get no ports; in or out.
What am I missing?
Do i need to open a virtual port?
This is also for others experiencing a similar issue as well:-
When I first started using RtMIDI, if you don't specify (on OSX at least) a macro define for the target system, the example code by default uses a dummy MIDI device, and this will have no MIDI ports.
Once I had specified MAC_OSX_CORE, then RtMIDI used the correct architecture and returned the MIDI devices on my system as expected. Perhaps you have to do something similar for your system - check the docs under "Compiling":
http://www.music.mcgill.ca/~gary/rtmidi/index.html#compiling
I've worked briefly with RtMidi and it is, as you stated, a rather complete library. However, when working with MIDI devices, you have to take the specific issues of this type of devices into account.
Another thing is that cheap USB-MIDI adapters often simply refuse to work with some applications "just because". They are very simple inside, yet apparently chinese manufacturers are still able to make malfunctioning devices.
If you're using unmodified, example code, and it's not showing your device, I'll first ensure all other apps that might be using it are closed, then try again. Creating a virtual interface is also a nice idea; I personally use freeware LoopBe1 for it. If it will show the virtual, but not the real interface, then the problem is with device itself. In that case you might want to experiment with different drivers or simply plugging it into a different port.
If it doesn't show any device, neither real nor virtual, then I strongly suspect there's something wrong in the way you build/run the application.
I'm writing a QT based native c++ app that uses QtSerialPort library under Win7. It communicates with it periodically(say every 5seconds).
Problem is: the device that my app connects to via serial port, has power loss issues(can't change this). When this happens my app becomes hung and immortal: can't be killed by windows task manager or by process hacker(a nice replacement for windows task manager)' termination facilities. Soft restart is the best solution at the hand.
Now how can my app cope with such device situation?
I would submit this question to Qt's interest mailing list (interest#qt-project.org). Since the QtSerialPort library is fairly new, bugs can appear when a wide user base starts using it. There is a good chance that the developers who wrote the library can give you a better solution or they find that this is a bug in their code and fix it.
How can i stop the host machine entering standby mode while my application is running?
Is there any win32 api call to do this?
There are two APIs, depending on what version of Windows.
XP,2000, 2003:
http://msdn.microsoft.com/en-us/library/aa373247(VS.85).aspx
Respond to PBT_APMQUERYSUSPEND.
Vista, 2008:
http://msdn.microsoft.com/en-us/library/aa373208(VS.85).aspx
There could be many valid reasons to prevent the computer from going to sleep. For example, watching a video, playing music, compiling a long running build, downloading large files, etc.
This article http://www.codeguru.com/cpp/w-p/system/messagehandling/article.php/c6907 provides a demo of how to do this from C++ (thought he article is framed as if you want to do it from Java, and provides a Java wrapper).
The actual code in in a zip file at http://www.codeguru.com/dbfiles/get_file/standbydetectdemo_src.zip?id=6907&lbl=STANDBYDETECTDEMO_SRC_ZIP&ds=20040406 and the C++ part of it is under com/ha/common/windows/standbydetector.
Hopefully it will give you enough of a direction to get started.