AliasAlreadyTaken reports: instrument_mod of debuggery do ... #5746
Labels
No Label
1. kind/balancing
1. kind/breaking
1. kind/bug
1. kind/construction
1. kind/documentation
1. kind/enhancement
1. kind/griefing
1. kind/invalid
1. kind/meme
1. kind/node limit
1. kind/other
1. kind/protocol
2. prio/controversial
2. prio/critical
2. prio/elevated
2. prio/good first issue
2. prio/interesting
2. prio/low
3. source/art
3. source/client
3. source/engine
3. source/ingame
3. source/integration
3. source/lag
3. source/license
3. source/mod upstream
3. source/unknown
3. source/website
4. step/approved
4. step/at work
4. step/blocked
4. step/discussion
4. step/help wanted
4. step/needs confirmation
4. step/partially fixed
4. step/question
4. step/ready to deploy
4. step/ready to QA test
4. step/want approval
5. result/cannot reproduce
5. result/duplicate
5. result/fixed
5. result/maybe
5. result/wontfix
ugh/petz
ugh/QA main
ugh/QA NOK
ugh/QA OK
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: your-land/bugtracker#5746
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
AliasAlreadyTaken reports a bug:
Player position:
Player look:
Player information:
Player meta:
Log identifier
Profiler save:
Status:
Teleport command:
Compass command:
it's working fine for me locally:
i've discovered that it doesn't work specifically for yl_statuseffects for reasons i don't understand, i'm investigating.
the problem was with structure of the yl_statuseffects, not with anything in debuggery. possibly this can be closed. see comments in #5747
Let's keep it open for testing, even though the culprit has changed :D
Do we have similar mods that cannot be profiled properly?
i need to audit my mods; it follows a pattern i know i've used repeatedly. i'm considering it an antipattern now, but i'm not sure what the best way to fix it is in general. i used that pattern as a marginal performance improvement in some places, and to improve legibility in others.
Shall we count this issue OK if it can instrument yl_statuseffects now? Coz a whole audit of your whole mods or even the whole of YL seems out of scope.
What's this antipattern though? Localizing a table?
Btw I still can't get it to be instrumented, but neither can I see any other. Am I doing something wrong? I sent
/instrument_mod yl_statuseffects
, it told me it would do so now and I can see in the log all the functions that are now meant to be instrumented, but neither the log nor ingame says anything about usage?that seems reasonable. it's going to be a lot of work to fix all the other places where i store local references to functions.
yup, local reference to a table of functions, or to the functions themselves
hm, i'll look into it
when i do this locally, i get:
When I do this I get
Waiiiit.
2024-01-29 09:35:25: ACTION[Server]: [debuggery] instrumenting "yl_statuseffects.log"
I can't find that file? Where does it go to?
that's a function, not a file
hmmmmmmmmmm you're certain it's the right version of yl_statuseffects installed? i have no other idea.
lolol, I'm an idiot
Maybe a setting? Wrong log level?
yl_statuseffects is on this commit: 540ccfcca46e9e362b66cfeaf324891590ca68f9
alright, same here...
the logs are all at the "action" level, so that can't be it. there's no relevant setting.
does it work if you try to instrument a different mod?
No. I tried areas, I even tried "minetest". It says it will now go ahead and isntrument all of it, then doesn't. Or at least not reveal to the log what it does.
this is happening on the test server or the main server?
This happens on the testserver, with latest updates to the mods involved.
i've got no real idea why this is failing. i'm probably going to ignore this for a while in favor of trying to fix the major issues with ballistics/y_bows.
If it works for you, but doesn't for me, then there must be some difference. I'll try to reduce modset and find a workable solution, but it's certainly not high prio atm
Wellll, if one looks at the right spot, the stuff does get instrumented.
For future reference and especially for smol brain Alias: It's the debug.txt, stupid!
NOT the usual Minetest_live.out log
That's how it looks like:
2024-02-28 23:13:14: INFO[Server]: [debuggery] [instrument_mod] in 1027442us,
2024-02-28 23:13:14: INFO[Server]: [debuggery] [instrument_mod] areas.canInteract was called 1 times, used 325 us
2024-02-28 23:13:14: INFO[Server]: [debuggery] [instrument_mod] areas.getAreasAtPos was called 5 times, used 43 us
2024-02-28 23:13:14: INFO[Server]: [debuggery] [instrument_mod] areas.getExternalHudEntries was called 2 times, used 3 us
2024-02-28 23:13:14: INFO[Server]: [debuggery] [instrument_mod] areas.get_banned_players was called 4 times, used 7 us
instrument_mod from debuggery is just using
minetest.log
ultimately - i have no idea how or why it's not showing up in the console log.hm i should at least check if it shows up in my local server console output tho
i can't validate whether this is live on main
I can see it logging to the debug.txt, IMO it should log to where minetest.log writes to as well. Still, it works nicely :)
i still don't understand why something would log to debug.txt but not the console, outside of logging levels. this message is logged at "action" level - maybe the console is only logging warning or above? i'm pretty sure that's not the case though?