I am using Qt 5.6 . I have created a application which contains many widgets such as labels,Buttons..etc.
Now I added a label in to my gui , But I am not able to access the label (ui->label_name).
While compile the application I am getting below prints.
*In file included from mainwindow.cpp:10:0: ui_mainwindow.h: In member function 'void Ui_MainWindow::setupUi(QMainWindow*)': ui_mainwindow.h:853:10: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
void setupUi(QMainWindow *MainWindow)*
Variable Tracking Assignments is a compiler (GCC) option, oriented to enhance the debugger and optimization experience. If you are experiencing problems while debugging your program, then you may disable optimizations or disable this feature altogether (with the compiler flag '-fno-var-tracking-assignments'). There may be also a bug in your compiler version. If your compiler is too old, you may consider an upgrade. There is no limit for Qt widgets, though.
Related
Today I'm looking for some enlightenment of the deep magic inside the dynamic loader. I'm debugging/troubleshooting a plugin system for a C++ application running on Linux. It loads plugins via dlopen (RTLD_NOW | RTLS_LOCAL) and releases them using dlclose. Nothing extraordinary - one would think.
However, I noticed that some plugins remain loaded even after dlclose is successfully called*. I concluded this after looking at the running process' memory map using pmap. Some libs get immediately removed from process memory and others keep lingering around apparently indefinitely.
Continuing on, the dlopen man page states:
The function dlclose() decrements the reference count on the dynamic
library handle handle. If the reference count drops to zero and no
other loaded libraries use symbols in it, then the dynamic library is
unloaded.
That means the problem boils down to these two possibilities; Either the reference counts aren't zero, or other loaded libs are using symbols from some - but not all - of the plugins.
I'm pretty sure (although not 100%) that the reference counts are zero. The application's plugin manager handles all plugins exactly the same. It also makes sure that a plugin doesn't get loaded multiple times. IMO loading & unloading should therefore behave the same for all plugins.
That leaves the second possibility: other loaded libs are using symbols from the plugins. Another typical case of 'That should never happen'. Although it's certainly possible. We're using gcc and default visibility and as far as I've seen nothing is stripped, so tons of symbols are being exported. Actually that worries me much more as these plugins should be independent.
Here then are my open questions at this point:
Are my conclusions so far correct?
Do you know a way to verifydlopen's reference count?
If there are internal symbols of my plugins (accidentally) used by other libs, is there a way to track down who is using which symbols?
My machine is:
Linux 3.13.0-43-generic #72-Ubuntu SMP Mon Dec 8 19:35:44 UTC 2014 i686 i686 i686 GNU/Linux
* I should mention that all of the loading and unloading happens in the main thread, so there should be no multi threading issue here.
other loaded libs are using symbols from the plugins
If other libs are not linked to that shared library at link time, referring to symbols of a shared library does not prevent that shared library from being unloaded.
To debug the run-time linker set environment variable LD_DEBUG to all, e.g. LD_DEBUG=all ./my_app. See man ld.so for details.
In a huge C++ builder 2010 application with several DLL's being built and linked etc. What would be the best way to trace down memory leaks that accumulate over a long period of time? Say that the application has to be running for a week or something on the target machine before it becomes an issue. Let's assume that there is no profiling application available like AQ Time or something similar. Just using the standard IDE and perhaps some code.
My initial idea was to write a macro to use in all classes that keeps track of the number of instances and space used of each class type to start with.
The RTL uses FastMM as its memory manager. FastMM supports memory leak reporting and tracing. The native version of FastMM that is included in the RTL is a stripped down version, but it does support minimal leak reporting. You can set the RTL's global ReportMemoryLeaksOnShutdown variable to true at run-time and FastMM will generate a basic leak report when the app is closed. For more advanced usage, you can download the full version of FastMM and add it to your app, which will replace the RTL's native version. You can then configure FastMM as desired.
Some days ago I set up my computer and installed a new copy of Windows 8 because of some hardware changes. Among others I changed the video card from Radeon HD 7870 to Nvidia GTX 660.
After setting up Visual Studio 11 again, I downloaded my last OpenGL project from Github and rebuilt the whole project. I ran the application out of Visual Studio and it crashed because of nvoglv32.dll.
Unhandled exception at 0x5D9F74E3 (nvoglv32.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000000.
In the old environment the application worked as expected. I didn't changed anything of the project or source code. The only difference was the language of the Visual Studio installtion which is English now and was German before. Therefore I created a new project and adopted all settings, but the error remains.
In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements() which referrs to the gemoetry pass of my deferred renderer.
After some reseach I found out that nvoglv32.dll is from Nvidia and is about a services called Compatible OpenGL ICD. Does that somehow mean that my application runs in a compatible mode? That sounds like a mode to support older applications and I want mine to run in a regular mode! By the way I installed the lastest stable drivers for my video card.
To be honest, I have no clue how to approach fixing this crash. What could cause it and how to fix it?
Update: I found a post on Geforce Forums about my issue. Although there was no reply, the autor could fix the problem by changing the order of two OpenGL calls.
Hi all,
After poking around with my application source code for a few hours, I found that calling the functions...
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
glBindVertexArray(#)
...in that order causes the crash in nvoglv64.dll.
Reversing the order of these calls to...
glBindVertexArray(#)
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
...prevents the crash and appears to be well-behaved.
Cheers,
Robert Graf
Since I do not use vertex arrays I cannot simple do this fix but there might be a similar issue. I will report my progress.
Update: I have absolutely no clue how to solve my problem. I tried different video driver versions but it makes no difference. I completely rewrote the renderer using minimal shaders and simple forward rendering. But the crash sill occurs at the first draw call.
In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements().
Most likely you had a out-of-bounds access in your code all the time, but the AMD Radeon Catalyst drivers did reserve more address space, or caught them beforehand. And now your NVidia GeForce driver's don't.
Either you're passing glDrawElements a too large number for count elements to draw, or your index buffer contains values that index beyond the range of your vertex arrays. If it's the later, then you're probably using client side vertex arrays, as VBOs usually catch out-of-bounds accesses; also those wouldn't crash your client side program, but just render garbage.
Finally I came up with a solution to fix the crash.
The SFML framework I use to create the window and more provides a function to reset the OpenGL state of the context. I called it right after window creation.
Even though I can't explain why, removing that function call solved the crash. Maybe it is because GLEW or something else isn't yet initialized that moment.
sf::RenderWindow window;
window.create(VideoMode(1024, 768), "Window Title");
window.resetGLStates(); // removing this line fixed the crash
window.setVerticalSyncEnabled(true);
I notice that the IsDirect() method which should say whether hardware rendering is on returns false on my vtkRenderWindow*, link to class doc:
http://www.vtk.org/doc/nightly/html/classvtkRenderWindow.html
How do I enable it? Seems like a build option in cmake should do it, but what? My OpenGL libs are found OK. I notice there's a thread from a while back here: http://www.vtk.org/pipermail/vtkusers/2005-July/081034.html but I don't see any more recent info so far, is it just not supported on Linux?
First of all, I doubt it is a cmake option to enable direct HW rendering.
Applications are falling back to the software rending when the hardware rendering is not possible (GPU doesn't support some of the picked options).
Without seeing some code and getting details (which GPU), it is not possible to give a better answer.
I have read in other discussions that Release dlls have reduced size compared to Debug dlls. But why is it that the size of the dll I have made is the other way around: the Release dll is bigger than the Debug dll. Will it cause problems?
It won't cause problems, its probably that the compiler is 'inlining' more items in the release build and creating larger code. It all depends on the code itself.
Nothing to worry about.
EDIT:
If you are really worried about and not worried about speed you can turn on optimize for size. Or turn off auto inlining and see what difference you get.
EDIT:
More info, you can use dumpbin /headers to see where the dll gets larger
How much bigger is your Release DLL than your Debug DLL?
Your Debug DLLs might seem small is you are generating PDB symbol files (so the debug symbol is not actually in the DLL file). Or if you are inadvertently compiling debug symbols into your Release DLL.
This can be caused by performance optimizations like loop unrolling - if it's significantly different, check your Release linker settings to make sure that you're not statically compiling anything in.
The performance can be influenced if your application perform tasks of high performance. A release version can even be larger than a debug version, if marked options to generate code with information on Debug included. But this also depends on the compiler you are using.