Raised This Month: $12 Target: $400
 3% 

Planned SourceHook changes


Post New Thread Reply   
 
Thread Tools Display Modes
PM
hello, i am pm
Join Date: Jan 2004
Location: Canalization
Old 05-30-2007 , 08:14   Re: Planned SourceHook changes
Reply With Quote #11

Hello dear human being,

if I recall correctly, SH_MANUALHOOK_RECONFIGURE expects a vtable index, a vtable offset, and a this pointer offset; not a vtable pointer.

Quote:
I passed into that stuff a pointer to the vtable obtained from dlsym() and the vfunc index.
Ah, so you have a vtable pointer and an index. And you want a VP hook. In this case, I guess this is the correct way to do it:

Code:
// First, declare a manual hook
SH_DECL_MANUALHOOK*(MyHook, [your vtable index here], 0, 0 [, possibly parameters and rettype etc] );

// If you do not know the vtable index at compile-time, pass some dummy value (probably something big like 0xdeadbeef so that you get immediate crashes if you forget to set it later) to SH_DECL_MANUALHOOK and later do:
// SH_MANUALHOOK_RECONFIGURE(MyHook, [your vtable index], 0, 0);
// do NOT pass vtable pointers to SH_MANUALHOOK_RECONFIGURE !

// Then, retreive the vtable pointer, and do this:
int hookid = SH_ADD_MANUALDVPHOOK(MyHook, [your vtable pointer here], [your handler], [pre/post]);
If that gives you crashes, please post / private message the relevant parts of your code as it may be a pretty serious bug

Thank you very much,
PM

EDIT:
Ah, yes, you are right, testvphooks.cpp is only in the MSVC 7.1 project file; I won't add it to the 8.0 file because I don't have a Visual Studio version which could open such files and I'm also afraid of editing them manually. If you could send me the original 8.0 file with added testvphooks.cpp, I'd be very thankful
__________________
hello, i am pm

Last edited by PM; 05-30-2007 at 09:16.
PM is offline
mooman2
Member
Join Date: Apr 2007
Old 05-30-2007 , 17:33   Re: Planned SourceHook changes
Reply With Quote #12

Ok, I'll try passing in the vfunc index at compile time rather then at load.

And here's the VS8.0 vcproj including testvphooks.cpp
Attached Files
File Type: rar test.rar (1.7 KB, 129 views)
mooman2 is offline
PM
hello, i am pm
Join Date: Jan 2004
Location: Canalization
Old 05-30-2007 , 17:37   Re: Planned SourceHook changes
Reply With Quote #13

Quote:
Originally Posted by mooman2 View Post
Ok, I'll try passing in the vfunc index at compile time rather then at load.

And here's the VS8.0 vcproj including testvphooks.cpp
:O shouldn't be a problem; could you post your original DECL and RECONFIGURE and ADD_HOOK lines please?
__________________
hello, i am pm
PM is offline
mooman2
Member
Join Date: Apr 2007
Old 05-30-2007 , 18:08   Re: Planned SourceHook changes
Reply With Quote #14

Ok, I just tried again with passing the index in manually and it still didn't work.

On the mod Zombie Master, I tried this originally and it crashed whenever I shot a zombie:

Code:
SH_DECL_MANUALHOOK2(BecomeRagdoll_hook, 0, 0, 0, bool, CTakeDamageInfo const&, Vector const&);

SH_MANUALHOOK_RECONFIGURE(BecomeRagdoll_hook, idxBecomeRagdoll, 0, 0);
        
BecomeRagdollHook = SH_ADD_MANUALDVPHOOK(BecomeRagdoll_hook, vtblCNPC_BaseZombie, SH_STATIC(BecomeRagdoll_handler), false);
If it also interests you, I tried hooking CBasePlayer::Weapon_Equip using what you told me to do in the latest post and that also crashed whenever I shot a zombie.

EDIT: It could be a problem with sourcehook backwards compatability since I'm also using deprecated methods to hook stuff DispatchEffect.

RE-EDIT: Ok, I definitely think it's a problem with sourcehook backwards compatability. CentOS server is running MM:S 1.5. I add a plugin that uses 1.4 methods to hook ITempEntsSystem:: DispatchEffect. It crashes whenever I shoot something that uses DispatchEffect. Now I comment out the DispatchEffect hooks and reload the plugin and it doesn't crash.

YET ANOTHER EDIT: I figured out its not the hooks causing the crash, but deprecated callclasses which I think are supposed to still be backwards-compatible?

EDIT #2415: after fixing the crash and trying a lot of random stuff, I still can't get DVPHOOK to work. Does it really not need a pointer to an already existing instance?

Last edited by mooman2; 05-31-2007 at 02:39.
mooman2 is offline
PM
hello, i am pm
Join Date: Jan 2004
Location: Canalization
Old 05-31-2007 , 04:29   Re: Planned SourceHook changes
Reply With Quote #15

Quote:
Originally Posted by mooman2 View Post
Ok, I just tried again with passing the index in manually and it still didn't work.

On the mod Zombie Master, I tried this originally and it crashed whenever I shot a zombie:

Code:
SH_DECL_MANUALHOOK2(BecomeRagdoll_hook, 0, 0, 0, bool, CTakeDamageInfo const&, Vector const&);

SH_MANUALHOOK_RECONFIGURE(BecomeRagdoll_hook, idxBecomeRagdoll, 0, 0);
        
BecomeRagdollHook = SH_ADD_MANUALDVPHOOK(BecomeRagdoll_hook, vtblCNPC_BaseZombie, SH_STATIC(BecomeRagdoll_handler), false);
If it also interests you, I tried hooking CBasePlayer::Weapon_Equip using what you told me to do in the latest post and that also crashed whenever I shot a zombie.

EDIT: It could be a problem with sourcehook backwards compatability since I'm also using deprecated methods to hook stuff DispatchEffect.

RE-EDIT: Ok, I definitely think it's a problem with sourcehook backwards compatability. CentOS server is running MM:S 1.5. I add a plugin that uses 1.4 methods to hook ITempEntsSystem:: DispatchEffect. It crashes whenever I shoot something that uses DispatchEffect. Now I comment out the DispatchEffect hooks and reload the plugin and it doesn't crash.

YET ANOTHER EDIT: I figured out its not the hooks causing the crash, but deprecated callclasses which I think are supposed to still be backwards-compatible?

EDIT #2415: after fixing the crash and trying a lot of random stuff, I still can't get DVPHOOK to work. Does it really not need a pointer to an already existing instance?
Whoa, that doesn't sound healhty.
I'll try to reproduce your situation here, so I'll have to ask some questions in order to get a precise picture of what is going on

Are you running only this plugin? Or also other plugins (which hook the function in question?)

Does your plugin use deprecated callclasses (SH_GET_CALLCLASS and stuff)? And then SH_CALL on them crashes? Do you do this when there is a hook on the function? Also, is the plugin which causes the callclass-related crashes compiled against 1.5 or 1.4 headers? Thanks
EDIT: Does it crash if you have a plugin running which "uses 1.4 methods to hook DispatchEffect"? Was that plugin compiled against the 1.4 SDK? Or was it recompiled? (it is important that not-recompiled plugins don't crash) Or does it only crash if you have BOTH your new plugin and an old plugin running?

It could be possible that I've made some error when writing those source backwards compat quirks.... I'm not sure yet, I'll have to test it.

However it worries me that you can't get VP hooks working :-O
There are two kinds of VP hooks:

normal VP hooks expect a pointer to an already existing instance (internally, they add the thispointeroffset and vtable offset to the this pointer, then dereference this computer "vtable pointer pointer" and use that as a direct VP hook. the thispointeroffset and vtable offset are either given manually (manual hook) or are discovered automatically from a member function pointer (non-manual hook) ).

direct VP hooks expect a pointer to the vtable. They only do vtable[vtblidx] in order to refer to the virtual function pointer then. This means that vtblidx is not the offset from the vtable beginning, but the offset / sizeof(void*), but you probably know that anyway.

/* It is important that the function/"method" you want to hook is called through this vtable (ie. it is possible that you hook a function in one vtable; but a derived class has its own vtable and thus when someone calls baseClassPointer->Function() and baseClassPointer is in fact a pointer to a derived class which overrides one or more functions from the base class (and it doesn't matter if the function is the function you are hooking or not) your hook will not be called). But you are probably doing that correctly as BaseZombie doesn't appear to be the lowest base class having a virtual BecomeRagdoll member. */ (EDIT2: I took a look at the SDK and found out that what I wrote here was unimportant for this discussion)

The source-level backwards compatibility callclasses are only template hacks so that old plugins compile without changing code; basically SH_GET_CALLCLASS stores the this pointer in some fake callclass instance and then SH_CALL extracts it again. So it should be the same as calling SH_CALL with the this pointer directly unless I've made some fault on the way.

Sorry for my confusion, it's early in the morning ;)
__________________
hello, i am pm

Last edited by PM; 05-31-2007 at 04:41.
PM is offline
mooman2
Member
Join Date: Apr 2007
Old 05-31-2007 , 10:27   Re: Planned SourceHook changes
Reply With Quote #16

Quote:
Originally Posted by PM View Post
Whoa, that doesn't sound healhty.
I'll try to reproduce your situation here, so I'll have to ask some questions in order to get a precise picture of what is going on

Are you running only this plugin? Or also other plugins (which hook the function in question?)

Does your plugin use deprecated callclasses (SH_GET_CALLCLASS and stuff)? And then SH_CALL on them crashes? Do you do this when there is a hook on the function? Also, is the plugin which causes the callclass-related crashes compiled against 1.5 or 1.4 headers? Thanks
EDIT: Does it crash if you have a plugin running which "uses 1.4 methods to hook DispatchEffect"? Was that plugin compiled against the 1.4 SDK? Or was it recompiled? (it is important that not-recompiled plugins don't crash) Or does it only crash if you have BOTH your new plugin and an old plugin running?

It could be possible that I've made some error when writing those source backwards compat quirks.... I'm not sure yet, I'll have to test it.

However it worries me that you can't get VP hooks working :-O
There are two kinds of VP hooks:

normal VP hooks expect a pointer to an already existing instance (internally, they add the thispointeroffset and vtable offset to the this pointer, then dereference this computer "vtable pointer pointer" and use that as a direct VP hook. the thispointeroffset and vtable offset are either given manually (manual hook) or are discovered automatically from a member function pointer (non-manual hook) ).

direct VP hooks expect a pointer to the vtable. They only do vtable[vtblidx] in order to refer to the virtual function pointer then. This means that vtblidx is not the offset from the vtable beginning, but the offset / sizeof(void*), but you probably know that anyway.

/* It is important that the function/"method" you want to hook is called through this vtable (ie. it is possible that you hook a function in one vtable; but a derived class has its own vtable and thus when someone calls baseClassPointer->Function() and baseClassPointer is in fact a pointer to a derived class which overrides one or more functions from the base class (and it doesn't matter if the function is the function you are hooking or not) your hook will not be called). But you are probably doing that correctly as BaseZombie doesn't appear to be the lowest base class having a virtual BecomeRagdoll member. */ (EDIT2: I took a look at the SDK and found out that what I wrote here was unimportant for this discussion)

The source-level backwards compatibility callclasses are only template hacks so that old plugins compile without changing code; basically SH_GET_CALLCLASS stores the this pointer in some fake callclass instance and then SH_CALL extracts it again. So it should be the same as calling SH_CALL with the this pointer directly unless I've made some fault on the way.

Sorry for my confusion, it's early in the morning ;)
I am currently running BAT, one other plugin compiled for 1.4, and this plugin.

This is the only plugin that hooks this stuff.

Yeah, my plugin uses SH_GET_CALLCLASS, but that doesn't make it crash- it's when SH_CALL's first parameter is that callclass. To fix it I changed it to the actual interface.

Yes, I do this inside a hook.

I compiled this against 1.5 headers.

Quote:
EDIT: Does it crash if you have a plugin running which "uses 1.4 methods to hook DispatchEffect"? Was that plugin compiled against the 1.4 SDK? Or was it recompiled? (it is important that not-recompiled plugins don't crash) Or does it only crash if you have BOTH your new plugin and an old plugin running?
I can't remember exactly, but I have old versions compiled against 1.4 which do the same thing and I'll see if they crash on 1.5.

What do you suggest I do to try and fix it?

Last edited by mooman2; 05-31-2007 at 22:27.
mooman2 is offline
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -4. The time now is 14:41.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Theme made by Freecode