fixed SIGSEGV caused by wrong initialization order

[moodyhunter]

Your checklist for this pull request

• I've read the guidelines for contributing to this repository
• I made sure to follow the project's coding style
• I've updated the documentation with the relevant information (if needed)

Detailed description

For the ImportsWidget class, its importsModel and importsProxyModel are initialized before the constructor, whilst the imports variable is initialized after them using default initlization order. (See https://en.cppreference.com/w/cpp/language/constructor (Initialization order section))

This leads to undefined behaviour when taking the address of imports to construct the ones before imports itself is constructed.

This PR changed the order that they three appears in the class member variable declaration, making imports the first one of the three to construct, which fixed a possible segmentation fault on my machine.

The same for RelocsWidget

Update:

My SIGSEGV back trace:

Test plan (required)

Compile and run.

Closing issues

Currently none.

[karliss]

These same issue is handled by 561a191 in #2662

[moodyhunter]

@karliss Thanks for the clarify.

However, I find the Qt5 build is also affected, (e.g. the recent versions in ArchLinux packages).

Should this fix be backported?

[karliss]

Yes, I confirmed that it also affects Archlinux version of QT with KDE patches. Not surprising that changes done at some point after 5.15.2 release are also included Qt 6.

I am not sure what you meant by "Should this fix be backported?". Qt6 branch isn't for replacing Qt5 with Qt6 it's for adding support compiling with both, using the same code as much as possible. So no backporting will be required it will be required.

[moodyhunter]

I wonder if we can apply this patch to the existing Qt5 version so that ArchLinux users will not experience a crash during startup.

[lenerd]

Applying this patch to the current 2.0.1 release fixes the segfault for me (also Arch Linux). Thanks!

Will there be a new release soon that contains a fix, or do we have to wait until the whole QT6 support is ready?

[karliss]

Yes there will be 2.0.2 soon that's why the milestone is there. It's mostly a matter of finishing code reviews. As was said multiple times "More Qt6 support" PR isn't "all the QT6 support". I doubt full Qt6 support will be finished earlier than 2.2 or 2.3. I want the #2662 to be included in 2.0.2 because it includes at least one more change that causes a more subtle bug with Qt6 and possibly current or future Qt 5.15.2 patches.

[lenerd]

@karliss Ah, ok. Thanks for your work on this!

[karliss]

Cutter 2.0.2 has been released including a different implementation of this fix.

[moodyhunter]

Thanks!