Доброго дня

Может кто-нибудь, сталкивался с чем-то подобным или есть какие-нибудь идеи.
Ситуация следующая - есть функция , в которой находится очень большой 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


Это сообщение отредактировал(а) Master01 - 26.4.2013, 22:38

Скорей всего дело не свитче, а в чем-то другом.
Вариантов может множество, например возможно у вас создание объектов в свитче

так делать очень не надо.
Ну в общем много чего может быть...

  

у вас 128 Гб оперативы?

Да нет, объекты в case не создаются. Кроме того там весь код обрамлялся  {} . Я правильно понял, что беспокойство вызывало именно области видимости для этих объектов?
Я понимаю, что может быть всё что угодно  я не понимаю, что может привести к тому, что операционка перестаёт обслуживать malloc/free. При этом оно же не валится а просто весит.
Да, оперативы 128 Гб - это большой Sun-овский бокс. Там ещё 2 4х ядерных спарка по 16 потоков на ядро  поэтому в системе и 128 потоков.


Это сообщение отредактировал(а) Master01 - 29.4.2013, 09:15

У Вас там точно break'и стоят в нужном месте?

Это сообщение отредактировал(а) feodorv - 29.4.2013, 10:11

Может быть оператор switch реализован "по-интересному"?
Попробуйте этот случай условием выкинуть либо за switch, либо в ветку default, и посмотреть результат.
Еще может быть вам покажется полезным ознакомиться с этой статьей, вдруг cc в солярисе реализовывает switch как в JVM'е

Судя по дампу стека у вас проблемы с памятью. Возможно большая фрагментация и частые заказы/возвращения памяти. У run-time'а в Solaris с этим были большие проблемы