Skip to content

Fixed server crash via @reloadpcdb#3377

Open
MrKeiKun wants to merge 1 commit into
HerculesWS:masterfrom
MrKeiKun:fix-2811-servercrash
Open

Fixed server crash via @reloadpcdb#3377
MrKeiKun wants to merge 1 commit into
HerculesWS:masterfrom
MrKeiKun:fix-2811-servercrash

Conversation

@MrKeiKun

Copy link
Copy Markdown
Contributor

Pull Request Prelude

Changes Proposed

Issues addressed: #2811

@hemagx hemagx left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

From your asan report (I would prefer a crash dump), it says it was a use after free, which means it was free'd else where, why it's not being nulled there and why it's a seperate function? I need more explanation here please.

@hemagx hemagx added this to the Release v2026.05 milestone May 24, 2026
@MrKeiKun

MrKeiKun commented Jun 7, 2026

Copy link
Copy Markdown
Contributor Author

From your asan report (I would prefer a crash dump), it says it was a use after free, which means it was free'd else where, why it's not being nulled there and why it's a seperate function? I need more explanation here please.

Why not nulled in pc_clear_exp_groups where the free happens?

pc_clear_exp_groups only owns and manages the VECTOR storage — it frees the exp arrays inside each class_exp_group entry and clears the vectors. It has no knowledge of class_exp_table, and by design it shouldn't: class_exp_table is a separate non-owning pointer array that acts as a class-indexed lookup into those vectors, and it is populated not by any function in pc.c but by status->read_job_db() in status.c. The two are in different abstraction layers — one owns the data, the other indexes it. Coupling pc_clear_exp_groups to nulling a lookup table it doesn't populate would mean it needs to know about a side effect that belongs to a different module.

Why a separate function?

Because the clear of class_exp_table needs to explicitly mirror its repopulation by status->read_job_db(). In pc_readdb the sequence is now: clear the lookup → free the storage → reload storage → repopulate the lookup. Making it a named function pointer in the pc interface keeps that intent readable and also follows the existing HPM hook pattern of the codebase, so plugins can override it if needed. An alternative would have been to inline the null loop directly in pc_readdb, but a named function makes the symmetry with read_job_db more obvious.

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