AStopher
commented
3 years ago Work on this has now commenced, I believe I have identified the source of the StackOverflowException crashes (we were creating database connections but returning before they were closed, resulting in the MySQL library keeping the connections open and therefore reaching its maximum connection limit and falling over) but to fix this requires either dumping data to a variable, closing the connection, and then returning the variable (easy), or to fix the issue properly by centralising the database interface into one class (more difficult).
Today I have:
- Made it so that the individual services (CDKey, ServerRetrieve, etc.) can restart without restarting the Core platform service. This is in preparation for a Discord connection to allow admins to restart services easily through a command interface.
- Re-written the database communication code, so that all communication is via one class instance that keeps a singular connection open instead of opening a connection for each and every query. I am keeping in mind that MySQL might refuse to execute a new query when one is already being executed, so I may need to create a multi-threaded database communication system (this is easy, but will take time).
- Started re-writing login and user registration code to use the new database communication class. This has also involved refactoring of several requests to improve efficiency (for example for user login we were checking if the user was banned first before fetching their data, when it would be more efficient to fetch their data and then check if they are banned using the data we fetched).
- Removed profile ID randomisation functionality, this was used by admins to effectively be unbannable from servers using the Wildfire service but is no longer needed (and to be honest if a server wants to ban service admins then that's completely fine and their decision, just that if we receive complaints about the server then we won't be able to enter the server to investigate and would simply ban the server).
- Changed status string recognition from "Playing Crysis Wars" to "Playing", allowing tracking of non-Crysis Wars servers too.
- The system now checks if the user's email address is banned. This is because a user can register multiple accounts with the same email address, previously we were checking if only the account they're using is banned- now if one of their accounts is banned, they all are.
- Switched to test-driven development- I use this at work and it's awesome... TDD means that if there are no assertions thrown in the code then it's doing what it's supposed to, which simplifies the testing process by quite a bit.
Under Wildfire4Linux, the Wildfire Core service module crashes. Under further inspection this appears to be a stack overflow, which points to likely some counter overflowing.
This is likely a regression from network statistic tracking within the Ceres module (the Wildfire component for system logs).
For this fix:
I am hoping that the above will resolve this issue (some of the obsolete code still runs and dates back to 2015, so this needs to be addressed). As you may know, back in January 2019 I said that I would no longer be actively supporting the Wildfire system (especially now as I work full-time as a software engineer) but I will pledge to fix this issue as it is long-standing (the first report was #2 in 2017) but will not be adding further features unless absolutely required.
I can't say when the issue will be fixed (because as above I work with code as my full-time job now, so going home and working on this won't be happening, if any progress is made it'll be on weekends)- I am hoping to have this fixed within the next month or so though.