Re: [Interest] QTextStream problem
On Tuesday 30 July 2024 08:30:27 GMT-7 Turtle Creek Software wrote: > We ran into a weird error with QTextStream. When using it to read a text > file, it removes all the line endings. That happens with readAll, read and > readLine. > > Getting a QString direct from a QFile via readAll works properly. > > Is this expected behavior in QTextStream? It's not documented anywhere. No, it's not. Looking at the code, it looks like it implements the translation from CRLF to newlines by simple removal of the CR. It doesn't check that it's followed by an LF. Is your text file using CRs alone for line breaks? -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Will TSAN_OPTIONS=detect_deadlocks=1 work when Qt is compiled with -sanitize thread?
On Friday 19 July 2024 10:00:44 GMT-7 Nuno Santos via Interest wrote: > Taking this into account. Do you think this could be a bug on Qt? I have no clue. I don't know the code in question to be able to make a guess based on the information you've provided. Someone who does may be able to. Short of that, we'll need a reproducer. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Will TSAN_OPTIONS=detect_deadlocks=1 work when Qt is compiled with -sanitize thread?
On Friday 19 July 2024 07:15:19 GMT-7 Nuno Santos via Interest wrote: > (lldb) bt all > * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP > * frame #0: 0x0001db7aa1cc libsystem_kernel.dylib`__psynch_cvwait + 8 > frame #1: 0x0001ef5096e4 libsystem_pthread.dylib`_pthread_cond_wait > + 1228 > frame #2: 0x000103e04bc4 > BAM`QWaitConditionPrivate::wait(QDeadlineTimer) + 64 frame #3: > 0x000103e04b18 BAM`QWaitCondition::wait(QMutex*, QDeadlineTimer) + 148 > frame #4: 0x00010313a960 > BAM`QSGThreadedRenderLoop::polishAndSync(QSGThreadedRenderLoop::Window*, > bool) + 1544 > frame #5: 0x00010313ae38 > BAM`QSGThreadedRenderLoop::handleUpdateRequest(QQuickWindow*) + 364 This is one of the frozen threads. It's inside the Scene Graph waiting on a QWaitCondition for an event notification. The question is what its partner thread, the one that is supposed to notify on this WC but isn't doing so? The only one running SG code is thread 26: > thread #26, name = 'QSGRenderThread' > frame #0: 0x000103567f40 > BAM`QRhiMetal::enqueueResourceUpdates(QRhiCommandBuffer*, > QRhiResourceUpdateBatch*) + 948 > frame #1: 0x000103007724 > BAM`QSGBatchRenderer::Renderer::prepareRenderPass(QSGBatchRenderer::Ren > derer::RenderPassContext*) + 2264 > frame #2: 0x000103006dcc > BAM`QSGBatchRenderer::Renderer::render() + 36 > frame #3: > 0x00010301bb70 BAM`QSGRenderer::renderScene() + 344 But this thread isn't frozen: it's not stopped at a system call. If this is the thread that should have notified the WC, why didn't it? Or why hasn't it got to the notification yet (that would be a livelock, not a deadlock)? Or has it notified by the other thread didn't get it? Either way, I think you've found a Qt bug. Please test with 6.7 or 6.8 betas, and report it with the updated backtrace. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Will TSAN_OPTIONS=detect_deadlocks=1 work when Qt is compiled with -sanitize thread?
On Friday 19 July 2024 03:30:40 GMT-7 Nuno Santos via Interest wrote: > That’s the biggest problem. It happens s RARELY. > > We can’t find a sistematic way of reproducing it. That is why I was trying > to find a more analytical way of detecting it. You don't need that. Can you reproduce the problem *at all*? If you can, then simply get the stack trace of all threads when the problem happens. You'll see at least two threads stalled and waiting for each other (not in an event loop). -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Will TSAN_OPTIONS=detect_deadlocks=1 work when Qt is compiled with -sanitize thread?
On Thursday 18 July 2024 09:11:36 GMT-7 coroberti wrote: > dtruss is available on Mac > https://stackoverflow.com/questions/31045575/how-to-trace-system-calls-of-a-> > program-in-mac-os-x It doesn't work properly, unless you disable System Integrity Protection. Even if you do, it's a poor implementation compared to even FreeBSD's equivalent (truss). If you need to trace system calls on macOS, my recommendation is to trace on Linux or FreeBSD first. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Error when configuring Qt 6.X.Y to build from source on Windows with -openssl-linked
On Wednesday 26 June 2024 08:17:51 GMT-7 Alexandru Croitor via Interest wrote: > Regarding compiling a project from the examples, the build system does not > 'remember' which openssl was used when building qt, so you have to set the > OPENSSL_ROOT_DIR variable also when configuring the project, either via IDE > kit settings, or on the command line. What example needs to know that in the first place? Examples should use the QtNetwork API and that completely hides which TLS backend is in use. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Platform & System Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on Exceptions
On Saturday 25 May 2024 09:51:49 GMT-3 Jean-Michaël Celerier wrote: > Likely there are "bad things" that could theoretically happen but in 10 > years of https://ossia.io across Mac, Windows, Linux and tens of thousands > of exceptions being caught after unwinding through the Qt and QWidget event > handling due to fairly defensive programming strategies (assertions > everywhere being transformed into exceptions in release builds), I have yet > to see *one* of these mysterious corruptions mentioned here. > > The time saved by my users who can however just resume using the software > after a small error popup is immense. Hello Jean-Michaël Do you have experience of this working on ARM Macs? That's the issue that Dennis is having: by default, the compiler there doesn't generate unwind information if exceptions are disabled, unlike on x86. So the big question I asked: does the same apply to the Apple libraries themselves? -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] More on Exceptions
On Saturday 25 May 2024 09:27:54 GMT-3 Turtle Creek Software wrote: > Thiago, I'll describe what happens when our typical exception is thrown, > since conditions are very different from what you describe. > > Before any method uses a pointer, it first does a sanity check. If nullptr > it shows a dialog with file/line number and what failed, then throws an > exception to avoid crashing. There are 7000+ checks, plus another 1000+ > assertions for other bad states. 99% will never be called. Some throws are > caught internally but most go out to the event loop, which has a try/catch > block. What is a user going to do with that information? This is my case of "clicking a button causes std::runtime_exception" - no, this is a UX bug. The user can't affect the result and will confuse the user. You should design your software so this condition will not happen and, in the unexpected case where it does happen, you need to handle it without user interaction. > The app has a couple megabytes of just file/line number text, since it > needs to be compiled in. The original plan was to remove them in release > build, but they help for user bug reports so they're permanent. Users tell > us exactly where to find the problem. You don't need the UI for this. More importantly, you *cannot* trust the process itself to display UI because, by construction, you've run into an unexpected condition because some internal invariant was violated. If you want to display any sort of UI, it needs to be out-of-process. > In practice, 99% of throws are from something trivial/stupid- a missing > field, or a link to something that doesn't need to be linked. They are > caught in the event loop and users can safely continue working. In rare > cases they may see a ton of weird messages and need to force-quit. Then just catch before returning to the event loop, eat the exception, and continue. You don't need to display a dialogue asking the user if they want to continue: they always do. My advice is you do no such thing. If you've run into an unexpected condition, continuing is just going to accumulate errors, postponing the crash until finding out what caused the initial problem is nearly impossible. > As the stack unwinds after a throw, in theory it should tidy everything via > scope endings and destructors. In practice, maybe there are leaks or other > bugs along the way. But in theory, those bugs would show up anyhow when the > stack unwinds from normal use. In practice, the setup has worked well for > 20+ years. Users see helpful error messages rather than crashes. Maybe the > exception throws cause subtle, unknown problems but no worse than the usual > problems in any app. In theory, there are no bugs. In practice, there are. > I think Qt should enable exceptions in QWidget etc by default, strengthen > the disclaimer a bit, and feel no obligation to survive throws in perfect > condition. Pass them along and let developers deal with the consequences. > Exceptions should be for weird problems, and if things get weirder, so > what? Based on our experience in x86 it probably will be just fine. As I said before in the dev mailing list: this is pending someone checking that the Cocoa and Win32 and glib frames that may be in the call stack can be unwound too. If they can't, then the exception unwind info in QtWidgets is dead weight. Even if someone shows they work, we may not do it in the official builds. But you can do it yourself. In fact, since you do have such a good infrastructure for testing whether it works, I recommend you just do it and tell us if it works. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Exceptions
On Friday 24 May 2024 13:25:37 GMT-3 Turtle Creek Software wrote: > >> Install a terminate handler instead. > > Is there some way to get from there back to the event loop? No and you don't want to. The moment you let the exception escape back to the Qt event loop, YOU MUST QUIT. So it doesn't matter where you quit it from, so long as you do so right now. Doing so from the terminate handler means you have a much better chance of having a valid state of everything you need to log stuff and save any files that you can still try to. Trying to go through the exception-unsafe code in Qt and, worse, the third party and system libraries, is a worse outcome. The application may crash before that, with a second exception being thrown, or just plain crash. > If so, that > would solve our problem. If not, there's nothing we can do safely in a > handler. Doing a database commit would cause worse chaos if there are > unfinished records. It needs GUI code to check that. I understand, but it's too late. My point is that you've let an untestable and unexpected condition happen, so you should not trust the GUI. You may want to try and save the state of what you would commit to the database, terminate the application and restart it. The newly-started process can inspect the saved state and decide how to continue, possibly offering the user the chance to decide to keep or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Undefined symbols when porting from Qt5 to Qt6
On Thursday 23 May 2024 19:06:59 GMT-3 Corentin Bacqué-cazenave via Interest wrote: > So I probably have to link LibX11 in CmakeList.txt, not sure how however > > Thanks for the help https://cmake.org/cmake/help/latest/module/FindX11.html -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Undefined symbols when porting from Qt5 to Qt6
On Thursday 23 May 2024 18:14:01 GMT-3 Corentin Bacqué-cazenave via Interest wrote: > Hi, > > I'm trying to port an application from Qt5 to Qt6. > > I get a lot of errors regarding undefined symbols reference like > XUngrabKey, XFree, XStringToKeysym, XFlush... > > All symbols related to X11 seam to be missing. > > Does anyone have an idea? Hello Corentin Where are those symbols being used? Is it from your application or is it from some Qt code? If it's from your application, then you probably forgot to link to the X11 library. Something in the buildsystem changed and your indirect dependency is not there any more. Qt5's GUI libraries, unlike Qt 4 and Qt 6, did not link to libX11. Qt 4 did because it did not have the feature as a plugin; Qt 6 has to do it because of OpenGL. But because of this, I wouldn't expect to see this problem at all: libX11 is in use. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Exceptions
On Thursday 23 May 2024 11:57:39 GMT-3 Turtle Creek Software wrote: > *Qt 6.7 > Best Practice Guides > Exception Safety* as currently written > seems very reasonable. We'd much rather see that extended to ARM rather > than abandoned. That is pending an investigation on whether the frames provided by Apple frameworks support unwinding. If they don't, then there's nothing we can do and you can argue with Apple. > This link states that ARM fully supports C++ exception handling: > https://developer.arm.com/documentation/dui0491/i/C-and-C---Implementation-D > etails/C---exception-handling That's irrelevant for Objective C, which is what Apple writes their code in. > If the problem is with Apple/Cocoa/SwiftUI, would a throw just skip their > code in the stack unwind? That might cause unknown errors, but would still > be better than fast termination. No, it makes unwinding impossible. You can't unwind a frame if you don't know how to unwind it. The only possibility is to std::terminate(). > In a GUI app, there's always a tall pile of QWidgetry on the stack. > Catching rare errors before it means extra code that will never be used. > More time and clutter. Throws to the event loop are such an elegant > solution. Install a terminate handler instead. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Fleet Engineering and Quality smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Tuesday 7 May 2024 00:26:41 GMT-7 NIkolai Marchenko wrote: > That sounds more unhinged than loading a dummy if metaobject is empty with > createObject in c++ It sounds like discussing two different workarounds for a bug that has been fixed. Workarounds are seldom clean. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Monday 6 May 2024 04:24:50 GMT-7 Ulf Hermann via Interest wrote: > > That's poor programming practice. > > No. I meant that attempting to search for a metatype by name, of a class that may or may not be registered, which itself is a private class. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 16:44:01 GMT-7 NIkolai Marchenko wrote: > https://i.postimg.cc/DZbz9F1Z/image.png > > I don't think it's getting installed anywhere by default in version 5.x.x, > at Ieast I don't see anything like that in all of my qt installations on > this machine. Must be 6.x.x only Sorry, I only looked at Qt 6. According to the Git log history, in Qt 5, this class was part of a plugin. So you can't link to it. Time to consider upgrading? -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 12:12:33 GMT-7 NIkolai Marchenko wrote: > I asked in qbs support channel and they told me that this should only work > in qt6 onwards. but not 5.15 The headers are installed, so you can just: #include -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 10:32:45 GMT-7 NIkolai Marchenko wrote:
> I don't think I can directly reference it in qbs unless I am missing
> something. trying to
> Depends { name: "Qt"; submodules: ["quicklayouts"] }
> just doesn't work, same for "layouts", as such, I also can't import its
> private parts
With qmake:
QT += quicklayouts-private
With CMake, use target Qt6::QuickLayoutsPrivate
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 10:21:22 GMT-7 NIkolai Marchenko wrote: > because importing quick-private doesn't bring > qtdeclarative/src/quicklayouts/qquicklayout_p.h into visibility and I don't > know what am I supposed to import to do so Sorry, it's QtQuickLayouts/private/qquicklayout_p.h. It's a separate library from QtQuick. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 08:51:39 GMT-7 NIkolai Marchenko wrote:
> QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*"));
Why don't you include and get the meta
object directly?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 09:58:45 GMT-7 NIkolai Marchenko wrote: > That's what the test I am trying to fix is for in the first place, yes. But > like I said, it looks like I can just force the registration in place if > it's not done yet and then rely on it being available You should still test before your release, because the internals of QtQuick may change. This class may disappear completely, for example. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 09:24:18 GMT-7 NIkolai Marchenko wrote: > I just need to understand how to properly set up test environment for it. You're relying on internal behaviour. That means you should simply verify that your assumption worked, before any release of yours with the specific Qt version that you're compiling with. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] what are the requirements for QMetaType::metaObjectForType(QMetaType::type("QQuickLayout*")) to work?
On Friday 3 May 2024 08:51:39 GMT-7 NIkolai Marchenko wrote: > I am assuming the registration of qquicklayout is deferred somewhere > but what are the exact timings and conditions? There's no explicit registration of this type, anywhere in the sources. I don't even see anything that would be an automatic registration; maybe it gets put into a QVariant somewhere that my git grep didn't see. But one of the unit tests assumes it exists, like your code does: https://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qml/ qmlcppcodegen/tst_qmlcppcodegen.cpp#n1646 That means it's relying on some automatic registration somewhere, somehow. That's poor programming practice. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Exception catching in event loop
On Wednesday 1 May 2024 14:54:48 GMT-7 Turtle Creek Software wrote: > To do that in Qt we wrap QApplication::notify in a try/catch. It works No, it doesn't work. It happens to work on those platforms by pure accident. Trying to catch in notify() is too late. Catch those things before they reenter Qt code. Especially Qt code that was compiled with exceptions disabled, like QtWidgets. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] App release
On Wednesday, 20 March 2024 17:27:26 PDT Turtle Creek Software wrote: > We are ready to release a free alpha version of our accounting app for Mac > & Windows. The plan is to use LGPL while still in beta, then switch to a > commercial license and static Qt when it's ready to sell. > > Will the switch cause licensing problems? The LGPL will not cause you legal problems. But you must remember that the licence you gave to those recipients is irrevocable: they can continue using it, distributing it and even developing it after you've made your production release. You may want to think more about your business case here, because some potential paying customers may decide they don't want to pay you if a nearly as good version is open source. You should also check with Qt Company sales what terms they'll sell you a licence under. In the past, they usually required that you retroactively buy for the time you spent developing the application. > How do people usually distribute QT for dynamic linking? Our users/testers > are not very tech savvy. For Mac, it's easy: use macdeployqt and everything is inside your application's bundle. For Windows, you'll need to make an installer to deploy your .exe and all the Qt libraries and plugins. windeployqt can prepare the installation target, but the installer itself is up to you. You can use the Qt Installer Framework if you wish, or something else. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt6 build on Raspi
On Friday, 8 March 2024 00:20:24 PST Frank Mertens wrote: > I usually do not build on the Raspberry directly. Modern compilers take ever > more memory. Another problem might be parallelism of the optimizing link > stage. Checkout CMAKE_JOB_POOL_LINK and CMAKE_JOB_POOK_COMPILE. > You probably have to limit both to not run out of memory. That's just going to fail the build if the compilers can't get enough memory. Alexander says he tried to build with -j1 and that still got the system to freeze. Alexander: add more RAM or build on a system with sufficient RAM. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6.5.4-LTS from source -> fatal: Unable to find current revision in submodule path 'qt5compat'
On Thursday, 8 February 2024 13:28:10 PST Nuno Santos via Interest wrote: > One question. I’m not interested in all the modules. Just some of them. If I > do that I will unit all the modules and therefore the build will contain > them all right? Correct. You can do "git submodule init" for each of the modules you want. Alternatively, you can clone and build just the modules you want. You don't need the top-level dir. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6.5.4-LTS from source -> fatal: Unable to find current revision in submodule path 'qt5compat'
On Thursday, 8 February 2024 09:19:12 PST Nuno Santos via Interest wrote: > Thanks for your reply. > > From the repository, the lts one. I don't know what's wrong then. I don't use the init-repository script. Just use "git submodule update --recursive --init" and be done with it. You don't need the extra features of the init-repository script because you're not going to use this repository to contribute to Qt (no need for the post-commit hook and for the Git remotes to push to Gerrit). -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6.5.4-LTS from source -> fatal: Unable to find current revision in submodule path 'qt5compat'
On Tuesday, 6 February 2024 07:02:11 PST Nuno Santos via Interest wrote: > While trying to build Qt 6 from source I’m having this error while > initialising the necessary modulates with the following line: To be clear: when you say "from source", do you mean from the tarball or from the Git repository? If you're building from the tarball, then you do not have a Git repository, so you shouldn't run init-repository. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] displaying Qt-coded JPEG image in browser
On Friday, 26 January 2024 04:55:59 PST Alexander Carôt via Interest wrote: > QString jpgBufferString( finalJpg.data() ); This here will corrupt the data, because you can't load arbitrary binary data into QString like this: it's trying to decode as UTF-8 and failing. > QString encodedString = jpgBufferString.toUtf8().toBase64(); You should encode to Base64 at the QByteArray level first, before going to QString. So: QString encodedString = QString::fromLatin1(finalJpg.toBase64()); -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Get intermediate data during http get
On Friday, 19 January 2024 06:34:37 PST Christophe Thomas wrote: > Using a tcp socket I noticed that I have first readyread that passes me the > http header from the first packet and then waits the end of the tcp flow to > gives me the full body/data part. When modifify the socket read buffer size > it is only modifying the available data between readyread. > > I'm still not sure if this is due to windows network stack or is it > related to Qt. QTcpSocket will emit readyRead() every time that the OS wakes it up with more data. That may not happen for every single packet; that's the OS's choice. But the OSes don't usually wait long after receiving TCP packets and processing them to wake the application up. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Can a signal/slot connection still exist after the receiver is destroyed?
On Friday, 5 January 2024 12:56:03 -03 Alexander Dyagilev wrote: > Hello, > > Let's suppose we have an object A with slot AA living in thread AAA. > > Let's suppose we have an object B with signal BB living in thread BBB. > > Let's suppose we've created a direct signal/slot connection from BB to AA. > > Question: is it possible that BB can call AA after it was destroyed? I mean > race condition bug (we have 2 threads). I.e. is connection 100% always > destroyed before A is destroyed? The connection is, but the answer is more complicated than that. The signal-slot connection mechanism is thread-safe. You can connect and disconnect signals to slots while emitting them. Because the signal activation mechanism locks the receiver's connection list, it will either find the connection intact or it will find the connection torn down. So if you race connections and disconnections with emissions, you will find that some slots may be called or not, depending on timing. This is the answer to the question asked above, but not what you wanted to know. This protection offers a modicum of protection against deletion too, but that is not guaranteed. So my recommendation is that you invest in a mutex and stop reading this reply. This lock does apply in QObject's destructor, so again there's a synchronisation between the emission in thread BBV and the deletion in thread AAA. If the connection were Auto or QueuedConnection, that would result in an event being posted to the object, which would either be delivered *before* the deletion began or would be discarded by the deletion so no delivery happens. This means with Auto or QueuedConnections, you can't really race the deletion. > Well, it seems I just understood. BBB see the connection and starts calling > AA. Then, CPU switch occurs. Thread BBB suspended and AAA resuming. AAA > destroys A. Then BBB resuming and continues to call AA. And we get a crash. > Am I right here? In the case of DirectConnection, no such protection occurs because QObject must drop the locks before invoking your slot. It's the same as your getting the pointer address for AA from somewhere else and directly calling it. YOU must ensure that the object stays alive until your signal emission has finished. That's a mutex. Just so we're clear, there's also the case of the deletion happening while the execution is happening, with no context switches. It's possible the signal activation code blocked the QObject destructor from proceeding... but at that point, object AA is no longer of type A, but of type QObject. This is already wrong. That means you must prevent object BB from starting its deletion in the first place, not from completing it. That is, a mutex inside the object is usually wrong: it must be outside. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Yocto is application or device creation license???
On Thursday, 14 December 2023 16:13:37 -03 Jérôme Godbout via Interest wrote: > Can I use the Yocto Layers and Recipes in a build using BitBake (YP's build > tool) to make a commercial application using the Application Development > license? > > That’s my true question, is application development license allowed into > that context or are we force to use the device creation license. I think you or I are getting mixed on details. Yocto Project, recipes, layers, and BitBake are just tools to accomplish the build of your device. YP licences won't apply at the end. Only the cumulative licence of all the software that you selected (by way of the layers) does and the YP tools will create the BOM for you to analyse. This is where this licence you're referring to comes into play. So it doesn't matter how you built and deployed your Qt Commercial onto the device, only that you did. Does that licence allow you to ship your device? Does it require payment of per-unit royalties? Does it put extra requirements on what you can or can't do? I can't answer that, since I don't know the terms. You should get your legal department to make a decision. Qt Company's opinion is an input, not a conclusion. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Yocto is application or device creation license???
On Thursday, 14 December 2023 14:00:32 -03 Jérôme Godbout via Interest wrote: > Can the commercial Application be used with a Yocto build into a custom arm > device? Your question is actually: Can I use the Yocto Layers and Recipes in a build using BitBake (YP's build tool) to make a commercial device? Yes. Can I use the meta-qt6 layer to build a commercial Qt? Tuukka's answer says yes. BitBake will produce a BOM for you with a list of licences and your obligations. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why does the QtLogging message not include type (e.g. WARNING)?
On Sunday, 10 December 2023 09:47:22 PST Thomas Larsen Wessel wrote: > I'm actually grateful that the original message is so concise, otherwise I > > > wouldn't look for a way to customise it > > I never considered that. If the goal is to make application developers > unsatisfied, such that they will look for how to customize the format, then > I suggest leaving out the message too ;) :) The fact that it has historically been JUST the message has made people use qDebug to create formatted output, instead of using stdio or iostreams. I disagree with doing that: that's not the purpose of QDebug. But it does exist, so changing the default will cause some irritation. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why does the QtLogging message not include type (e.g. WARNING)?
On Sunday, 10 December 2023 05:03:53 PST Thomas Larsen Wessel wrote: > Is there a good reason why the severity is left out of the default format? Behaviour-compatibility with older versions. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CMake problems with WASM
On Tuesday, 21 November 2023 08:43:20 PST DAS Loop wrote: > Yes Thiago, CMAKE_TOOLCHAIN_FILE is the way but vcpkg is doing the same. Either vcpkg knows about building for WASM or it doesn't. If it does, then its toolchain file is the one you want and it will produce WASM content. If it doesn't, then its toolchain file is wrong and mustn't be used. Most likely, that means vcpkg can't be used for this cross-compilation in the first place. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CMake problems with WASM
On Tuesday, 21 November 2023 06:04:36 PST DAS Loop wrote: > The app is compiled for wasm as expected. > > > Because I´m using vcpkg, using CMAKE_TOOLCHAIN_FILE is not a solution for > me. > > > Any idea of what is wrong? If you're cross-compiling, you MUST use CMAKE_TOOLCHAIN_FILE. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QJsonObject memory leak?
On Thursday, 2 November 2023 15:37:39 PDT Nuno Santos wrote: > I have sent an example project to this list, you will see it has nothing > besides that. > > Two buttons, two functions. > > I would love to understand how to properly deal with this in a simple case > so I can better handle it on the real use case that triggered this doubt. I replied before you sent the test. My hypothesis remains unconfirmed. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QJsonObject memory leak?
On Thursday, 2 November 2023 11:54:25 PDT Nuno Santos wrote: > Thiago, > > So, there is no way of recovering that memory back until the process is > closed? No, you can free the memory that caused the fragmenting. It's probably whatever happened between the two functions that you talked about. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QJsonObject memory leak?
On Thursday, 2 November 2023 08:51:43 PDT Nuno Santos wrote: > Any ideas of what is happening here? It's probably memory fragmentation. The JSON and CBOR classes store the strings of a container in a large QString, per container level. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QFileSystemWatcher: Timing of file changed signal.
On Tuesday, 10 October 2023 08:17:44 PDT Michael Jackson wrote: > I get that this probably completely depends on the operating system being > used. I am not really familiar at that low a level how filesystems work > (like NTFS, APFS and others) so I can't figure out what would happen. Correct, it depends on OS and FS. Test with yours and find out when it gets sent. Probably, multiple times during while you're writing. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Local QRegularExpression variables
On Sunday, 24 September 2023 18:34:02 PDT NIkolai Marchenko wrote: > Clang has warnings about using local regular expression objects and > recommends creating them statically, but seemingly only when the pattern > isn't QStringLiteral. Is it an oversight in clang's detection system or > stringliteral'd regular expressions are so much cheaper that it doesn't > deserve a warning? The expense is in QRegularExpression, so it doesn't matter where the pattern came from. That's a limitation in the detection system then. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] running pyqt app event loop in secondary thread, using (Py)Qt6.5
On Friday, 22 September 2023 15:48:53 PDT Stefan Seefeld wrote: > I'm not sure what "at the same time" means. At least in my sample code, I'm > really calling the `quit()` function from a different thread (while the > event loop is still running, of course), and am only destroying the > application after the `exec()` function has completed. Then stop guessing. Get the backtrace of those messages, by setting QT_FATAL_WARNINGS=1 and inspecting the core dump, or by running the entire thing inside the debugger. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How does using `-platform offscreen` affect network communication?
On Friday, 8 September 2023 05:06:15 PDT Siddh Raman Pant wrote: > Hi, > What could be the reason it is not connecting offscreen? How does > using offscreen platform affect network communication? It does not. You'll need to debug the application to find out a) is it attempting to connect b) is the server listening in the address you've tried to connect to c) is the application getting an error? Or is it a timeout? You said "local (mumble) server", so I'm assuming it's an AF_LOCAL socket. If so, make sure that you're running in the same network namespace and using the same filesystem namespace. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Default stack size of QThread
On Monday, 28 August 2023 23:34:26 PDT Ramakanth Kesireddy wrote: > Thanks for your feedback. > As we donot set any stack size for QThread and it looks like it runs out of > default stack size limit during long running operation. Hence would like to > measure the cumulative stack variables used in a thread so as to set stack > size of QThread accordingly. That's not how stacks work: long-running has nothing to do with the size of the stack. What matters for stack depth is just that: how deeply do you recurse. So I repeat the question: why do you think you need to change anything? Do you have a concrete problem? Because if you don't, it looks like you're trying to solve a problem that doesn't exist out of a misunderstanding of how things work. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Default stack size of QThread
On Monday, 28 August 2023 10:05:14 PDT Thiago Macieira wrote: > If you really want this, then QThread doesn't enforce any limit. Please > consult the documentation for the pthread_create() function on how how it > determines the default stack size. For glibc, it uses the RLIMIT_STACK > resource limit. I meant, "by default". Yes you can change the stack size using QThread::setStackSize(), but the default of QThread is 0, so it's whatever the underlying implementation chooses. Since you're using Yocto, if this really matters to you, just change the underlying implementation or Qt. But please answer the question on why you think you need this. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Default stack size of QThread
On Monday, 28 August 2023 05:08:25 PDT Ramakanth Kesireddy wrote: > Hi, > > We are using Qt 5.15.x through yocto Dunfell on embedded Linux. > > Any thoughts on default stack thread size of QThread would be great if it > would be 1-2MB. Why do you want that? This either indicates you don't understand how memory management works on Linux or you have a different problem that needs fixing. If you really want this, then QThread doesn't enforce any limit. Please consult the documentation for the pthread_create() function on how how it determines the default stack size. For glibc, it uses the RLIMIT_STACK resource limit. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Application stack traces are not seen using Massif with Qt debug symbols
On Thursday, 3 August 2023 09:21:26 PDT Ramakanth Kesireddy wrote: > Thanks for the inputs. It helped to resolve the issue. Hope these asserts > are enabled only in Qt debug build as app is able to run fine on Qt 5.15.8 > enterprise installer version. Internal assertions are only enabled in debug builds. In release builds, they are simply assumed. You must still obey them, whether they got printed or not. So, no, your app is *not* able to run fine. It still has a race condition that only happened to cause no visible effect for you (yet). > However, the application stack traces are not seen when used with massif > tool even after enabling config+=debug and QMAKE_CXXFLAGS_DEBUG += -g. > > Am I missing something so that application debug symbols are being read and > shown as stack trace on exit of application? Sorry, that's a Massif question now. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Application stack traces are not seen using Massif with Qt debug symbols
On Wednesday, 2 August 2023 09:46:54 PDT Ramakanth Kesireddy wrote: > ok..Does it mean installTranslator() is not invoked in the main thread? That's what your backtrace says: > #9 0x75f8966e in QCoreApplication::installTranslator > (translationFile=) at kernel/qcoreapplication.cpp:2078 > #10 0x5562c654 in Translator::loadLanguage (this=0x7fffde80, > langId=0) at translator.cpp:89 > #11 0x5562c00e in Translator::installTranslator > (this=0x7fffde80) at translator.cpp:15 ... > #14 0x75d60b0f in QThreadPoolThread::run (this=0x55f73320) at > thread/qthreadpool.cpp:100 -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Application stack traces are not seen using Massif with Qt debug symbols
On Tuesday, 1 August 2023 21:54:47 PDT Ramakanth Kesireddy wrote: > Am unable to locate core dump even after setting ulimit -c unlimited. It was probably captured by systemd-coredumpd. You can find it with coredumpctl. > #4 0x75d4a852 in qt_assert_x (where=where@entry=0x7618ff5b > "QCoreApplication::sendEvent", what=, > file=file@entry=0x7618ff00 "kernel/qcoreapplication.cpp", > line=line@entry=553) at > ../../include/QtCore/../../src/corelib/global/qlogging.h:90 > #5 0x75f80061 in QCoreApplicationPrivate::checkReceiverThread > (receiver=receiver@entry=0x7fffddf0) > at ../../include/QtCore/../../src/corelib/tools/qarraydata.h:208 [cut] > #16 0x75c70609 in start_thread (arg=) at > pthread_create.c:477 > #17 0x75847133 in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 The assertion is correct. You didn't run this in the main() thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Application stack traces are not seen using Massif with Qt debug symbols
On Sunday, 30 July 2023 10:11:55 PDT Ramakanth Kesireddy wrote: > QCoreApplication::installTranslator(). > ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to > objects owned by a different thread. Current thread 0x0x55a25cfacea0. > Receiver '' (of type 'QApplication') was created in thread > 0x0x55a25cf32ef0", file kernel/qcoreapplication.cpp, line 553 > Aborted (core dumped) > > Can anyone let me know if there is any issue with the below configure line > which causes the assert error on ubuntu 20.04 with Qt 5.15.8? No, nothing obvious. It could be a mismatch of having two different Qt loaded into memory at the same time. Can you provide the stack trace of this warning? It says "core dumped" so it means you have a core dump to get the trace from. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Application stack traces are not seen using Massif with Qt debug symbols
On Wednesday, 26 July 2023 02:09:48 PDT Ramakanth Kesireddy wrote: > Yes I am able to get the stack traces for non-Qt applications using g++ > like g++ -g -o my_app main.cpp. > However, when I build the Qt application with Qt creator, it > doesnot outputs the application trace. > > Do I need to build with qmake config+=debug on command line to generate > application stack trace? Please paste the g++ command-line that qmake generated and make printed for your project. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Application stack traces are not seen using Massif with Qt debug symbols
On Tuesday, 25 July 2023 10:38:28 PDT Ramakanth Kesireddy wrote: > In the massif_report.txt, no application stack traces are seen. > > Please let me know if am missing anything in this regard. Why do you think this is a Qt problem? Do you get the stack traces for non-Qt applications? How were those applications built? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QSharedMemory::create returns out of resources errors on a few macOS machines
On Sunday, 2 July 2023 21:51:43 PDT Thiago Macieira wrote: > I suggest you abandon QSharedMemory and simply use QFile + mapping of > memory. https://doc-snapshots.qt.io/qt6-dev/shared-memory.html#sharing-memory-via-memory-mapped-files -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QApplication was not created in the main() thread.
On Saturday, 1 July 2023 06:37:20 PDT Yauheni Pervenenka via Interest wrote: > Hi, Konstantin, thanks for your reply, I have attached stack when QObject > created first time, the problem is that UB is already exists in Qt, No, it doesn't. > Q_CONSTRUCTOR_FUNCTION(initialize) and QBasicAtomicPointer > QCoreApplicationPrivate::theMainThread = > Q_BASIC_ATOMIC_INITIALIZER(nullptr); > should be called in next order, first should be initialized theMainThread > and after should be called Q_CONSTRUCTOR_FUNCTION(initialize) but it is not > guaranteed by standard, https://en.cppreference.com/w/cpp/language/siof Nope. The QBasicAtomicPointer is initialised at static time, meaning it is initialised *before* any code runs. It's guaranteed by the standard. Your diagnosis is incorrect. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QSharedMemory::create returns out of resources errors on a few macOS machines
On Saturday, 1 July 2023 03:04:05 PDT Alexander Dyagilev wrote: > Hello, > > Some rare uses keeps reporting that our app can't start due to this error. > > We use QSharedMemory to keep track of running instances of our app. > > It seems this is can be a known issue due to macOS limits. Here an > article on how to lift them: > http://www.spy-hill.com/help/apple/SharedMemory.html > > However... Did anybody here experience the same issue? > > All I can think for now is that it's caused by some buggy software which > exhausted macOS limits so our app can't function normally. Yes, there's a limit on Darwin kernels and it's pretty low compared to other modern OSes. I suggest you abandon QSharedMemory and simply use QFile + mapping of memory. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Void pointers for Mac ARM
On Tuesday, 20 June 2023 17:46:04 PDT Thiago Macieira wrote: > On Tuesday, 20 June 2023 15:50:16 PDT Volker Hilsheimer via Interest wrote: > > Either way, it would perhaps help to boil all this down to some minimal > > code; you have a 2-byte aligned struct that you cast to and from void *, > > this should be reproducible with small bit of code. And if you have that, > > then comparing the assembly you get out of your compiler when targeting > > Intel vs ARM might give some hints. > > I'm pretty sure he's going to find out that the problem is not the casting, > but elsewhere. The explanation currently doesn't make sense. Proof that it's bitwise equivalent: https://godbolt.org/z/zc1vqh9cs -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Void pointers for Mac ARM
On Tuesday, 20 June 2023 15:50:16 PDT Volker Hilsheimer via Interest wrote: > Either way, it would perhaps help to boil all this down to some minimal > code; you have a 2-byte aligned struct that you cast to and from void *, > this should be reproducible with small bit of code. And if you have that, > then comparing the assembly you get out of your compiler when targeting > Intel vs ARM might give some hints. I'm pretty sure he's going to find out that the problem is not the casting, but elsewhere. The explanation currently doesn't make sense. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Void pointers for Mac ARM
On Monday, 19 June 2023 04:13:51 PDT Turtle Creek Software wrote: > The debugger showed the correct address but failed to cast a > parameter. > > Can the ARM compiler handle #pragma pack (2) ? What does this have to do with casting? It would really help if you gave exact error messages. That includes warnings about ignored / unrecognised pragmas. Anyway, why do you want #pragma produce_slow_memory_accesses? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Void pointers for Mac ARM
On Saturday, 17 June 2023 10:09:42 PDT Turtle Creek Software wrote: > The code also builds OK with the latest Qt6, but running it on an M1 Mac > gives run-time errors. Void pointers to structs and objects don't cast > properly and stay null. Your diagnosis can't be correct. The ABI on Arm Macs is very similar and reinterpret-casting between different pointer types, especially between function pointers and void*, is a simple bitwise copy. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Mysterious C++/QML compilation bug
On Monday, 12 June 2023 07:20:55 PDT Alexander Dyagilev wrote: > Where are this cached files located? In the regular cache dir, which you can find using qtpaths or QStandardPaths. $ qtpaths --paths CacheLocation /home/tjmaciei/.cache/ $ du ~/.cache/plasmashell/qmlcache 4924/home/tjmaciei/.cache/plasmashell/qmlcache -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] TCP window scale
On Tuesday, 23 May 2023 10:37:19 PDT Yauheni Pervenenka via Interest wrote: > In more details I need to get correct progress from my localhost tcp > server, I mean to get progress when tcp server read data from socket, but > now I can write 8MB using QTCPSocket to server but server read nothing from > socket and system ack's every 8192 message After re-reading this, I think the answer is that there's nothing that can help you directly. If you want the sender to know how much the receiver has consumed, then the receiver has to send that information back to the sender. So modify your protocol. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] TCP window scale
On Wednesday, 24 May 2023 00:04:31 PDT Yauheni Pervenenka via Interest wrote: > Hi, Thiago, thanks for your reply, attached server file, attached logs, > wireshark dumps, you can see that server just get notification while 65536 > receive buffer is no full, in wireshark dump sended 8MB and received ack > for every 8192 message, maybe I described the problem wrong but, I am > talking about something like this: What system call will do what you want? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt online installer: Linux ARM platform?
On Friday, 2 June 2023 10:04:30 PDT Alexander Dyagilev wrote: > Hello, > > Am I right that there is no way to build an app for Linux ARM platform > using Qt online installer? That's correct, there is no ARM binary for Windows or Linux desktops. The macOS one comes in universal binary form. > Some of our users asks to add support of Raspberry Pi. We use prebuilt > Qt binaries (provided by online installer) and would like to stick with > them further :) The rule of thumb is to always use the Linux distro's packages if they exist, or build on the distro and use the distro's supporting libraries in "system" mode. Don't use the pre-built binaries for anything but testing. (This is an opinion and is not shared with most other Qt developers) -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt5 --> Qt6 dramatic increase of binary sizes under macOS
On Friday, 2 June 2023 04:37:14 PDT Alexander Dyagilev wrote: > Yes, this is it. I did not know about such a thing (macos universal > binaries). Thanks! :) They've been around since the PowerPC days. They were quite popular during the last processor transition exactly because of that, then later when the 64-bit platforms came online. Also used on iOS when the iPhones started switching from 32- to 64-bit. There was a time when some binaries came with four slices (ppc32, ppc64, i386, x86_64). As far as I know, no one has ever done five (adding x86_64h to those four). -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt5 --> Qt6 dramatic increase of binary sizes under macOS
On Thursday, 1 June 2023 10:56:54 PDT Alexander Dyagilev wrote: > 1) Is this a bug? For me, it sounds like a bug of macOS build system, > because there is no such increase under other platforms. Check if the binaries in both cases are fat and which architectures they contain inside. It's possible your Qt 5 binary was single-arch and your Qt 6 one is a fat x86_64+arm64 binary. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] TCP window scale
On Tuesday, 23 May 2023 12:28:43 PDT Yauheni Pervenenka via Interest wrote:
> const auto writeToSocket = [&](){
> const auto written = tcpSocket.write(QByteArray(8192, '1'));
> qDebug() << "Sending " << written << " bytes";
> };
> QObject::connect(, ::bytesWritten,
> , [&](auto bytes){
> qDebug() << "Bytes written = " << bytes;
> writeToSocket();
> });
This could cause unconstrained memory growth, because you're adding 8kB of
data every time that any amount of data gets written. The MTU in the localhost
interface is greater than 8 kB, so this won't be a problem in this test, but
if you tried this over Ethernet, with an MTU of 1500, it's possible that
bytesWritten() would get emitted after 1460 bytes get written.
So you'd have:
- connected
...after a while...
- write 8 kB → buffer is 8 kB
- bytesWritten(1460) → buffer is 6732 bytes
- write 8 kB → buffer is 14924
- bytesWritten(1460) → buffer is 13464 bytes
- write 8 kB → buffer is 21656
...
Anyway, as with any networking problem, please isolate *which* side the
problem happens on. Your description said "server read nothing". Well, *which*
side had the problem: are you sure the client had sent the data? Confirm with
tcpdump that the data was being sent.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] TCP window scale
On Tuesday, 23 May 2023 10:37:19 PDT Yauheni Pervenenka via Interest wrote: > In more details I need to get correct progress from my localhost tcp > server, I mean to get progress when tcp server read data from socket, but > now I can write 8MB using QTCPSocket to server but server read nothing from > socket and system ack's every 8192 message That's not sufficient information. I actually doubt that what you're asking for will accomplish what you want. It's very likely you have mis-diagnosed the problem and are therefore asking for something completely irrelevant. Very likely, the problem is in your sender, somewhere where you're not looking. Make sure the event loop is running in the thread that is writing that 8 MB. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] TCP window scale
On Tuesday, 23 May 2023 09:06:05 PDT Yauheni Pervenenka via Interest wrote: > Hi, community > Is it possible to change the TCP window size for qtcpsocket? https://doc.qt.io/qt-6/qabstractsocket.html#setSocketOption Maybe QAbstractSocket::ReceiveBufferSizeSocketOption will do what you want. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QT_WARNING_DISABLE_DEPRECATED, QT_INIT_METAOBJECT does not name a type
On Monday, 15 May 2023 15:37:12 PDT Tamás Nagy wrote: > If I start the cross compilation with the build-script.sh, it throws random > recurring > errors containing: "QT_WARNING_DISABLE_DEPRECATED does not name a type", > "QT_INIT_METAOBJECT does not name a type" for the generated > moc_myprogram.cpp as the moc-compiler is running. Through the > cross-compilation script it comes to an error > that can be a missing library linkage. But in which .lib or .so are those > QT_WARNING_DISABLE_DEPRECATED? What should I add to the library linkage? Nitpick: the errors are neither thrown (they are not exceptions) nor are random (there is a pattern, even if you can't discern it). QT_WARNING_DISABLE_DEPRECATED is a macro from qcompilerdetection.h, which is included by qglobal.h, which means it's always defined. It's been there since Qt 5.8. QT_INIT_METAOBJECT is similarly in qglobal.h and was there from 5.10.1 to 6.0, when the design flaw that required the macro in Windows systems was fixed. Because those are macros, they won't be in any .lib, .a or .so. They are in headers; adding libraries to the linking will not solve anything because you have not reached the linking step yet. If it were just the latter error, I'd guess that you're trying to use a Qt5- generated moc output with Qt 6 headers, but the former error implies that is not a good hypothesis. Something else is afoot. I doubt that these are the first errors. Please run the build again and attach the full output from the compiler. Please also include the full compiler command-line that was executed printed by make or ninja -v. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Continued past failed assertions with MSVC
On Tuesday, 9 May 2023 17:33:04 PDT Alexander Dyagilev wrote: > The most ugly thing coming from it is that it changes the way app works. > It executes additional event loop in those regions of code where it's > not supposed to happen. This can bring additional bugs and/or change an > apps' behavior on its own. > > For me, it never helps to debug app. It interferes instead. Ah, that's interesting: the fact that it is running a Windows event loop and thus processing messages. That's easy to fix, though, we can simply remove the event handler callback before starting that dialogue. But that does mean we can't resume from a failed assertion, as we may have missed messages and made things even worse. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Continued past failed assertions with MSVC
On Monday, 8 May 2023 16:50:51 PDT Scott Bloom wrote: > I do on a regular basis. Not sure why you say it’s a horrible dialog, it’s a > message box with the assertion information. Because it's "Abort", "Retry", "Ignore" that tells you that "Retry will launch the debugger", so it doesn't actually mean retrying. Do you really mean you use the Ignore functionality? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Continued past failed assertions with MSVC
When a Qt application fails a Q_ASSERT and was compiled against a debug-mode QtCore, with MSVC, it shows a debug dialog with three options: Abort, Retry, Ignore. It looks like https://www.google.com/search?q=_CrtDbgReport+dialog This is a horrible dialogue that harkens back to the DOS days. But the big problem is that "Ignore" button: it allows the application to ignore this condition and continue executing. I suppose people use it for debugging past failed assertions to see what else is going on. So the question is: does anyone use this particular feature? Would you suffer terribly if we removed it? This would bring MSVC in line with the other compilers. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QMAKE_BUNDLE_DATA: $$files does not work for macOS
On Monday, 1 May 2023 15:44:35 PDT Alexander Dyagilev wrote: > Yes, looks like this. Any way to work around this? :) Do exactly what you did: list the actual names that you expect will get created. This also ensures that the build fails if one of the files is missing, for some reason, instead of silently producing something that may be unworkable. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QMAKE_BUNDLE_DATA: $$files does not work for macOS
On Monday, 1 May 2023 06:39:43 PDT Alexander Dyagilev wrote: > Hello, > > Did anybody encounter this issue and has a nice workaround? > > I'm trying to use this code (qmake) to copy my shared library to > Frameworks folder of my app's bundle. > > mylib.files = $$files($$OUT_PWD/$$DESTDIR/libmylib*.dylib) > mylib.path = Contents/Frameworks > QMAKE_BUNDLE_DATA += mylib > > It does not copy anything. However, this code works (instead of $$files): > > #mylib.files += $$OUT_PWD/$$DESTDIR/libmylib.dylib > $$OUT_PWD/$$DESTDIR/libmylib.1.dylib > > This issue exists under macOS only. $$files works fine when building for > iOS. That probably happens because those files don't exist when you ran qmake, so the glob matched nothing. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Behavior of write() to stdErr in Qt Creator
On Friday, 28 April 2023 01:31:39 PDT Bernhard Lindner wrote:
> Please note that lines are not interleaved. Still a line feed is added after
> each write() call when executing the code snippet from a sub thread.
>
> The effect is completely reproducible when starting the debug build from Qt
> Creator under gdb supervision. However when manually stepping through the
> code or when running the debug build without debugger the output looks just
> fine.
I can reproduce this with the attached test. The problem appears to be that
when Qt Creator reads from the pipe, it assumes that whatever it read is a
full line after a time out, when it isn't. It doesn't update the previous line
when more characters are received.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
#include
int main()
{
write(2, "h", 1);
sleep(1);
write(2, "h", 1);
sleep(1);
write(2, "h", 1);
sleep(1);
write(2, "h", 1);
sleep(1);
}
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QTcpServer::setProxy meaning?
On Thursday, 20 April 2023 08:14:41 PDT Alexander Dyagilev wrote: > What about authentication? QTcpSocket has proxyAuthenticationRequired > signal. > > But QTcpServer does not. Am I right that the only way is to provide > user/password in QNetworkProxy in a call to QTcpServer::setProxy? Probably, yes. You need to test to make sure it works, I don't think we've ever tested the SOCKS5 support for proxy authentication in BindMode. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] running Qt main event loop in secondary thread
On Tuesday, 28 March 2023 13:23:58 PDT Stefan Seefeld wrote: > if you have a look at the little sample script I attached to my mail you'll > see that I'm actually constructing the application object within the > function that is executed in the other thread. > I do however import PyQt5 modules at the top of my script, and if I move > those imports into the function the warning goes away. > Does this suggest that PyQt5 itself instantiates a QApplication as a global > object ? No. It suggests that PyQt5's loading process creates at least one QObject, but not a QCoreApplication/QApplication object. And as I said about the libraries themselves, I can't guarantee that one of them won't create such object just by linking to it. I can only guarantee QtCore doesn't (in 6.5; I can't guarantee earlier versions). You must cause there to be NO QObject creations at all, if you want to create your QCoreApplication in another thread. If you can't ensure that, then you must accept defeat and create the QCoreApplication in that thread where the first QObject was created. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] running Qt main event loop in secondary thread
On Tuesday, 28 March 2023 06:16:52 PDT Stefan Seefeld wrote: > First I see > the error / warning message > > `WARNING: QApplication was not created in the main() thread.` > > the main window appears, but isn't fully constructed and it doesn't look > like the event loop is ever started. (The window's content isn't updated, > no button appears, and the app isn't receiving input events.) > What am I doing wrong ? You must create the QCoreApplication (including QApplication) in the thread that the first QObject is created in. That warning message tells you that you didn't. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] running Qt main event loop in secondary thread
On Monday, 27 March 2023 13:23:02 PDT Stefan Seefeld wrote: > Hello, > > I'm working on some Python tests that interact with a Qt application. I > would like to run the application's event loop in a secondary thread, so > the primary thread can perform the test itself. > > I read in the past that such a use-case wasn't supported by Qt, but I can't > find that information right now, and neither do I remember the rationale > for that limitation. >From Qt's point of view, as well as from the C and C++ one, one thread isn't different from any other. Any thread can assume any responsibility. What Qt cares about, specifically the QCoreApplication event loop (which is the GUI event loop if you have a GUI) is the *first* thread in which *any* QObject is created. We also ask that that first QObject be QCoreApplication itself, but it isn't required to be so. In theory it would be possible to let QCoreApplication be created in any thread, but it's not implemented and also not something we'll spend time on. > For context: my application is somewhat atypical in that the application > only has a minimal GUI, but does a lot of processing of input from TCP/IP. So GUI in the main thread and processing of data auxiliary thread(s). The networking itself may be the main thread, those auxiliary threads, or dedicated network threads. This is the typical design of such applications. > The test logic I'd like to write would thus have test function (running in > the primary thread) control the data sent to the app and inspect and assert > the application's corresponding states, while the event processing would > take place in a secondary thread. If your GUI is minimal, then it doesn't matter where it runs; that means it can run in the main thread while you create the data that will be processed by your networking code. Or you can create the data in yet more auxiliary threads too. There's nothing in your design that requires your data-creation to be the main thread nor the shunting of the GUI into an auxiliary one. Also... you don't need a GUI for testing. You should make it so no windows are shown and therefore no GUI input is processed while in test mode. That means you don't have to exec() the Qt GUI event loop. > I'm unfortunately not sure that such a use-case is possible at all, i.e. I > may have to invert roles, i.e. have the actual "test scenario" be executed > in a secondary thread as the main thread is reserved for the (blocking) > event loop. You can do what you want too. Like I said, just make sure no QObject is created before you start this other thread and create the QCoreApplication in there. Do note that some libraries may create QObjects by simply linking to them. QtCore doesn't do that. I make no statements about any other Qt library, including QtGui itself. If that happens, you may need to move the Qt code to a plugin so you can delay loading it until the auxiliary thread is created. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6.4.3 compiler warnings in QTaggedPointer
On Thursday, 23 March 2023 00:03:24 HST Hamish Moffatt via Interest wrote: > OK. There's a similar issue in QtConcurrent (unchanged since 5.15 > actually) also driving me mad - __int64 resulting from std::distance is > assigned to int. In Qt 6, that should just be qsizetype or plain auto. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6.4.3 compiler warnings in QTaggedPointer
On Wednesday, 22 March 2023 18:19:59 HST Hamish Moffatt via Interest wrote: > static constexpr quint8 tagBits = > QtPrivate::qConstexprCountTrailingZeroBits(alignment); > > So would you fix it with a cast, or by changing the variable type to int > to match the function? Either solution is fine. I was thinking of simply adding a quint8() cast around the result, but changing to uint also works too. The latter is a smaller change anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6.4.3 compiler warnings in QTaggedPointer
On Tuesday, 21 March 2023 20:18:17 HST Hamish Moffatt via Interest wrote: > I'm porting from Qt 5.15.12 to 6.4.3, and now MSVC 2019 is giving me a > ton of compiler warnings about QTaggedPointer. [cut] > Any suggestions on how to shut it up? Stop using 2019, please. That compiler has a number of unfixed bugs. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
On Saturday, 18 March 2023 13:47:53 PDT Scott Bloom wrote: > Was that the core issue? Or it still isn’t working with the correct check > in? The content was there, it was just in the parent commit. So it ran when I executed it. The problem is that the CRT still did full buffering, didn't flush before the TerminateProcess. The parent saw nothing printed. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
On Friday, 17 March 2023 14:00:54 PDT Scott Bloom wrote: > Maybe I missed it. But I don’t see where you use the InheritableHandleInfo > template. WTF? Ah, it ended up in the wrong commit in the series during rebase. Fixed. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
On Tuesday, 7 March 2023 18:18:53 PDT Scott Bloom wrote: > I really want to thank Björn > > With his starting point, I was able to tweak his changes, and seem to have > it working I have more testing to do. But it was actually pretty > straight forward. > > * I use VS (2022) so the packing was different > __attribute__((packed)) became __pragma( pack( push, 1 ) ) struct > HackedHandlePasser * The handles are 64 bit in the existing Startup Info, > so I kept them as such, which changed the definition of HANDLE32 using > HANDLE32 = std::int32_t; was removed, and the standard HANDLE defined in > windows.h was used * The static assert was updated to reflect this > * I copy all 3 handles from the existing startupinfo >std::memcpy([0], , 4); >std::memcpy([1], , 4); >std::memcpy([2], , 4); > >became > > std::memcpy( [ 0 ], >startupInfo->hStdInput, > sizeof( HANDLE ) ); std::memcpy( [ 1 ], > >startupInfo->hStdOutput, sizeof( HANDLE ) ); std::memcpy( > [ 2 ], >startupInfo->hStdError, sizeof( HANDLE ) ); I'm trying to add this to QProcess but it's not behaving as expected on Windows. https://codereview.qt-project.org/c/qt/qtbase/+/467281 -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] can't dump QStringList with qDebug()
On Tuesday, 7 March 2023 21:20:02 PST Hamish Moffatt via Interest wrote: > I confirm that my test code compiles in 6.5.0-beta3. And I can reproduce the error with GCC 13 if I check out the 6.4.2 headers. GCC 13 says: note: candidate: ‘template QDebugIfHasDebugStreamContainer, T> operator<<(QDebug, const QList&)’ note: template argument deduction/substitution failed qdebug.h:217:53: required by substitution of ‘template QDebugIfHasDebugStreamContainer, T> operator<<(QDebug, const QList&) [with T = QString]’ type_traits:2594:11: error: no type named ‘type’ in ‘struct std::enable_if’ This is GCC speak for "condition evaluated to false" By moving the constraint from the return type to a static_assert inside the function, I can prove that the ostream test fails: qdebug.h:219:5: error: static assertion failed due to requirement 'QTypeTraits::has_ostream_operator_v' But that test is: std::void_t() << detail::const_reference())> and if I copy that expression to the function, it does compile. Moreover, the changes to qdebug.h and qtypeinfo.h don't seem related. So I have no clue *why* the check fails and *how* it was fixed. This is template black magic. It works right now and I've spent enough time investigating. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] can't dump QStringList with qDebug()
On Tuesday, 7 March 2023 17:21:11 PST Hamish Moffatt via Interest wrote: > I said gcc 10 earlier, but I meant to say clang 11. But I also see it in > clang 14, and in VS 2019 (17.5.1 - latest). Cannot reproduce with those files with GCC 11, 12, 13 or Clang 15, all with Qt 6.6. Looking at the generated assembly, I can also see the compiler realised the list is always empty, so the loop from printSequentialContainer() disappears.f -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
On Tuesday, 7 March 2023 14:23:00 PST Björn Schäpers wrote: > From the code I reviewed back then (and remember it now) it unpacks the > handles directly to a HANDLE, which is pointer size (although it only uses > the lower 32 bit). But Scott will tell us what the field width has to be > for a 64 bit process. Yup. BTW, Scott, when using QProcess::setCreateProcessArgumentsModifier(), you get access to QProcess' standard handles so you can place them in your fd table. Björn's code probably predates that function (Qt 5.7). -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
[quoting out of order] On Tuesday, 7 March 2023 12:57:59 PST Björn Schäpers wrote: >startInf.cbReserved2 = sizeof(HackedHandlePasser); >startInf.lpReserved2 = reinterpret_cast(); These reserved fields are how the runtimes "pass file descriptors" to child processes. This mimics the Unix fork() behaviour that the parent's open file descriptors are available in the child, without implementing the full fork() behaviour. The fields are undocumented (AFAIK) but since both msvcrt and ucrt depend on the specific behaviours, they can't change. That includes these bit fields for flags: >#ifndef FOPEN > #define FOPEN 0x01 >#endif >#ifndef FDEV > #define FDEV 0x40 >#endif > >handles.FlagsPerHandle[0] = 0; >std::memset([1], FOPEN | FDEV, 2); According to the UCRT source code, the FDEV flag controls whether the standard streams will be buffered or not. The UCRT implementation of isatty() is a check to see if this flag is set. The UCRT source code isn't complete (ucrtbase isn't included AFAICS), so I couldn't find all details when trying to give you a more specific answer. > * I have the HANDLE32 because I start a 32 bit application from within a 64 > bit, as far as I understood the structure needs the right HANDLE size, thus > for a 64 bit application it should be std:int64_t, but since I don't need > that I never tested it. The parent process wouldn't know whether the child is 32-bit or not, so I imagine the size must be fixed at 32 bits in order to be inheritable. If you have MSVC, you have access to the UCRT source code too and you can search for those two reserved fields to see if they hardcode to 32-bit or pointer sizes. > So when using it with QProcess I think one should copy the handles from the > STARTUPINFOW structure into this struct, then I think the normal QIODevice > interface should keep working. If one should clear the STARTF_USESTDHANDLES > flag I also don't know. I stopped my experiments when I achieved success > for my "simple" use case. QProcess uses CreateProcessW directly, not the _spawnv* CRT family of functions, which is why file descriptors aren't usually inherited via QProcess. I don't know either whether the STARTF_USESTDHANDLES flag must be cleared because they're handled at separate times. If this flag is passed, then the three handles in STARTUPINFO[1] are passed to the child as its default handles, by the Win32 call itself. That means those handles are installed in the child before the runtime gets a chance to initialise and read the file descriptor table passed in those reserved fields. Whether the runtime overwrites the standard file descriptors or not, I couldn't find in the UCRT sources. And for the same reason, I can't tell either how the FDEV flag is set for the standard file descriptors from outside the file descriptor table. Moreover, please note that this is *runtime* -driven behaviour, not OS- mandated. So it's entirely possible that this executable that Scott wants to run operates differently because it uses a weird runtime. (Strictly speaking, it's the same on Unix systems, but all libcs have the same behaviour) [1] https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-startupinfoa -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] can't dump QStringList with qDebug()
On Monday, 6 March 2023 22:15:01 PST Hamish Moffatt via Interest wrote: > ../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdebug.h:217:53: note: > candidate template ignored: requirement > 'std::conjunction_v, > QString>, QTypeTraits::has_ostream_operator>>' was > not satisfied [with T = QString] This is the expected template and the compiler told us why it couldn't expand: it thinks that the QDebugIfHasDebugStreamContainer condition wasn't satisfied. That condition is std::is_base_of OR QTypeTraits::has_ostream_operator Obviously, QStringList is not a base class of QString; we're expecting the second check to be true, that there's an output streaming operator for QDebug- QString That of course is there; it's in QDebug itself. So my conclusion is that your compiler has a bug and improperly parsed the C++ code. Does this problem happen with GCC 11 or 12? -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
On Monday, 6 March 2023 12:17:39 PST Björn Schäpers wrote: > I had the exact same problem (but without QProcess). You have to use a trick > to disable the buffering, I don't know if its possible with QProcess, you > will have to use QProcess::CreateProcessArgumentModifier or most likely > CreateProcess directly. QProcess gives you access to all options of CreateProcess, so if it's a matter of flags, it should be doable with it. If it's something else, we'd like to know. > If there is interest I can copy some of my data, but currently I can't > access it. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
On Sunday, 5 March 2023 20:32:20 PST Bob Babcock wrote: > I haven't tested this, but what happens if you use QProcess to run >cmd /c mkvalidator ... > I suggest this because mkvalidator output isn't buffered when run in a .bat > file. You might lose return codes doing it this way. If you were saying "/bin/sh" "-c" "mkvalidator" on a Unix system, I'd say it makes absolutely no difference. The issue is whether stdout is connected to a terminal or not, and using a shell doesn't change that. On Windows, I have no clue. The equivalent concept of a terminal is a console, but the lack of a standard C library makes the question more difficult than it would otherwise appear. Is mkvalidator a /subsystem:console application or is it GUI? If it is GUI, how does it determine whether to write anything to stdout at all? If it's console, how does it choose between line-buffered and fully-buffered? And how does this all change if you use cmd.exe? Sorry, I don't know the answer. If at all possible, I'd investigate if this application has a separate, machine-communication channel that you can use instead of the stdout pipe. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QProcess unbuffered
On Sunday, 5 March 2023 17:11:13 PST Scott Bloom wrote: > I have an external executable (mkvalidator from > https://www.matroska.org/downloads/mkvalidator.html > > It never flushes the output, and it uses linefeed without carriage returns > to overwrite existing text on the output. You've described the standard for Unix processes. There's no carriage return and stdout is fully buffered when not connected to a terminal. > The problem is, when I run it via QProcess (on windows, Qt 5.15.10), I get > zero output until the process ends. As if it was buffered, and the output > was finally flushed > > When running from the command line, I do get output continuously during the > processing. > > I setup a timer to waitForRead, didn't do anything. I cant seem to force the > QProcess to read all stdout or stderror info. You don't need a timer on waitForRead because you have the readyRead() signal. Anyway, the problem is that your process is not writing. It's buffering its output until later. This is not a QProcess problem; you must force the child process to write. Many programs that do this type of interaction have a command-line option to switch back to line-buffered. For those that don't, you can use the /usr/bin/ stdbuf tool to change the buffering semantics, but I don't know how it works, just that it does on Linux, so it may not on Windows. Since you're on Windows and this application is not part of Windows itself, it stands to reason you're compiling it yourself and distributing with your application. So just modify it to be line-buffered. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Weird assert, how to debug?
On Thursday, 2 March 2023 22:09:19 PST Axel Spoerl via Interest wrote: > Option 2 seems more likely to me, since the assertion doesn't shout in > release builds. Assertions are disabled in release builds. But the invariant that they were testing for will be assumed and thus may cause other, visible symptoms. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] use of deleted function errors in QList / qarraydataops.h
On Monday, 27 February 2023 16:22:46 PST Hamish Moffatt via Interest wrote: > How and when would Qt5 show an error? We have the above code working and > in production, and I'm able resize, copy and change, force a detach - > operations where QVector would need to copy elements. Ah, looks like it isn't going to. I expected the issue was that it didn't happen in this test case because it never detached. If you're definitely detaching, then this isn't the same issue. The issue here is that you have a type that is copy/move constructible, but cannot be copy/move assigned. That's usually a bad combination; the new QList/ QVector code uses move-assignment when moving elements in the overlapping part of the list. We could determine that your type is not move-assignable and use a different strategy, but this isn't implemented right now. It might be less efficient; I wouldn't know. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] use of deleted function errors in QList / qarraydataops.h
On Monday, 27 February 2023 13:05:01 PST Hamish Moffatt via Interest wrote:
> On 28/2/23 04:14, Thiago Macieira wrote:
> > On Sunday, 26 February 2023 23:24:43 PST Hamish Moffatt via Interest wrote:
> >> Is there a solution?
> >
> > Remove the const in:
> > struct S
> > {
> >
> > const QVector v; // compiles if not const
> >
> > };
> >
> > If S is not copyable, then QVector can't copy it and QVector requires
> > copying all its elements.
>
> May I ask why that is? Qt5 QVector and std::vector are both OK with the
> above.
Qt 5 QVector is not ok with the above, it just hasn't produced an error *yet*.
All Qt main containers are implicitly-shared and therefore must be able to
copy their elements. Therefore, your elements must be copyable.
std::vector doesn't have this requirement. It is copyable if the element is
copyable, otherwise it isn't.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] use of deleted function errors in QList / qarraydataops.h
On Sunday, 26 February 2023 23:24:43 PST Hamish Moffatt via Interest wrote:
> Is there a solution?
Remove the const in:
struct S
{
const QVector v; // compiles if not const
};
If S is not copyable, then QVector can't copy it and QVector requires copying
all its elements.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QTcpServer::setProxy meaning?
On Saturday, 25 February 2023 07:17:39 PST Alexander Dyagilev wrote: > Hello, > > I can't understand it. Are there really proxies supporting such a mode? Yes, SOCKS proxies for example. > I.e. QTcpServer tells a proxy to start listening on some specific port > and redirect incoming connections to QTcpServer? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Errors while building Qt 6 on Windows
On Monday, 20 February 2023 05:23:38 PST Alexey Edelev wrote: > Please remove C:/Strawberry from path. before running configure. Or at > least please make sure that it goes after the mingw provided by Qt. Or any MinGW that is sufficiently recent; it doesn't have to be the one that Qt Company uses and provides. The problem with the Strawberry one is probably that it is too old and lacks std::filesystem support in libstdc++ (it was still in the experimental libstdc++fs library). -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
