Отдельно он и у меня работает. Пробовал баловаться с флагами -MD, -MT.
Исключение происходит в конструкторе класса.

Создается объект класса, внутри себя он подключается куда я ему сказал.
[Перед вызовом методов хочу поместить проверку на наличие ошибок в экземпляре класса, метод getLastError() const возвращает мне номер ошибки]
Затем я вызываю его методы и они запрашивают определенную инфу с сервера.
Удаляю объект.

P.S: В качестве граф. оболочки для приложения использую QT4. Все статически линкуется.

Проделал след. опыт: в конце функции, в которой создается экземпляр моего класса, я добавил:

    boost::asio::io_service io_service;
    boost::system::error_code ec;
    udp::resolver resolver(io_service);
    udp::resolver::query query(udp::v4(), "bad_hostname", "27015");
    udp::resolver::iterator resolve_iter = resolver.resolve(query, ec);

дабы сгенерировать исключительную ситуации на подобие той, что возникает в конструкторе.

Однако это не вызвало вылет программы, ошибка записалась и приложение продолжило работу.
Я не могу понять почему все именно так.

Все решилось довольно просто.
Как я понял, проблема возникала из-за использования моего недопиленного костыля:

ADDRESS* get_addr(char *address){
    
    ADDRESS *ptr = new ADDRESS;
    ptr->host = address;
    // Require optimization!
    char *p;
    if( !(p = strrchr(address, ':')) )
        ptr->port = p = 0;
    else{
        ptr->port = p + 1;
        *p = '\0';
    }
    return ptr;
}

Видимо внутри себя он(resolver.resolve) что-то делал такое с этими указателями, что вызывало исключительную ситуацию.
Я посмотрел на конструкторы udp::resolver::query, и обнаружил:

Внес исправления:

udp::resolver::query query(udp::v4(), 
            boost::lexical_cast<std::string>(host),
            boost::lexical_cast<std::string>( !port ? "27015" : port ) );
        udp::resolver::iterator resolve_iter = resolver.resolve(query, error_code);
        
        if( !(lastError = error_code.value()) ){/*...*/}

А в функции запроса, я сделал соответствующую проверку:

SE_Query *ptr = new SE_Query(addr->host, addr->port, 600);
    if(ptr->getLastError()){
        ui->label_3->setText(QString::fromLocal8Bit("Сервер не ответил"));
        return;
    }

Возник еще вопрос. Если я пытаюсь перед выходом из функции удалить объект ptr - ошибка. Если я пытаюсь использовать boost::scoped_ptr - ошибка.
Не получается освободить ресурсы. У меня конечно есть идея: создать boost::shared_ptr объект, поместить его в класс MainWindow, а в этой функции лишь .. ну вы поняли. Вобщем переложить работу с памятью для класса SE_Query на умный указатель и вынести его за пределы функции.

Ну а если в целом, то все работает. Осталось лишь утечки памяти отловить.

Забыл:

Если пытаюсь удалить в блоке if(ptr->getLastError()), в конце самой функции конечно идет удаление этого объекта.

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

Класс - http://paste.org.ru/?fp5vdp
Функция запроса - http://paste.org.ru/?govnp0

а на входе что подаёшь?
host может оказаться нулевым. это не учтено, я не знаю, что выдаст lexical_cast на нулевой указатель. но это мелочи.
в деструкторе SE_Query делается попытка удалить указатели:

delete endpoint_;
    delete socket_;
    delete deadline_;

а они запросто могут быть нулевыми, ибо в конструкторе не все пути их инициализируют.

Тоже сначала так подумал, сделал все с if'ами, однако крах программы все равно происходил. Именно это меня и смутило.


Эту проблему полностью решил lexical_cast.

UPD:
Реакция венды на delete ptr перед return; .

http://ompldr.org/vOWo3Mg/crashh.png

по-моему, он там вообще не требуется. стандартный конструктор std::string жрёт char* на входе без проблем. если бы дело было в скорости, было бы ещё понятно, но тут она явно не приоритетна, ибо операции разовые. а lexical_cast как раз имеет свойство кидать эксепшны и в норме его всегда нужно оборачивать в try-catch.


дык, оно вообще не информативно. абсолютно пустое сообщение венды, чисто для юзера. если бы там хоть подробности были раскрыты - тогда ещё бы что-то было ценное.

Сообщение отредактировал Iron Bug - 18.7.2011, 22:50

Я в подтверждение моих слов, что даже не критикал эррор.
А lexical_cast использовал, тк он первым на ум пришел. Какие данные не подставлял ему, все корректно было.