Не знаю, сюда, в КУ или сразу в КСВ...

Через WinDbg удалось понять:
Исключение типа Stack overflow. Всё шло как надо, просто спирит не в состоянии обработать столько.
Крэш как бы намекает на то, что надо переходить с прототипа на спирите на нормальную реализацию.

Здравствуйте, Alexander G, Вы писали:

AG>Не знаю, сюда, в КУ или сразу в КСВ...
+1
Всё-таки в КУ наверное

А окошко внизу -- это call stack?

Здравствуйте, Erop, Вы писали:

E>А окошко внизу -- это call stack?

Ага. К сожалению ни имена методов полностью ни стек целиком не отображается в Студии, пришлось юзать WinDbg для отладки.

Здравствуйте, Alexander G, Вы писали:

AG>Не знаю, сюда, в КУ или сразу в КСВ...

Ты просто не умеешь их готовить
У меня есть специальный перловый транслятор, я через него всегда прогоняю все сообщения компилятора (это автоматически в мейк-файле), стеки от дебаггера и т.п. — выглядит все в результате вполне читабельно.

К тому же в большинстве случаев ошибка у тебя в коде, и библиотечные потроха тебе просто не нужны (поэтмоу в моем скрипте они скрываются, иначе через всякие "instantiated from" невозможно продраться, ну и grep -v никто не отменял.)

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Alexander G, Вы писали:

AG>Через WinDbg удалось понять:
AG>Исключение типа Stack overflow. Всё шло как надо, просто спирит не в состоянии обработать столько.
AG>Крэш как бы намекает на то, что надо переходить с прототипа на спирите на нормальную реализацию.

А ты уверен, что это проблема спирита, а не кривой грамматики, которую ты на нем написал?
Включи отладочный режим (есть специальный макрос на эту тему), посмотри, как именно он парсит все, может, у тебя там просто бесконечная рекурсия (самая распространенная причина Stack overflow)?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Ты просто не умеешь их готовить
J>У меня есть специальный перловый транслятор, я через него всегда прогоняю все сообщения компилятора (это автоматически в мейк-файле), стеки от дебаггера и т.п. — выглядит все в результате вполне читабельно.

Не было необходимости, это единичный случай. У меня нет большого количества "шаблонной магии" в коде, так что проблемы интерпретации диагностики нет. Насчёт сообщений компилятора при ошибках в STL, в bind — то к ним легко привыкнуть. Кстати, в критичном коде бинд вообще не использую.

Этот случай легко разобран WinDbg без хитроумных трансляторов.

Здравствуйте, Alexander G, Вы писали:

AG>Насчёт сообщений компилятора при ошибках в STL, в bind — то к ним легко привыкнуть.
Зачем привыкать, если можно читать по-человечески

AG>Кстати, в критичном коде бинд вообще не использую.

А какие проблемы с bind? Он же инлайнится весь (если ты его в function не сохраняешь, конечно же).

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>А ты уверен, что это проблема спирита, а не кривой грамматики, которую ты на нем написал?
J>Включи отладочный режим (есть специальный макрос на эту тему), посмотри, как именно он парсит все, может, у тебя там просто бесконечная рекурсия (самая распространенная причина Stack overflow)?

Уверен.

Рекурсия в одном месте — такая:

      group = '(' >> +element >> ')';
      element = ...|group;

Здравствуйте, jazzer, Вы писали:

J>А какие проблемы с bind? Он же инлайнится весь (если ты его в function не сохраняешь, конечно же).

Не всегда весь. Ещё, делает несколько лишних копирований, можно упустить копирование чего-то большого.
Если бинд для передачи в for_each — всегда будет лучше BOOST_FOREACH, для более сложного алгоритма можно не полениться написать функтор.

Здравствуйте, Alexander G, Вы писали:

AG>Здравствуйте, jazzer, Вы писали:

J>>А какие проблемы с bind? Он же инлайнится весь (если ты его в function не сохраняешь, конечно же).

AG>Не всегда весь. Ещё, делает несколько лишних копирований, можно упустить копирование чего-то большого.
boost::ref, boost::cref тебя спасет (ну да я уверен, что ты и без меня про них знаешь)

AG>Если бинд для передачи в for_each — всегда будет лучше BOOST_FOREACH, для более сложного алгоритма можно не полениться написать функтор.
BOOST_FOREACH не всеми компиляторами поддерживается, к сожалению

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Alexander G, Вы писали:

AG>Уверен.

Тогда минимальный код, воспроизводящий проблему, в студию
Ну и файл, который нужно распарсить, естественно.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, jazzer, Вы писали:

J>Тогда минимальный код, воспроизводящий проблему, в студию
J>Ну и файл, который нужно распарсить, естественно.

struct dumb_grammar : public boost::spirit::grammar<dumb_grammar>
{
  template <typename ScannerT>
  struct definition
  {
    typedef boost::spirit::rule<ScannerT> rule_t;
    definition(const dumb_grammar& g)
    {
      using namespace boost::spirit;
      symbol = range_p('\x32', '\x7F') - (ch_p('\\')|'('|')');
      group = '(' >> +element >> ')';
      element = symbol|group;
    }

    const rule_t& start(void) const
    {
      return group;
    }

    rule_t symbol, element, group;
  };

};


int _tmain(int argc, _TCHAR* argv[])
{
  size_t size = 1024 * 1024;
  char *p = (char*)malloc(size);
  memset(p, '(', size);
  {
    using namespace boost::spirit;
    dumb_grammar g;
    parse(p, p+size, g);
  }
  return 0;
}

Boost 1.37 проблема повторяется.

Здравствуйте, Alexander G, Вы писали:

AG>http://files.rsdn.ru/74426/spirit_crash.png

Кошмар...

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Alexander G, Вы писали:

AG>>Здравствуйте, jazzer, Вы писали:

J>>>А какие проблемы с bind? Он же инлайнится весь (если ты его в function не сохраняешь, конечно же).

AG>>Не всегда весь. Ещё, делает несколько лишних копирований, можно упустить копирование чего-то большого.
J>boost::ref, boost::cref тебя спасет (ну да я уверен, что ты и без меня про них знаешь)

Для this'а ещё спасёт &.
Для бинда, помещаемого в function и живущего дольше контекста shared_ptr спасёт.

/* return bind(&X::x, X()); // oops. */
return bind(&X::x, shared_ptr<X>(new X()));  // ok.

J>BOOST_FOREACH не всеми компиляторами поддерживается, к сожалению

Меня больше всего интересует компилятор, поставляемый со средой на картинке

Здравствуйте, Alexander G, Вы писали:

AG>Не знаю, сюда, в КУ или сразу в КСВ...

AG>[-img]http://files.rsdn.ru/74426/spirit_crash.png[/img]

На момент прочтения сверху висела тема: "Праздновал юбилей". Щелкал, не глядя, по ней, а попал сюда. Ну, думаю, хорошо отпраздновали.

Здравствуйте, Alexander G, Вы писали:

J>>Ну и файл, который нужно распарсить, естественно.

AG>

AG>  memset(p, '(', size);
AG>

Ну да, рекурсия не бесконечная, всего 1024 * 1024 раз
Т.е. если вызов функции занимает всего байт на стеке (чего быть не может, так как надо хранить информацию для отката), то это сразу мегабайт
Я тебе такой крэш и без всякого спирита сэмулирую.

У тебя реально файлы такие? Т.е. все эти скобки еще миллион раз закроются же? Если не секрет, что ты за задачу решаешь, что тебе нужно парсить миллион раз вложенные скобки?

You will always get what you always got
  If you always do  what you always did

jazzer wrote:

> У тебя реально файлы такие? Т.е. все эти скобки еще миллион раз
> закроются же? Если не секрет, что ты за задачу решаешь, что тебе нужно
> парсить миллион раз вложенные скобки?
Хм... а это реально может быть проблемой, если есть возможность DoS-аттак. Нехорошо, если какой-нибудь сервис будет падать по переполнению стека при специально сформированных входных данных.

Здравствуйте, jazzer, Вы писали:

J>У тебя реально файлы такие? Т.е. все эти скобки еще миллион раз закроются же? Если не секрет, что ты за задачу решаешь, что тебе нужно парсить миллион раз вложенные скобки?
Интерпретатор LISP?

Здравствуйте, jazzer, Вы писали:

J>У тебя реально файлы такие? Т.е. все эти скобки еще миллион раз закроются же? Если не секрет, что ты за задачу решаешь, что тебе нужно парсить миллион раз вложенные скобки?

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

Кстати, boost::regex имеет макрос BOOST_REGEX_NON_RECURSIVE для тех, кто хочет обрабатывать любые входные данные без переполнения стека.