как Вы диагностируете ядро ой?
HTTP::HTTP(const string& adress)
{
Poco::URI uri(
adress.substr(0, 4) == "http" ? adress : "http://" + adress
);
HTTPClientSession session{ uri.getHost(), uri.getPort() };
}
Последняя строка в этом конструкторе создает локальную переменную с именем session, ... которая немедленно уничтожается при возвращении конструктора и не имеет ничего общего с членом класса того же члена.
Итак, когда все сказано и сделано, член session этого экземпляра класса остается неинициализированным. Для сравнения:
session = HTTPClientSession{ uri.getHost(), uri.getPort() };
Вместо этого правильно будет инициализироваться член класса, как было указано в вашем очевидном намерении. Однако, поскольку HTTPClientSession не имеет пригодного для использования оператора присваивания, ваша единственная возможность - либо продолжать использовать unique_ptr, либо реструктурировать конструктор так, чтобы он создавал член класса в своем списке инициализатора.
3 ответа
ООП дает набор информации, полезной в диагностировании катастрофического отказа. Это запускается с адреса катастрофического отказа, причина ("доступ плохой области") и содержание регистров. Трассировка вызовов отвечает на вопрос, "как мы добирались здесь". Первый объект в списке произошел последний раз. Работая назад, прерывание произошло (do_IRQ), потому что адаптер Atheros WiFi получил пакет (ath_rx_poll). Стандартная программа передала его универсальному коду WiFi (ieee80211_input), который в свою очередь передал его до сетевого стека (netif_receive_skb).
Для выяснения точного кода, вызывающего проблему, можно выполнить
gdb /usr/src/linux/vmlinux
и затем демонтировать рассматриваемую функцию, которая могла бы быть mesh_packet_in(). Мог бы, потому что дающая сбой инструкция (0xc50659ec) надеется быть за пределами mesh_packet_in() (0xc5065f04). Вы могли бы также попробовать gdb команду
(gdb) info line 0xc50659ec
для выяснения, какая функция содержит этот адрес.
Необходимо сначала попытаться найти источник кода, который отказал. В конкретном случае анализ утверждает, что катастрофический отказ произошел в mesh_packet_in manet драйвера при смещении 0x8f0. Это также сообщает, что инструкции в этой точке 419d02a0 98010009... Поэтому осмотрите модуль с "objdump-d", чтобы подтвердить, корректна ли функция/смещение, о которой сообщают. Затем проверьте источник на то, что он делает; можно использовать список регистров, чтобы подтвердить снова рассмотрение правильной инструкции.
, Когда Вы знаете, какой оператор C дает сбой, необходимо считать источник для обнаружения, куда поддельные данные прибывали из.
http://oss.sgi.com/projects/kdb/
Установка это в Ваше ядро, затем когда это ООП, Вы будете брошены в подобный gdb интерфейс, с которым можно ввести по абсолютному адресу вокруг. Однако похоже, что manet модуль является deref'ing неверный указатель.