@Christian-Ehrlicher said in Strange memory allocation issues?:

@Dariusz said in Strange memory allocation issues?:

Any idea why converting QString to stdString causes memory allocation issues?

I don't know what you're trying to achieve - if you want to look for memory leaks use the appropriate tools but those two functions don't leak any memory.

/edit:
and btw: there is more than one new operator: https://en.cppreference.com/w/cpp/memory/new/operator_new

Meh no luck, added other ones but failed to track it :/

// 1. Simple allocation void *operator new(std::size_t size) { if (mRecordData) { allocations++; total++; void *p = std::malloc(size); if (!p) { badAllocs++; totalBadAllocs += size; throw std::bad_alloc(); } totalSizeAllocated += size; return p; } return std::malloc(size); } // 2. Array allocation void *operator new[](std::size_t size) { return ::operator new(size); } // 3. No-exception allocation void *operator new(std::size_t size, const std::nothrow_t &) noexcept { if (mRecordData) { allocations++; total++; void *p = std::malloc(size); if (!p) { badAllocs++; totalBadAllocs += size; } return p; } return std::malloc(size); } // 4. Array no-exception allocation void *operator new[](std::size_t size, const std::nothrow_t &nt) noexcept { return ::operator new(size, nt); } #if __cplusplus >= 201703L // 5. Aligned allocation (C++17 onward) void *operator new(std::size_t size, std::align_val_t al) { if (mRecordData) { allocations++; total++; void *p = _aligned_malloc(static_cast<size_t>(al), size); if (!p) { badAllocs++; totalBadAllocs += size; throw std::bad_alloc(); } totalSizeAllocated += size; return p; } return _aligned_malloc(static_cast<size_t>(al), size); } // 6. Aligned array allocation (C++17 onward) void *operator new[](std::size_t size, std::align_val_t al) { return ::operator new(size, al); } #endif // Corresponding delete overloads void operator delete(void *p) noexcept { if (mRecordData) { deallocations++; total--; } std::free(p); } void operator delete[](void *p) noexcept { ::operator delete(p); } void operator delete(void *p, const std::nothrow_t &) noexcept { ::operator delete(p); } void operator delete[](void *p, const std::nothrow_t &) noexcept { ::operator delete(p); } #if __cplusplus >= 201703L void operator delete(void *p, std::align_val_t) noexcept { ::operator delete(p); } void operator delete[](void *p, std::align_val_t) noexcept { ::operator delete(p); } #endif

Bummer!

Just wanted a lightweight way of tracking my test allocations/memory footpring :c
I know there is valgrind/other ones, but they are harder to set up for per-function tests/etc inside gtest as far as I can tell :/

I didn't intend this question to be a joke or blaming session. I invested quite some time already in trying to make testing Drag&Drop work.

Does anyone have an idea how to (automatically; also in CI) post the necessary events to make the drag-engine recognize them? Nothing I tried inside the Qt-framework worked so far, because the drag-engine circumvents the Qt-framework completely. At least on Windows; could be different on Unixoid systems, but I don't have the liberty to use that system.

Just a thought: is there a platform-plugin available for testing on Windows? Currently the default one is loaded.

I managed to solve the problem.
The cause was my mistake in understanding how signals works in test environment.

During tests I have no EventLoop running, so the signal-slot mechanism of Qt can't work.
De facto, every time the assign method execute, I was emitting a signal using a Qt:QueueConnection, but there was no EventLoop running to process the signal queue.

Every time I call a setter method in test code, the next line have to be:

QVERIFY(signalSpy->wait());

which waits, no more than 5 seconds, running an internal EventLoop to process all emitted signals, and waiting for signals of the same type declared in QSignalSpy instance.

Since I had some methods with signal checks and some with only simple code checks (but both of them emit signals) I had a continuous jump between methods with and without QSignalSpy usage.

Since no EventLoop is running on tests, when I called the wait method on QSignalSpy instance, I was getting all the queued signals emitted on the previous test method, which also explain why I was getting constant numbers on signal counts.
I was not able to resolve just calling signalSpy->clear() in cleanup method because there was nothing to clear.

One solution could be to run the EventLoop between every tests method, just to be sure that the next test will handle only signals emitted in its code.
I resolved the problem implementing signals checks in every test method, which not only was my initial goal, but which ensure that every signal-emitting code is followed by a call to wait() method, which runs the EventLoop.
Every signal, now, is kept inside the test method and everything seems to works.

Thanks for support

@oblivioncth said in Help with Autotest for Gerrit submission:

So I should just add the cases locally, ensure they test correctly, and then commit --amend & push the changed test file as part of the rest of my submission?

That's correct yes.

Oh yes, it's logic. Thanks !!!

I found a solution for the issue: Simply split the main() from the rest of the Project . Here is the updated Production Code Product specification:

import qbs Project { name: "TheRealApp" QtApplication { name: "TheApp" Depends { name: "cpp" } Depends { name: "library" } Group { name: "Main" files: [ "main.cpp", ] } } StaticLibrary{ name: "library" Depends { name: "cpp" } Depends { name: "Qt.core" } Export { Depends { name: "cpp" } cpp.includePaths: product.sourceDirectory } Group{ name: "Grp_Main" files: [ "mycustomclass.cpp", "mycustomclass.h", ] } } }

Hi,

IIRC, you can't directly do that. However, there where some scripts in the qtqa repository to run the tests in the CI, you might be able to leverage that.

Hope it helps

I've partialy analysed AutoTest code.
For QTest it checks if given source file (after macro preprocesing) has QTest include and QTest::exec() somewhere in code.
In my case it lead to usage of TestRunner modified to store function object

#define DECLARE_TEST_RUNNER(className) \ namespace { \ int executeTestClass(int argc, char* argv[]) \ { \ className test; \ return QTest::qExec(&test, argc, argv); \ }; \ static char test_##className = \ TestRunner::Instance().RegisterTestClassRunner(executeTestClass); \ }

Macro is placed at begining of each CPP file with test details (to decouple as much as possible)

However Autotest still acts strangely. Sometimes it discover tests, sometimes not. I believe that it may search in source context of currently selected run target.

PS: When I expanded one of DECLARE_TEST_RUNNER macro - AutoTest start displaying green arrows. Not before. Building main exe or ut.exe isn't helping.
Calling 'Refresh test' from Tools->Tests also doesn't help. I still don't know what triggers test gathering.
PSS: In each test binary at least one QTest::qExec should be expanded out of MACRO. From this point - AutoTest shows also test runners hidden in MACRO and run then all.

Nice ! Thanks for sharing :)

Nice one ! I've missed that function. Thanks !

Hi @CharlieG
AFAIK that is not possible from QML. But you can try checking for errors by loading the QML from C++ side. For eg. if you use QQmlComponent you can check for errors using errors.

@Paul-Colby
Thank you for reporting back.
This is very important info for people using this function as "stuff"
will happen if you upgrade from older Qt.

@Sam2304

you are welcome

Well, sometimes "we programmers do not see the forest because of trees" ;)
Glad, that it worked out for you.

Hi and welcome to devnet,

reading from docs QWidget::cursor() should do the job. Have you tried it?