-
Notifications
You must be signed in to change notification settings - Fork 23
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
y_hooks funky parameter counts #57
Comments
Can you add a repro? |
So... do you have an example script? |
#include <a_samp>
#include <YSI_Coding\y_hooks>
hook FakeCallback(c[32], d)
{
printf("%d %d", BAD_numargs(), numargs());
// Force a crash.
c[d] = 42;
}
main()
{
new arr[32];
CallLocalFunction("FakeCallback", "ai", arr, 100);
} Gives:
|
Although that doesn't actually look right, I'm not sure why it is reporting 1073741813. y_hooks pushes It took me a long time looking at this, but my code is reporting |
Thanks, I will look into it 👍 |
Print first 10 argumenmts regardless of whether they are variadic or named (fixed). Before this only named arguments used to be printed with debug info loaded, but without debug info up to 10 arguments were printed, including variadic arguments, which can useful to see sometimes. So fix this unfairness by always printing first 10 arguments, with or without debug info. This is related to #57.
I think it should work better now after the recent commits, though maybe not ideal before:
after:
|
Looks correct to me. What's not ideal about it? |
I mean this:
I guess it's fine, they are shown in the frame above anyway |
Functions that begin with |
Ahh I see. Well that's a runtime generated function, so it makes sense that it has no debug information. So this is brilliant thanks. |
OK. |
Yes they are publics, but those ones get removed from the publics table to free up space for new generated names. |
Basically, y_hooks does all sorts of crazy things to the assembly to work. |
y_hooks does some unusual manipulation of parameter counts - using a negative number so that
RETN
actually puts data back ON to the stack instead of removing it. When there is a crash, it means this outputs things like:This is not a bug in crashdetect - it is correctly reporting what it is told. However, it would be nice if it knew of this quirk and could walk the stack a bit more to get the real parameter count. If the parameter count is negative, the parameter count for the current function will be equal to the parameter count of the previous function (which is a small shim generated by y_hooks). Unless, of course, there is a different bug that is just corrupting the parameter count and the strange number is just wrong and nothing to do with y_hooks, in which case this adaptation won't help.
The text was updated successfully, but these errors were encountered: