[Решено] Самопроизвольный краш клиента при отладке пида

[Pavel3333]

При работе пида клиент самопроизвольно крашится.

 

референсов на PyObject в коде практически нет, просто отлаживаю с помощью PySys_WriteStdout() функцию по преобразованию строки в структуру.

 

Иногда успевает завершиться код, иногда нет. Даже если он достигает return Py_None, клиент 100% крашится.

В коде часто используются memset/memcpy, хотя не думаю, что они на что-то влияют.

Edited May 4, 2018 by Pavel3333

[Mixaill]

Собственно, а что мешает воткнуться в клиент той же самой Visual Studio/WinDbg/IDA и посмотреть где конкретно падает?

Edited May 3, 2018 by Mixaill

[Pavel3333]

@Mixaill пробовал присоединиться к процессу танков. Не смог. Писало что-то вроде "не поддерживается".

 

Сейчас не за компом, последнее что успел выяснить - крашится даже пустая функция с макросом Py_RETURN_NONE.

PS. В VS установлена поддержка Питона. Завтра попробую поплясать с бубном на тему отладки танкового клиента.

[Mixaill]

 Тогда это очень похоже на сборку не тем и не в том режиме. Чтобы работало без проблем, необходимо билдить свою библиотеку

- в Microsoft Visual Studio 2015 / 2017

- в конфигурации Release

[Pavel3333]

@Mixaill компилю в VS 2017 Community последнего обновления, конфигурация релизная. Очень похоже на неправильные свойства проекта, ибо еще вчера я работал на другом компьютере, притом все работало стабильно, а сегодня работаю уже на другом компьютере, синхронизировавшись с репозиторием. Может быть, синхронизация с репозиторием не затронула файлов решения, и из-за этого были старые параметры проекта.

 

Спасибо за совет, буду разбираться завтра.

[Pavel3333]

@Mixaill ситуация та же.

#include "stdafx.h"

#include "API_functions.h"
#include "python27/Python.h"


#define Py_BUILD_CORE 1
#define CONSOLE_VER1

PyObject* trj_get_models(PyObject* self, PyObject* args) {

	Py_INCREF(Py_None);
	return Py_None;
}

static struct PyMethodDef trj_methods[] =
{
	{ "get_models", trj_get_models, METH_VARARGS, "get_models" },
	{ NULL, NULL, 0, NULL}
};

PyDoc_STRVAR(trj_methods__doc__,
	"Trajectory Mod module"
);

PyMODINIT_FUNC inittrj(void)
{
	Py_InitModule4("trj",
		trj_methods,
		trj_methods__doc__,
		(PyObject*)NULL,
		PYTHON_API_VERSION);
};

Компилирую в VS 17, конфигурация Release. Вызываю в питоне без хука, при загрузке игры:

 

print '[TrajectoryMod]: loading module...'
trj_path = PATH.XFWLOADER_PACKAGES_REALFS+'/TrajectoryMod/native/trj.pyd'
trj = imp.load_dynamic('trj', trj_path)
print '[TrajectoryMod]: loading module OK'

print trj.get_models()

Краш.

[SkepticalFox]

2 hours ago, Pavel3333 said:

#define Py_BUILD_CORE 1

такое до инклудов писать надо

2 hours ago, Pavel3333 said:

Компилирую в VS 17, конфигурация Release. Вызываю в питоне без хука, при загрузке игры:

надо вызывать после того, как xfwnative инициализуется

[Mixaill]

3 часа назад, SkepticalFox сказал:

 

#define Py_BUILD_CORE 1

такое писать вообще не надо

[Pavel3333]

14 часов назад, SkepticalFox сказал:

надо вызывать после того, как xfwnative инициализуется

все верно. похоже, вылеты были по этой причине. не успевали дозагрузиться com.modxvm.xfw.mutex, com.modxvm.xfw.xinput, com.modxvm.xfw.console. отложеный запуск функции с задержкой 3 секунды исправил ситуацию.

[Mixaill]

просто дерни самостоятельно 

import mod_xfw_native

 

[Pavel3333]

@Mixaill ок, спасибо.

[Mixaill]

Или грузись через XFW и проставь зависимость от com.modxvm.xfw.native

[Pavel3333]

@Mixaill в xfw_package.json прописано:

{
    "id": "pavel3333.TrajectoryMod",
    "name": "TrajectoryMod",
    "description": "TrajectoryMod",

    "version": "4.0.0.1",
    "dependencies": ["com.modxvm.xfw.native"],
    "features": ["python", "native"],

    "url": "http://pavel3333.ru/trajectorymod/",
    "url_update": "http://pavel3333.ru/trajectorymod/",
    
    "wot_versions"         : [],
    "wot_versions_strategy": "allow_newer"
}