TF2 run_command hook gives bad pointer as second argument when the player in question is a bot

[quartata]

Original thread: http://forums.sourcepython.com/viewtopic.php?f=20&t=1257

Title says it all. Not certain what pointer is getting passed, but it's not pointing to an instance of CUserCmd nor to an instance of CBotCmd. To reproduce, make a new plugin with this code:

from entities.hooks import EntityCondition, EntityPreHook
from memory import make_object
from players import UserCmd

@EntityPreHook(EntityCondition.is_player, "run_command")
def hook(stack):
  print(make_object(UserCmd, stack[1]).buttons)

and add a bot with sv_cheats 1; bot. Currently only been reproduced on TF2 with Linux, other games/platforms may be affected. NextBots (added with tf_bot_add) do not seem to have any problems.

[Ayuto]

What gets printed to the console when you execute the following?

stack[1].type_info.dump()

[quartata]

Segfault. Here's the debug.log: http://pastebin.com/pn9eY8re

[quartata]

I'll try to see if I can reproduce this on DoD:S a little later.

[Ayuto]

Well, the debug.log still mentions MakeObject. Just use this and not more:

from entities.hooks import EntityCondition, EntityPreHook

@EntityPreHook(EntityCondition.is_player, "run_command")
def hook(stack):
    stack[1].type_info.dump()

[quartata]

This was all I had:

from entities.hooks import EntityCondition, EntityPreHook

@EntityPreHook(EntityCondition.is_player, "run_command")
def hook(stack):
    print(stack[1].type_info.dump())

[Ayuto]

The log says something different:
#10 0xebc1c7ab in MakeObject(boost::python::api::object, boost::python::api::object) () from /home/quartata/sourcepythonds/tf/addons/source-python/bin/core.so

[quartata]

I've done it three times now (each time I've removed the pycache, guaranteed that no other plugins were loaded, etc.) and that's what the stacktrace looks like. Maybe dump() calls it?

[Ayuto]

No, it doesn't call it. In the log file there is also this line:

#2  0xebd8eb67 in boost::python::objects::caller_py_function_impl<boost::python::detail::caller<CUserCmd* (*)(CPointer*), boost::python::return_value_policy<boost::python::reference_existing_object, boost::python::default_call_policies>, boost::mpl::vector2<CUserCmd*, CPointer*> > >::operator()(_object*, _object*) () from /home/quartata/sourcepythonds/tf/addons/source-python/bin/core.so

Did you notice the CUserCmd occurence? You definitely run the old plugin.

[quartata]

I added a print statement before the dump() and it showed up in the output right before the segfault. It's not the old plugin.

[Ayuto]

Then please upload the new debug.log. It's impossible to get this output with the snippet I gave you.

[jordanbriere]

CRASH: Thu Jul 14 11:15:12 PDT 2016
Current PDT time: 13:03:49

→ That debug.log is about 2 hours old. Delete the file, and try again.

[quartata]

That 2 hour old log was the first log I got when I ran the snippet plugin. All the other logs I got had identical stacktraces, but for some reason when I deleted the __pycache__ again just now the stack trace changed to something that makes a little more sense: http://pastebin.com/SpVVv9Js

[Ayuto]

L'In20Cible and I came to the conclusion that the passed pointer doesn't has RTTI data. This snippet will work around that issue.

ucmd_size = memory.get_size(UserCmd)

@EntityPreHook(EntityCondition.is_player, "run_command")
def hook(stack):
    ucmd = UserCmd()
    ucmd_ptr = memory.get_object_pointer(ucmd)

    orig_ucmd_ptr = stack[1]
    orig_ucmd_ptr.copy(ucmd_ptr, ucmd_size)

    # You have now read-only access to the user command. Writing any attribute
    # has no effect as it doesn't modify the original user command.
    print(ucmd.buttons)

    # If you want to modify the user command, you need to copy back your work
    ucmd_ptr.copy(orig_ucmd_ptr, ucmd_size)

[Ayuto]

Does this workaround work for you, @quartata?

[quartata]

Yes, it works fine. Thanks.

[jordanbriere]

Thanks for confirming! I guess we can close this issue now, since it is not directly related to Source.Python.