Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix lifetime issue with utf8 string in Drumkit::exportTo #2069

Merged
merged 1 commit into from
Nov 24, 2024

Conversation

cme
Copy link
Contributor

@cme cme commented Nov 24, 2024

The QString::toUtf8() function returns a QByteArray object. Previously, a reference to the contents of this was taken with .constData() but the object itself was transient and destroyed at the end of the statement, leaving a const char* pointing at freed memory.

Copy link
Contributor

@theGreatWhiteShark theGreatWhiteShark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Damn. We use toUtf8().constData(), toLocal8Bit().data() and things alike in quite a number of places. Strange it did not cause issues yet. Well, maybe it did and we just couldn't reproduce the tickets.

I'll take care of fixing lifetime handling of the remaining occurrences.

@cme
Copy link
Contributor Author

cme commented Nov 24, 2024

I'll take care of fixing lifetime handling of the remaining occurrences.

Using the memory sanitizer (-fsanitize=memory) should find these I think!

@cme cme merged commit f3f5428 into hydrogen-music:master Nov 24, 2024
1 check passed
@cme
Copy link
Contributor Author

cme commented Nov 24, 2024

Using the memory sanitizer (-fsanitize=memory) should find these I think!

Oops, I mean -fsanitize=address. I've just tried builds with that and it does indeed find this problem during the unit tests, and with this fix it is clean with no further asan violations :)

@theGreatWhiteShark
Copy link
Contributor

I've just tried builds with that and it does indeed find this problem during the unit tests, and with this fix it is clean with no further asan violations :)

Well, not on my end :D I get both a couple of asan violations and classical test failures when adding this compile option. I'll take a look.

But I'm very glad we have all these unit tests helping us to track down potential issues.

@cme
Copy link
Contributor Author

cme commented Nov 24, 2024

Potentially GCC's asan covering some different cases from LLVM's. I certainly have asan failures if I try and actually run the GUI.

@theGreatWhiteShark
Copy link
Contributor

Potentially GCC's asan covering some different cases from LLVM's. I certainly have asan failures if I try and actually run the GUI.

What happens if you encounter one of those asan failures? Always a full segfault?

I'm a little stunned how much things this option uncovers. There are e.g. memory leaks when loading a drumkit or when creating the Preferences instance. Any more magic compiler options we should employ in our test builds in AppVeyor?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants