Здравствуйте, Философ, Вы писали:
Ф> clr!MethodDesc::MakeJitWorker+0x44d Ф> clr!MethodDesc::DoPrestub+0x150b Ф> clr!PreStubWorker+0x3cc Ф>Что интересно, этот клиент один такой, и почти на 300 остальных его машин подобных проблем не возникает.
Впечатление такое, что у него что-то не в порядке с JIT. Этот код производит компиляцию, вот здесь это описано
и при этом возникает исключение, которое перебрасывается в нативный код (а куда еще!) и потом портируется в дотнет обратно
>Как этого чувака осчастливить?
Я бы для начала посоветовал переинсталлировать дотнет. Если у всех 300 других проблем нет, а есть только у него и именно в этом месте — это первое, что приходит в голову.
С памятью проблема там нет:
8Gb Physical RAM + 8Gb PageFile
4.3 Physical RAM free
с CommiteSize тоже проблем нет.
Peak PrivateSet для процесса ~160 Mb
Что интересно, этот клиент один такой, и почти на 300 остальных его машин подобных проблем не возникает.
Есть у кого-нибудь идеи что это может быть? Как этого чувака осчастливить?
ЗЫ: Что любопытно, метод, который в гуёвине не джитится даже не дженерик....
Всё сказанное выше — личное мнение, если не указано обратное.
В качестве догадки. Cудя по логу, необработанное OutOfMemoryException возникает изнутри callback метода у Timer'a. Т.е. примерно такая ситуация, что этот callback одновременно вызывается из двух разных потоков, причем в одном потоке он в процессе JIT, а в другом потоке он бросает OutOfMemoryException. Ну и MakeJitWorker перехватывает это исключение и пробрасывает его дальше.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Как этого чувака осчастливить?
PD>Кстати, эффект стабилен ?
Да, эффект (был) стабилен.
PD>Я бы для начала посоветовал переинсталлировать дотнет. Если у всех 300 других проблем нет, а есть только у него и именно в этом месте — это первое, что приходит в голову.
Так и сделали, но вряд ли клиент это сделал, т.к. перед этим сборки ему проngenили и это его "осчастливило".
Всё сказанное выше — личное мнение, если не указано обратное.
