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 order of static initialization #13386

Merged
merged 2 commits into from Feb 17, 2023
Merged

Conversation

oltolm
Copy link
Contributor

@oltolm oltolm commented Feb 11, 2023

Without this fix rpcs3 sometimes crashes on start. I guess it happens because the order of static initialization is undefined.

@elad335
Copy link
Contributor

elad335 commented Feb 11, 2023

When you say sometimes, you mean static initialization happens on more than one thread which causes this this situation to occur randomly?

@oltolm
Copy link
Contributor Author

oltolm commented Feb 11, 2023

I build rpcs3 myself and sometimes the build crashes because of this problem. It depends on the build details I guess. If it crashes then it crashes each time it is started, so I don't think it has anything to do with threads.

@kd-11
Copy link
Contributor

kd-11 commented Feb 11, 2023

This fix makes no sense. What dependency chain is supposedly fixed by moving the static var to function scope?

@oltolm
Copy link
Contributor Author

oltolm commented Feb 11, 2023

I think it happens because the code tries to insert into s_module_map before s_module_map is initialized. The order of static initialization is undefined in C++ if the initialization happens in different compilation units.

If the code in cellFont.cpp does this

DECLARE(ppu_module_manager::cellFont)("cellFont", []()

It calls void ppu_module_manager::register_module(ppu_static_module* _module) in the end which inserts into the static map s_module_map. In C++ it is undefined whether s_module_map is initialized before the call of register_module.

I'm not a C++ expert, but that's what I think is happening and it happened to fix the problem, but I could be wrong of course.

@kd-11
Copy link
Contributor

kd-11 commented Feb 11, 2023

It's a reasonable explanation, but that should be in the PR description. Without that context the code change makes no sense.

@Nekotekina Nekotekina merged commit bbd308a into RPCS3:master Feb 17, 2023
@oltolm oltolm deleted the fix_static_init branch February 17, 2023 15:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants