2016-12-17 5 views
0

My app (java based) запускает python для Windows, который, в свою очередь, вызывает os.spawnv для запуска другого питона.Как отлаживать нарушение доступа, которое оно выбрасывает из библиотеки windows ucrtbase?

Время от времени у меня возникает исключение из-за нарушения доступа.

00 005eedb0 763e68f3 ucrtbase!<lambda_7d9ee38b11181ddfdf5bd66394e53cb7>::operator()+0x1b 
01 005eedfc 763e65d9 ucrtbase!construct_environment_block<char>+0xdb 
02 005eee14 763e7aba ucrtbase!common_pack_argv_and_envp<char>+0x31 
03 005eeebc 763e778a ucrtbase!execute_command<char>+0x62 
04 005eeee8 763e8066 ucrtbase!common_spawnv<char>+0x13f 
05 005eeef8 65a323d7 ucrtbase!_spawnve+0x16 
06 005eef38 65a360c6 python35!os_spawnve_impl(int mode = 0n0, struct _object * path = 0x03adfde0, struct _object * argv = 0x03b258a0, struct _object * env = 0x03b25a80)+0x1a7 [c:\build\cpython\modules\posixmodule.c @ 5299] 

Я установил п.н. на c:\build\cpython\modules\posixmodule.c @ 5299 и вот что я вижу в источниках питона

Py_BEGIN_ALLOW_THREADS 
spawnval = _spawnve(mode, path_char, argvlist, envlist); 
Py_END_ALLOW_THREADS 

Я проверил все аргументы дважды: они в порядке. mode is 0, path_char - это путь к моему интерпретатору, argvlist и envlist оба являются char**: массивы с NULL-концами строк с NULL-тимированием.

Таким образом, это не ошибка python.

Я знаю, что _spawnve не является потокобезопасным, но есть только одна тема.

У меня нет источников или частных символов для MS ucrtbase. Каков правильный подход к его исследованию?

-

В чем разница между ucrtbased.dll и ucrtbase.dll? Должен ли я компилировать Python против ucrtbased.dll, чтобы найти больше символов?

+1

В сборке отладки используются файлы ucrtbased.dll и python35_d.dll. Использование отладочной сборки должно облегчить задачу поиска. Попробуйте '! Anal -v'. – eryksun

+1

У вас должен быть источник для CRT, установленного с Visual Studio 2015. Например, я вижу определение 'construct_environment_block' в« C: \ Program Files (x86) \ Windows Kits \ 10 \ Source \ 10.0.10586.0 \ ucrt \ Exec \ cenvarg.cpp». – eryksun

+1

Источники Crt и частные приходят в sdk/wdk под папкой src в дереве vc – blabb

ответ

0

Я только что столкнулся с той же проблемой при попытке построить SciPy; нарушение прав доступа выбрано как часть setup.py, пытающегося выполнить spawnve() компилятор C.

Я еще не получил его до конца, но, по крайней мере, поступил в разборку. Вот что происходит:

  • Calls get_environment_from_os() который дает указатель на переменные окружения текущего процесса.

  • Перебирает этот список строк с завершающим нулевым ищет переменные окружения, имя которых начинается с «=»

  • Видимо это способ Windows в экспрессировать набор текущих каталогов, например, должна быть переменная окружения «=c:» со значением, как «c:\mystuff»

  • Он никогда не находит и не отправляется в неинициализированную память в своем бесполезном квете.

  • Boom.

Проверка адреса памяти, возвращаемой get_environment_from_os() показывает мне довольно вменяемый смотрит список переменных окружения, но ни один из которых ключ не начинается с «=» характер.

Я все еще вникаю в то, почему и как все происходит в этом состоянии; это не всегда происходит, что заставляет меня подозревать темы, но, как и вы, я не могу найти никаких доказательств, подтверждающих это; хотя у меня нет интимных знаний о том, как работает distutils.

0

Aha! Тайна решена.

См. https://bugs.jython.org/issue29908 для деталей, но в основном spawnve() не работает. Он полагается на эти секретные текущие переменные среды каталога, которые начинаются с = и, скорее всего, будут разбиваться, если среда их не содержит.

cmd.exe и explorer.exe установить их при запуске процессов, но если запустить процесс самостоятельно с ограниченной средой, которая не включает их, то, что сам процесс пытается вызвать spawnve() вы направляетесь к краху земли.

Обходным путем является установка как минимум одной переменной окружения, соответствующей шаблону; например =c:=pants, и вы хороши.

 Смежные вопросы

  • Нет связанных вопросов^_^