I'm instantiating QSystemDeviceInfo on a worker thread, but it causes a segfault.
int BatteryInfo::getLevel() {
QSystemDeviceInfo sysDevInfo; //segfault happens when I step on to this line
return sysDevInfo.batteryLevel();
}
Is the class thread-safe, or does the problem lie elsewhere?
EDIT: With further debugging I also noticed that native Symbian calls segfault as well.
Best regards
Me and my friend found this issue as well on Symbian Qt Mobilty 1.0. He reported an issue QtMobility access from multiple threads. As it says in the issue description Think this could be due to that some static members are created first time the QSystemDeviceInfo/QSystemNetworkInfo is created..
If you are using Qt Mobility 1.2 or only accessing QSystemDeviceInfo from one thread it's some other issue.
EDIT: One workaround for us was to make sure we created a QSystemDeviceInfo object in our main thread first but then we had some problems with not getting all signals.
Do you have capabilities set ?
QSystemDeviceInfo needs the 'ReadDeviceData' capability.You will need to sign your app to install on the device if you include this capability.
Related
I got error when execute code. I think it's not related to code. something is missing.
java.lang.IllegalStateException: Problem in some module which uses Window System: Window System API is required to be called from AWT thread only, see http://core.netbeans.org/proposals/threading/
You have flagged your post with JavaFX, so I assume you are talking about a JavaFX application. Every GUI update in the JavaFX-world is done on the JavaFX application thread. Your exception however indicates that you are using some AWT code in your program which has a different requirement. It must be run on AWT thread. So, the first thing you have to do is find out what this code is and then you have to make sure to call it on the right thread. You can use Platform.runLater() to put something on the JavaFX thread and SwingUtilities.invokeLater() to put something on the AWT thread.
Qt 5.8 was supposed to come with the optional use ahead of time qtquick compiler, instead it arrived with a sort-of-a-jit-compiler, a feature that's enabled by default and caches compiled QML files on disk in order to improve startup performance and reduce memory usage.
The feature however arrives with serious bugs which greatly diminish, or in my case even completely negate its benefits, as I didn't have a problem with startup times to begin with, and testing didn't reveal any memory usage improvements whatsoever.
So what I would like to do is opt out of that feature in my project, but I don't seem to find how to do that. Going back to Qt 5.7.1 is not an option since my project relies on other new features, introduced with 5.8.
Add QML_DISABLE_DISK_CACHE (set to 1) to your environment variables. You should be able to do it inside your application via qputenv -- put it somewhere in main before loading QML content.
Credit to peppe for informing us of the environment variable, but qputenv()only takes a QByteArray as the value parameter, so 1 won't work.
The two options that work:
qputenv("QML_DISABLE_DISK_CACHE", "1"); // or
qputenv("QML_DISABLE_DISK_CACHE", "true");
This successful disables the cache and prevents the associated bugs from manifesting.
I am working on a project recently migrated to Qt 5.3.0 (previously it was running on Qt 5.2.1).
My project is based on a QQuickView object being filled with some QML files, depending on some command I receive from a communication protocol...
Since I was on Qt 5.2.1 the system worked fine and was rock solid: never a problem. Now with Qt 5.3.0 if I close the QQuickView window the process crashes with the following output:
** glibc detected ** /home/morix/devel/aesys/VLED/build/bin/VLED: free(): invalid pointer: 0x091ec694 **
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb5c1fee2]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xb5e1b51f]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN21QQmlImageProviderBaseD0Ev+0x24)[0xb7136110]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(+0x211f59)[0xb713cf59]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(+0x2138b3)[0xb713e8b3]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN9QHashData11free_helperEPFvPNS_4NodeEE+0x4a)[0xb5f40e7a]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN17QQmlEnginePrivateD1Ev+0x8ab)[0xb71378c5]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN17QQmlEnginePrivateD0Ev+0x1c)[0xb7137a7c]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN7QObjectD1Ev+0x6a1)[0xb6173031]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN9QJSEngineD1Ev+0x36)[0xb70352b6]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN10QQmlEngineD1Ev+0xf0)[0xb71398fe]
/opt/Qt/5.3/gcc/lib/libQt5Qml.so.5(_ZN10QQmlEngineD0Ev+0x1c)[0xb71399e2]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN14QObjectPrivate14deleteChildrenEv+0x6c)[0xb616e4ac]
/opt/Qt/5.3/gcc/lib/libQt5Core.so.5(_ZN7QObjectD1Ev+0x661)[0xb6172ff1]
/opt/Qt/5.3/gcc/lib/libQt5Gui.so.5(_ZN7QWindowD2Ev+0x6d)[0xb646a7bd]
/opt/Qt/5.3/gcc/lib/libQt5Quick.so.5(_ZN12QQuickWindowD1Ev+0xd9)[0xb74878e9]
/opt/Qt/5.3/gcc/lib/libQt5Quick.so.5(_ZN10QQuickViewD1Ev+0x9a)[0xb753925a]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x8059bbe]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x8059c8f]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x8051368]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x804d429]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb5bc34d3]
/home/morix/devel/aesys/VLED/build/bin/VLED[0x804d2b1]
(VLED is the name of my project in the output here above).
It seems that some free() call in QQmlImageProviderBase is working on a unvalid pointer...
Please consider that in my project I make use of a QQmlImageProviderBase-derived class to provide some "live" pixmaps to QML... but I don't think the problem is there: the code is very simple (simply returns some pixmaps previously inserted in a local collection) and furthermore with Qt 5.2.1 it works fine...
I am working on Ubuntu Linux 12.04 LTS... but the problem is the same if I cross-compile the application for BeagleBone Black / TI AM335x... so it seems not to be an "environment-related" problem but rather a Qt problem...
Does somebody else is experiencing such a problem with Qt 5.3.0? Any workaround?
UPDATE
I created a very simply project for reproducing the issue: it can be found here here.
Please try it on your own and let me know if you have the same issue and if you find a valid workaround…
Ok, I posted the question on Qt bug tracker and here is the answer: the QQmlImageProviderBase-derived object must be allocated on the heap because the QQmlEngine takes the ownership of it when it is added to the view... If it is allocated on the stack the object is going to be deleted twice (once by QQmlEngine and once when the stack is popped)...
Allocating it on the heap (as suggested) and letting QQmlEngine to delete it on its own fixes the problem.
I have a Qt Application that works in Debug mode without any problems. Since two days I'm trying to make it work in Release mode. After some Project property modification I managed to compile without errors. But unfortunalty the application crashes before even reaching the main method.
That's my environment:
MS VS 2010
Qt 4.8.4
Qwt 6.0.0
I don't know if this is relevant, but I also installed the Qt plugin for VS and used Qt Designer to create my GUI.
As I said in Debug mode there is no problem. Starting the release version from the Visual Studio produces the following error:
Unhandled exception at 0x77c415de in Application.exe: 0xC0000005: Access violation reading location 0x0000000c.
The last function I can "debug" is the the "WinMain" method called inside the method "__declspec(noinline) int __tmainCRTStartup", which is located in crtexe.c (honestly I have no idea what this is). The call stack looks like this:
ntdll.dll!77c415de()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
ntdll.dll!77c415de()
ntdll.dll!77c3014e()
msvcr100.dll!718f0269()
msvcr100.dll!718f233b()
msvcr100.dll!718f233b()
msvcr100.dll!718f233b()
QtCore4.dll!5b2cfc49()
QtGui4.dll!57bf54ea()
Application.exe!__tmainCRTStartup() Line 547 + 0x1c bytes C
kernel32.dll!754633aa()
ntdll.dll!77c59ef2()
ntdll.dll!77c59ec5()
In the moment I'm totaly lost with this problem. No idea what to try further...
I've tried to reduce the program and commented out the complete main function. But the result was the same behaviour. As I said the error occurs even before the main function is called. I also turned off all optimization and recompiled... didn't changed anything.
What completly puzzles me, is the fact that it "works" when I call "Application.exe" from the command prompt (ok it also crashes but much later during execution). Weird, isn't it? What is the difference between starting from command prompt and starting from Visual Studio application?
AnatolyS and npiau thanks for you tips. Meanwhile I continued digging in my code. More or less I started from the very beginning and finally got the place the error occurs. I suppose npiau is right, it has nothing to do with Qt.
It's still (for me) a strange problem. I posted it in a new thread (because it has little to do with this thread): C++ Creation of a Singleton object in initializer list causes an Access Violation (only Release Mode)
The problem is not in QT but in your source code. "0xC0000005: Access violation reading location 0x0000000c" means that you try to access a wrong memory location.
Check out your arrays, ans pointers.
I need to make so that my application can have only one instance running at a time. Also when it's launched with a command line parameter ( like when registered to open certain file types ) it should pass the parameter to an existing instance and quit immediately without displaying graphical interface. You all probably know what I mean. The framework used is Qt 4, and it seems like it must have some facilities for that. Any ideas?
There is a Qt Solutions project doing this:
Qt Single Application
There are several ways to do inter process communication. Examples can be found in Qt's examples section.
It's also possible to implement a this sort of class oneself using QSharedMemory
(see QSharedMemory::attach() ). It's capable of being used for both determining whether other instance is already running and communicating/sending messages. Except some pointer magic and memory copying it's quite straightforward.