Abtin Forouzandeh обнаружил баг в реализации go для 32-хбитной платформы Windows. Простейшая программа запускается и тут же падает.
По итогам исследования ошибки оказалось, что дело в выделении памяти рантаймом go. В 32-хбитной системе Windows всего доступны 4GB виртуального адресного пространства, верхние 2 из которых зарезервированы для системы, а процессу остаются нижние 2 гигабайта. При запуске программы на go, скомпилированной компилятором 8g рантайм пытается выделить 512 мегабайт виртуального адресного пространства для нужд сборщика мусора. Проблема в том, что память требуется одним куском. Однако в этой реализации языка библиотека KERNELBASE.DLL загружается в середине адресного пространства, выделить протяженный кусок памяти у системы не получается и происходит падение.
Разработчики go извещены о проблеме, но ошибке выставлен приоритет «Priority-Later» и в go 1 версии она не исправлена. Решения по исправлению сводятся к «Переходите на 64 бита» и «Переходите на Unix» и вопросам «Как же мы это просмотрели?». Автор оригинального поста предпочел перейти с go на С.
UPD: Как правильно указывает atd даже если вы перейдете на 32bit Linux проблемы со сборщиком мусора не исчезнут. Вот этот баг показывает, что для определенных структур данных сборщик мусора не справляется с задачей. Для долго работающих и активно использующих память программ это означает постоянные падения. Рекомендации разработчиков — черная магия типа «Разнесите долго живущие и коротко живущие данные по разным структурам» или опять же «Переходите на 64 бита». В ближайшее время ошибка исправлена не будет.
По итогам исследования ошибки оказалось, что дело в выделении памяти рантаймом go. В 32-хбитной системе Windows всего доступны 4GB виртуального адресного пространства, верхние 2 из которых зарезервированы для системы, а процессу остаются нижние 2 гигабайта. При запуске программы на go, скомпилированной компилятором 8g рантайм пытается выделить 512 мегабайт виртуального адресного пространства для нужд сборщика мусора. Проблема в том, что память требуется одним куском. Однако в этой реализации языка библиотека KERNELBASE.DLL загружается в середине адресного пространства, выделить протяженный кусок памяти у системы не получается и происходит падение.
Разработчики go извещены о проблеме, но ошибке выставлен приоритет «Priority-Later» и в go 1 версии она не исправлена. Решения по исправлению сводятся к «Переходите на 64 бита» и «Переходите на Unix» и вопросам «Как же мы это просмотрели?». Автор оригинального поста предпочел перейти с go на С.
UPD: Как правильно указывает atd даже если вы перейдете на 32bit Linux проблемы со сборщиком мусора не исчезнут. Вот этот баг показывает, что для определенных структур данных сборщик мусора не справляется с задачей. Для долго работающих и активно использующих память программ это означает постоянные падения. Рекомендации разработчиков — черная магия типа «Разнесите долго живущие и коротко живущие данные по разным структурам» или опять же «Переходите на 64 бита». В ближайшее время ошибка исправлена не будет.
