| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > Очень длинный switch блок |
| Автор: Master01 26.4.2013, 22:34 |
| Доброго дня Может кто-нибудь, сталкивался с чем-то подобным или есть какие-нибудь идеи. Ситуация следующая - есть функция , в которой находится очень большой switch-case блок, около 50 case блоков, в строках кода - примерно 2000 строчек, но, наверно, не суть. В этот switch добавил ещё один case, после чего система стала зависать. pstack показывает что все потоки (их в сиcтеме ~100 ) застряли на new или delete (malloc/free), причём в какой момент это происходит не ясно, т.к. система работает минут 30-40 до зависания. Забавно следующее - перенёс код нового case блока в отдельную функцию и из case её вызывал - всё равно вешалась. Удалил все изменения в старой функции, весь код положил в новую и стал вызывать её минуя старую функцию со switch блоком - взлетело и работает. Проверил по спецификации - минимальное число поддерживаемых блоков case в switch - 64 или 256 т.е. у меня точно меньше. Да и симптомы какие-то непонятные. Вешалось оно в разным местах, давольно отдалённых от функции, которая изменялась. Что за затык, кто-нибудь может предположить? Памяти 50% свободно (64 Гб из 128) Код - c++ core, stl + boost 1.35 и CORBA (у меня сомнения вменяемости может вызывать только последняя) Компилится это CC на Solaris 10 . Вот кусок дампа из pstack. ----------------- lwp# 89 / thread# 89 -------------------- ffffffff7a4d270c lwp_park (0, 0, 0) ffffffff7a461c4c free (22f7f4f20, 2270, 18a3d0, ffffffff7a460d08, ffffffff7a5ec000, 2000) + 28 ffffffff7b50786c void operator delete(void*) (22f7f4f20, 3e80, ffffffff609fb4df, 104274, ffffffff7b60ca60, 0) + 4 000000010069be88 void std::allocator<double>::deallocate(double*,unsigned long)const (ffffffff609fb830, 22f7f4f20, 7d0, ffffffff609fb56f, ffffffff7261c2 00, 0) + 30 000000010069bc44 std::_Vector_base<double,std::allocator<double> >::~_Vector_base #Nvariant 1() (ffffffff609fb820, 22f7f8da0, ffffffff609fb808, ffffffff 609fb64f, ffffffff7b60ca60, 12ce61680) + 5c 000000010069b1b4 std::vector<double>::~vector #Nvariant 1() (ffffffff609fb820, 0, ffffffff609fb808, ffffffff609fb76f, ffffffff7bd15a38, ffffffff7bbab940 ) + 2c |
| Автор: volatile 26.4.2013, 23:30 | ||||||
Скорей всего дело не свитче, а в чем-то другом. Вариантов может множество, например возможно у вас создание объектов в свитче
так делать очень не надо. Ну в общем много чего может быть... 
у вас 128 Гб оперативы? |
| Автор: Master01 29.4.2013, 09:13 |
| Да нет, объекты в case не создаются. Кроме того там весь код обрамлялся {} . Я правильно понял, что беспокойство вызывало именно области видимости для этих объектов? Я понимаю, что может быть всё что угодно  я не понимаю, что может привести к тому, что операционка перестаёт обслуживать malloc/free. При этом оно же не валится а просто весит.Да, оперативы 128 Гб - это большой Sun-овский бокс. Там ещё 2 4х ядерных спарка по 16 потоков на ядро поэтому в системе и 128 потоков. |
| Автор: feodorv 29.4.2013, 10:10 | ||
У Вас там точно break'и стоят в нужном месте?
|
| Автор: Silent 29.4.2013, 12:31 |
| Может быть оператор switch реализован "по-интересному"? Попробуйте этот случай условием выкинуть либо за switch, либо в ветку default, и посмотреть результат. Еще может быть вам покажется полезным ознакомиться с http://habrahabr.ru/post/174065/, вдруг cc в солярисе реализовывает switch как в JVM'е |
| Автор: xvr 29.4.2013, 14:51 |
Судя по дампу стека у вас проблемы с памятью. Возможно большая фрагментация и частые заказы/возвращения памяти. У run-time'а в Solaris с этим были большие проблемы  |
