отладить переполнение стека в окнах?
попробуйте указать полный путь от python3, а затем обновите строку crontab, указав полный путь к python3, например ...
* * * * * cd /Users/james/Desktop/elearning && /usr/bin/python3 manage.py expire_lesson
5 ответов
Управлять тем, что Windows делает в случае нарушения прав доступа (SIGSEGV- эквивалентный), звонить SetErrorMode (передайте его параметр 0 для принуждения всплывающего окна в случае ошибок, позволив Вам присоединить к нему с отладчиком.)
Однако на основе отслеживания стека Вы уже получили, присоединение с отладчиком на отказе не может привести ни к какой дополнительной информации. Или Ваш стек был поврежден, или глубина рекурсии превысила максимальное количество кадров, визуализуемых VS. В последнем случае можно хотеть уменьшиться, размер стека по умолчанию процесса (используйте /F переключитесь или эквивалентная опция в Свойства проекта), чтобы заставить проблему проявиться раньше и удостовериться, что VS отобразит все кадры. Можно, альтернативно, хотеть засунуть точку останова в станд.:: basic_filebuf <>:: сброс () и обход через него до фазы разрушения (или отключают его до только до фазы разрушения.)
Ну, Вы знаете то, что распараллеливает проблему, идет - это мог бы быть простой вопрос трассировки через него от начала для наблюдения, куда это уходит в сорняки.
Другая опция состоит в том, чтобы использовать один из отладчиков в Средствах отладки для пакета Windows - они могут показывать больше, чем отладчик VS (возможно), даже если они являются обычно более сложными и трудными использовать (на самом деле, возможно, из-за этого).
Это действительно на первый взгляд походит на бесконечную рекурсию, Вы могли попытаться поместить точку останова в строку перед той, которая завершает процесс. Это добирается там хорошо? Если это делает, у Вас есть два довольно простых способа пойти.
Любой Вы просто выходите вперед и видите, какие деструкторы называют и когда это схвачено. Или Вы могли поместить printf/OutputDebugString в каждый деструктор соответствующих объектов (Только, которые являются globals, должен нуждаться в этом). Если сообщение является первой вещью, деструктор делает, то последнее сообщение, которое Вы видите, от деструктора, который зависает вещи.
С другой стороны, если это не добирается до той точки останова, я первоначально упомянул, затем могу сделать что-то подобное, но это будет более раздражающим, так как программа все еще "делает материал".
Я не управлял бы туда быть таким обработчиком в Windows, но я никогда не слышал о нем.
Я думаю traceback, который Вы показываете, может быть поддельным. При вторжении в процесс после того, как некоторое повреждение уже произошло, то traceback не обязательно допустим. Однако, если Вы удачливы, что нижняя часть отслеживания стека все еще имеет некоторые подсказки о том, что продолжается.
Попытайтесь поместить Sleep() вызовы в выбранные функции в Вашем источнике, который мог бы быть вовлечен в рекурсию. Это должно дать Вам лучший шанс вторжения в процесс, прежде чем стек полностью переполнился.
Я соглашаюсь с Dan Breslau. Ваш стек является поддельным. может быть просто, потому что у Вас нет правильных символов, все же. Если программа просто исчезает без WER, обрабатывающего умирание, это обычно из условия памяти. Вы пошли исследованные та возможность?