LINUX.ORG.RU

Найден 33-летний баг в коде yacc

 , , ,


0

0

Голландский программист Отто Моэрбик случайно нашёл баг в коде функции yyparse(), вскоре после написания собственного варианта malloc для OpenBSD. Николай Штурм первым обнаружил проблему, предположительно связанную с новым malloc, на платформе SPARC64 при попытке компиляции большого проекта на С++ с использованием новой версии malloc от Моэрбика, компилятор иногда завершается с сообщением о внутренней ошибке. После недолгого исследования оказалось, что при определённых условиях (создаваемых новой версией malloc) в функции yyparse происходит обращение к несуществующему элементу массива.

Выпущен соответствующий патч для OpenBSD, решающий данную проблему. Данный баг существует и в старых версиях UNIX вплоть до Sixth Edition UNIX, выпущенной в 1975 году.

>>> Подробности

★★★★★

Проверено: Shaman007 ()

Ответ на: комментарий от gaux

>Низкоуровневый код обработки прерываний x86 написан на языке ассемблера и C.

В вики можно было и не лазить. Не думаю, что на ЛОРе найдется хотя бы пара людей, способных написать проуедуру обработки прерываний без использования прямого доступа к памяти. О бутлоадере я вообще молчу :)

anonymous
()

Круто, недавно нашли 25-летний баг, а тут на 8 лет старше :) Какой следующий по возрасту найдут?

lester_dev ★★★★★
()
Ответ на: комментарий от anonymous

>Пусть кто нить форк снимет с этой поделки. Она не должна просто так исчезнуть.

Кто-нибудь... Сними сам.

anonymous
()
Ответ на: комментарий от val-amart

не знаю что такое як, безон, и прочие рогатые скатины

но осуждаю их за то, что отрекаются от православного m4.

anonymous
()
Ответ на: комментарий от val-amart

> а 4.4 BSD на чем основана знаешь, нет? =)

из-за судебных разбирательств код AT&T убрали и 4.4BSD Unix переименовали в 4.4BSD

phasma ★☆
()
Ответ на: комментарий от gaux

>>Напиши мне автономную программу (какой является ядро ОС) на твоем любимом си-решетка. Ассемблер и C не использовать.

>Уже давно написано, качай сорцы Singularity

>http://ru.wikipedia.org/wiki/Microsoft_Singularity

>Низкоуровневый код обработки прерываний x86 написан на языке ассемблера и C. Библиотеки времени исполнения (англ. runtime) и сборщик мусора написаны на Sing# (специально доработанном для данного проекта диалекте C#) с использованием небезопасного режима (англ. unsafe mode).

>:P

Как всегда, линупсята не видят дальше своего носа... Какая разница откуда взялся hotspot, на чем его написали? Может в моем мажорном девайсе он вообще аппаратный? Главное что если он есть то обвязки и конечные продукты (оси, приложения) получаются на порядок качественнее

anonymous
()
Ответ на: комментарий от anonymous

>Главное что если он есть то обвязки и конечные продукты (оси, приложения) получаются на порядок качественнее

и главное - DRM легкореализуема! :)

anonymous
()

После заключения договора о сотрудничестве со следствием, Отто Моэрбик согласился показать местонахождение 33-летнего бага.

anonymous
()
Ответ на: комментарий от anonymous

>Интересно, openbsd уже начал ктото использовать, что в ней начали дыры находить?

Ее все используют, у кого нет денег на циско.

anonymous
()
Ответ на: комментарий от anonymous

> оси

А что, уже есть даже несколько рабочих ОС на C#? :D

tailgunner ★★★★★
()

Бздякапец! Линь навек!

exah
()
Ответ на: комментарий от anonymous

>Главное что если он есть то обвязки и конечные продукты (оси, приложения) получаются на порядок качественнее

>и главное - DRM легкореализуема! :)

А кто заставляет пользоваться файлами с замками? Да даже если это будет единственный источник контента - что мешает запускать правоозабоченные плееры на собственном хотспоте который предоставляет интерфейс для доступа куда угодно?

anonymous
()

Линукс - сила!

anonymous
()
Ответ на: комментарий от anonymous

>А кто заставляет пользоваться файлами с замками? Да даже если это будет единственный источник контента - что мешает запускать правоозабоченные плееры на собственном хотспоте который предоставляет интерфейс для доступа куда угодно?

Да речь не о контенте, а о том, что со временем все компы могут стать тостерами с невозможностью изменения пользователем.

anonymous
()

>Найден 33-летний баг в коде yacc

А давайте в новости ЛОРа запостим пару тысяч открытых багрепортов с kernel.org

anonymous
()
Ответ на: комментарий от anonymous

>А давайте в новости ЛОРа запостим пару тысяч открытых багрепортов с kernel.org

если они 30-летней давности, давайте :)

seiken ★★★★★
() автор топика
Ответ на: комментарий от anonymous

>Да речь не о контенте, а о том, что со временем все компы могут стать тостерами с невозможностью изменения пользователем.

И как управляемый код этому поспособствует? Хотспот будет зашит в биосе с невозможностью использования альтернативного? Любой производитель железа прогорит на выпуске таких плат

anonymous
()
Ответ на: комментарий от seiken

>если они 30-летней давности, давайте :)

Линукс столько не жил.

anonymous
()
Ответ на: комментарий от anonymous

> А кто заставляет пользоваться файлами с замками?

Ну вот когда будете это использовать, приходите на поговорить. Пока это клуб пикейных жилетов.

anonymous
()

Вот нашли старый баг, и сразу пошёл холивар какая система стабильнее

> Дело в том, что для самой популярной платформы получается самый стабильный код....

> И необязательно автор бажного кода бездарь...

Посему в любой системе можно найти очень старый баг. Скажем, завтра выйдет новая мегаархитектура под которой может не заработать какая-нибудь очень древняя процедура из прошлого тысячелетия, просто потому, что автор кода даже в страшных снах не видел таких машин.

И наличие такого бага не означает, что код, содержащий баг крайне стабилен или наоборот - его надо на помойку.

Количество багов, которые находят, зависит не только от бажности кода но и от кучи других параметров, например количества разработчиков и скорости их работы... Не стоит отправлять на помойку ос, если в ней найдено 1000 багов за сутки, равно как и если найден 1 за год. В первом случае это может быть результатом интенсивной разработки (что говорит о том, что свежие дыры будут быстро устраняться) а может и результатом низкого качества кода (что означает большое кол-во новых дыр), во втором случае - крайне высококачественного кода (устойчивая система) или очень вялой разработки (проект просто умирает, т.к. не идёт "в ногу со временем").

world
()

-- Они убили баг! Сволочи!

Такой знатный баг надо было окружить воркэраундом и заботой, тщательно прокомментировать в коде и водить пионеров на экскурсии!

LowLevel
()
Ответ на: комментарий от anonymous

>Любой производитель железа прогорит на выпуске таких плат

RIAA и MPAA продавит нужный закон, и производители железа будут производить то, что им скажет шоу-бизнес.

anonymous
()
Ответ на: комментарий от anonymous

Боюсь, ты прав. Читал обзор материнской платы на новом чипсете от Интел - там, между строк, упомянуто об улучшении TPM. Т.е. он там есть, а это массовый чипсет...

anonymous
()

Баг -- мне ровестник! :) Вот же... люди юниксы писали, когда я ещё пелёнки марал. :)

Lumi ★★★★★
()
Ответ на: комментарий от gln0fate

>>> а 4.4 BSD на чем основана знаешь, нет? =)

>> вот советую ознакомиться, очень познавательно:

>> http://upload.wikimedia.org/wikipedia/commons/7/77/Unix_history-simple.svg

дети сарказма не понимают... советуй дальше, я предпочитаю

http://www.levenez.com/unix/

val-amart ★★★★★
()

и не стыдно таких старых жуков давить... это ж пенсионеры читай.

AiFiLTr0 ★★★★★
()

да линуксоиды просто завидуют. они из кернела выгребают, выгребают, выгребают килотонны багов, а они все молочные. а эти баги проверенные временем, на них уже выросло не одно поколение программеров, ветераны. а каждый ветеранский баг идет в соотношении 1 к 10^количество_лет_багу. вот и посчитайте сколько багов надо еще выковырять из кернела, чтобы хоть чуточку приблизиться к заветному первому месту.

ss
()
Ответ на: комментарий от anonymous

>Не забывайте, что BSD - это настоящий UNIX в отличие от линупса. Настоящий, в смысле имеет корни в давней подел^W разработке AT&T.

Нам пофиг.

jackill ★★★★★
()

Нечего безбажного не существует.

LeeQuadro
()

интересно - а в bison-e нет такого???

fi ★★★
()

Почти главный пенсионер теперь :)

Голландскому кодеру респект и уважуха :)

tensai_cirno ★★★★★
()
Ответ на: комментарий от obsidian

> Рекорд 25 лет успешно побит :)

> Первая бага была еще у Ады Лавлейс на Машине Бэбиджа,а отловили ее только в 70-е гг в СССР. Так что даже если всплывут баги, унаследованные от Multics, рекорда им не видать

Угу, в 80-е, будучи школьником, слышал такое по ТВ чуть ли не из уст самого Ершова или Глушкова...

Так что 33 года багу -- так, младенческий возраст :)

Stalin ★★★★★
()

Если баг себя никак не проявляет, то его нет. Вот баг себя проявил, и его исправили. Что за шум то?

zone_ru
()
Ответ на: комментарий от anonymous

>В вики можно было и не лазить. Не думаю, что на ЛОРе найдется хотя бы пара людей, способных написать проуедуру обработки прерываний без использования прямого доступа к памяти. О бутлоадере я вообще молчу :)

Собственно и чего здесь сложного? :-)

Metallic
()
Ответ на: комментарий от seiken

> Дело в том, что для самой популярной платформы получается самый стабильный код. Изменяем размер страницы - лезут баги, меняем endianness - вылезает ещё больше багов. И необязательно автор бажного кода бездарь - просто он не расчитывал, что его код будет запускаться на какой-либо платформе, отличной от той, для которой он пишет. Потом есть ещё такие вещи, как производительность, которая слабо совместима с универсальностью. Приходится идти на компромисс - либо скорость, либо портабельность.

С учётом того, что в помянутых моментах аппаратной части платформы х86 всё сделано через задницу и совсем наоборот относительно нормальных RICS'ов - то логичен вывод, сынок, что оная х86 принципиально и от рождения является жутким глюкодромом. Что можно обойти лишь хорошей кармой, в частности - писать юникс под х86 и следовать юникс-вею, что блестяще доказывают линупс и гном и замечательно подтверждают аппаратно заточенные венды и прочие сопутствующие поделия на букву Кы с кармическим пенальти.

Gharik
()

>Выпущен соответствующий патч ...Sixth Edition UNIX, выпущенной в 1975 году.

И в каком месте перфоленты надо ковырять дополнительные дырочки? :)

quickquest ★★★★★
()
Ответ на: комментарий от Gharik

>жутким глюкодромом. Что можно обойти лишь хорошей кармой, в частности - писать юникс под х86 и следовать юникс-вею, что блестяще доказывают линупс и гном и замечательно подтверждают аппаратно заточенные венды и прочие сопутствующие поделия на букву Кы с кармическим пенальти.

так я не понял, что в итоге победило: глюкодром, карма или керамика? Ты можешь изъясняться попонятнее, дедуля?

seiken ★★★★★
() автор топика
Ответ на: удаленный комментарий

> P.S. Сорри за оффтоп, достали анонимусы :(

А, анонимусов прикрыли? Тогда удаляю описание бага винды :)

voronaam ★★
()
Ответ на: комментарий от quickquest

>>Выпущен соответствующий патч ...Sixth Edition UNIX, выпущенной в 1975 году.

>И в каком месте перфоленты надо ковырять дополнительные дырочки? :)

очень оригинальное чувство юмора

seiken ★★★★★
() автор топика

Блин...ясно же написано:
The bug was only triggered on sparc64, since it uses 8k pages. The default yacc stack size for C++ is 24 * 200 = 4800 bytes, which is larger than a page on most platforms.

Не было тогда таких платформ...:))

GlorySmith
()

Ничего святого у людей!

emacs
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.