I'm building an application using JavaFX and noticed a unpleasant behavior (maybe a feature)
When the app launches and i start interacting with ui components (buttons specialli) the app reactivity is somehow slow, for example the buttons doesn't perform the click on time etc..
But once i use it enough (interacting with some ui components) it starts to act normal and reactive.
I guess there's something to do with lazy memory allocation or something like this. I've tried to start the JVM with 256mb using -Xms256m but still the same problem.
In an ordinary computer, something like that doesn't really bother, but my program is running in a Raspberry Pi 3 B Model, which is in fact annoying.
Any idea about such behavior ?
Related
Context
I'm trying to implement a sort-of orchestrator pattern for our applications.
Basically, we have three different and independent applications developped in Qt that communicate with each other using Web Socket. We'll call them "core", "business" and "ui". This is a flexibility aim as we can simply develop a new application in a more suiting technology and connect it to the others via the same communication protocole.
Now the idea is to have a simple launcher that allows us to specify which part to start. We launch this "orchestrator-like" application and it starts all required processes from a configuration file.
Everything is done in Qt currently (QML for the UI interfaces).
Initial Issue
I've made a custom class oriented towards reading the configuration file, preparing the processes, and starting them with their respective arguments.
This uses a std::map of QProcess related to their name in the configuration file and launch them using QProcess::start(<process_path>) method.
The catch is that everything went smoothly until recently. The sub processes are started and runs perfectly ; everything goes on as normal until we reach some point were the "ui" part crashes (usually an LLVM memory error or vector:: length error).
At first we thought about a memory leak or a code error but after much debugging we found that the application had no error whatsoever when we ran each part individually (without using the custom orchestrator class).
Question / Concerns
So, our question is: could it be that the QProcess:start() method actually shares the same stack with its parent? Three processes having the same parent, it would not be surprising than a vector of ~500 elements stored in each application can exceed the stack size when returned.
Information
We use MacOS Big Sur, IDE is Qt Creator, using Qt 5.15.0 and C++11.
Tried using valgrind but as read here and here, this seems a dead-end for now. The errors below were seen in the .crash file following the application exit.
libc++abi: terminating with uncaught exception of type std::length_error: vector
ui(2503,0x108215e00) malloc: can't allocate region :*** mach_vm_map(size=140280206704640, flags: 100) failed (error code=3) ui(2503,0x108215e00) malloc: *** set a breakpoint in malloc_error_break to debug LLVM ERROR: out of memory
Also tried to redirects or completly remove the application's output. First changing the setProcessChannelMode when starting the application, then with startDetached instead of start. Then, commented my Log method dumping log info into the corresponding Qt output (info/warning/critical/fatal/debug).
As suggested by #stanislav888, we could rewrite the application manager part in bash scripts and it would probably do the trick but I'd like to understand the root issue to avoid future mistakes.
It looks like a bad design. Application running and orchestrating through bash or PowerShell script looks much more better.
But anyway.
You could try to suppress orchestrated applications output and see what happen. The programs output might flood memory and make crash.
You must check what particular trouble cause the crash. Use memory "coredump" and system error messages to understand the all problem details.
I sure the community need that details. Because "оut of memory", "stack depth exceeded" and same errors make big difference.
Try to write bash or PowerShell script which does the same workflow as the Qt application. Hope it is not hard. But it will help you to figure out the issue.
At least you can run this script from the application.
Basically, I'm trying to carry out a number of tasks while a Visual Studio instance is running.
I have not been able to find anything yet in the Visual Studio SDK reference which is analogous to a background thread or IsRunning or anything like that. All I can do so far is respond to very specific events such as the view changing or the cursor being moved.
I don't even understand what event fires when the Visual Studio instance finishes loading.
Surely there must be something pretty big that I'm missing here? What manages the lifecycle of a Visual Studio instance?
So nothing prevents you from launching a background thread and doing work there. All sorts of components do that all the time. There are some ways you can register your package to load in various scenarios, and from there you could always launch a thread.
Be careful of course with any of these -- if everybody did "I'll run a background thread once VS loads", your CPU cores would be very, very busy! There's an older concept in VS called the "idle loop" where some code can be registered to run whenever the UI thread doesn't have a message to pump, and the internal joke is that the idle loop is never idle.
this is a more unusual question so give me a hint when stack overflow isn't the right place for it. ;)
I have a problem with Visualstion 2012 where it freezes every so often when I compile my project.
I am currently working on a Qt project so the Qt add-in is installed. I am sure you can't remote-fix my problem but I would like to ask what could cause such freezes.
Here are some important infos:
the PC doens't freeze every time I compile (seems to be a bit random)
the freeze takes from 5 to 15 minutes. In most cases, it ends with the screen switching to black and then back to "normal"
I often try to open the task manager which returns an exit code after the freeze which says that the task manager couldn't start
the PC comes back to life after 5-15 minutes but many applications (incl VS) aren't responding for additional ~5 minutes.
the hardware components are fine for what I can tell. (I tested HDD and RAM, temps are fine)
I hope you can give me a hint where the cause of the freezes could be hiding. ;)
You could start by analyzing what is unique about your system.
Perhaps you are using an unusual source control system, anti-virus, network connections, mapped drives or some weird form of integration that nobody else uses. My guess is that this may be your source control integration or some server connection that is triggering an unusual locking condition.
I am working on a QT application for which I've integrated DirectX 11 into a custom widget. The application renders a scrolling display - a graphical representation of data being read from a file. The user can speed up and slow down the scrolling speed.
For the most part, this is working great. The DirectX 11 rendering is presented to my custom widget just as I'd expect. The problem is that the graphics driver randomly hangs and crashes my program. I say "random" because I have been testing this with the same data file and it never seems to crash at the same point in the file, after a specific amount of time, or at a specific scrolling speed (the faster the scrolling speed, the more work being done by the GPU per frame).
When the application hangs, my screen freezes for a moment, goes black, then returns with a nice message from NVidia that it has recovered from a driver crash. The Debug Output in Visual Studio contains the following:
D3D11: Removing Device.
D3D11 ERROR: ID3D11Device::RemoveDevice:
Device removal has been triggered for the following reason
(DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of
time to execute its commands, or the hardware crashed/hung. As a
result, the TDR (Timeout Detection and Recovery) mechanism has been
triggered. The current Device Context was executing commands when the
hang occurred. The application may want to respawn and fallback to
less aggressive use of the display hardware). [ EXECUTION ERROR #378:
DEVICE_REMOVAL_PROCESS_AT_FAULT]
I have discovered that by simply commenting out the IDXGISwapChain1::Present call, the application will run through the file at blazing speed. Graphics-wise it is still pushing data to the GPU and drawing to render targets, it just never gets displayed to my window.
What I'm hoping for is help with ideas of what types of things cause driver hangs. My shaders are incredibly simple - basically just positioning my vertices using a projection matrix. And considering what I described in the above paragraph, shaders should still be cranking through vertices and pixels even when Present isn't being called, yes?
I was suspicious that this could be a compatibility issue with Qt - I know DirectX isn't officially supported by Qt. So I tried creating a separate window using CreateWindowEx and using that for my swap chain instead of the custom Qt widget. It rendered to that window but also hung the driver just like before.
I was also suspicious of a driver bug in my laptop, so I tried running the application on a beefier desktop PC that regularly runs another DirectX 11 application (non-Qt) without a hitch (worth mentioning that this other application renders similar data in a scrolling display as well, using shaders that are a lot more complex). But my QT application hangs the driver on that PC as well.
Anyone know of a way I can get a more detailed description of what is causing the driver to hang?
Thank you in advance for any help you can offer.
UPDATE: 2013-08-01 17:16 CST
I am currently investigating a possible thread syncing issue that may be the culprit. Will continue tomorrow morning and post if I solve this on my own.
After some testing today, it appears to have been a threading issue. I have run several times today with no graphics crash. So my problem must be fixed, unless I've just been getting lucky with my tests today (or unlucky, rather - if this shows its ugly face again in a day or two).
I was aware that the immediate device context is not thread safe. Rather than using deferred contexts, though, I was using critical sections to sync my threads and coordinate use of the device context. What I did not realize is that it is not safe to call IDXGISwapChain1::Present while another thread is using the device context. Makes sense, but since it is not call directly from the device context itself, I overlooked it. I literally moved my Present() call a few lines up into my critical section block, and it hasn't given me a crash since.
Is there a framework to simulate a deterministically pseudorandom series of clicks imposed upon a Qt application - in order to try to trigger any memory leaks, threading errors etc - typical monkey-testing?
Some exotic, monkey use for QTestLib?
Yes, you can use the useful unit test module. Look in particular at the class QTestEventList. Just provide the QWidget you want to test, or the QMainWindow or whatever subclass you want and add the list of events you want to generate. If you want to generate a sequence of points so that you can reproduce in case of failure, use qsrand() and qrand().
The Squish automated GUI testing framework can be used to do monkey clicking in your application. There are a couple of nice things about using Squish for this purpose:
Squish runs on Windows, Mac, Linux and Android
It logs whatever random steps it happens to perform as a script that can be re-run (monkey testing docs)
It has an option to take a screenshot on application crash (screenshot on failure settings docs)
Disadvantages: Squish is not free. Setting up Squish to run your application can be super-irritating, especially if your application requires specific build characteristics of Qt or Python.