LINUX.ORG.RU

Изменение поведения memcpy в glibc привело к странным ошибкам

 ,


0

2

Изменение поведения функции memcpy() в реализации glibc для x86_64 (для ia-32 ничего не изменилось) привело к странным ошибкам во многих программах. Например, искажению звука при проигрывании.

Проблема в том, что memcpy для перекрывающихся участков памяти теперь работает некорректно (как в общем-то и должно быть согласно документации). Но, как выяснилось, авторы многих проектов документацию не читали.

Несмотря на появление в обсуждении Линуса Торвальдса, у которого также появились проблемы со звуком в некоторых программах на его компьютере, ошибка была закрыта по причине «not a bug». В сообщении #38 Линус предлагает способ обхода этой проблемы.

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

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: Dendy (всего исправлений: 5)

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

> Такую «мелочь», как перекрывающиеся области запросто можно и не вспомнить через 5 лет после того, как ты прочёл man, если ты не наступал на такие грабли.

Хера се мелочь. Ну Вы жжоте.

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

>Хочется писать через жопу, милости просим в мир .NET/Java и прочей виртуальщины.

Через жопу, сожалению, пишут на любом языке, это факт. Приходится с этим мириться.

Тут же речь про системные библиотеки.

Эээ, не. Речь-то про flash.

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

> Скорость нужна при поносе и ловле блох. У вас что ? Всем всегда нужна стабильная работа

Так SUN вроде уже Oracl-у продался? Вас что, не уведомили?

То есть если железка обрабатывает 60 каналов а потом стала 10, но стабильно, но это нормально? Пойду своим расскажу, вы, надеюсь, авторитетный источник?

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

>Есть расширения для отладки, короче

Конечно, есть. Но судя по этой новости — либо в них нету самопроверяющейся memcpy, либо ими кое-кто не пользуется.

Конечно, отладочное сообщение будет лучше чем segfault. Это я ступил.

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

Скорость нужна при поносе и ловле блох. У вас что ? Всем всегда нужна стабильная работа.

А вы согласны смотреть фильмы на стабильных 5 кадров в секунду. В драйверах тоже не нужно ускорения и оптимизации?!

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

>Хера се мелочь. Ну Вы жжоте.

А что, нет? Попробуй выйти на дорогу и пораспрашивать, например, о порядке проезда перекрёстков. Нифига ж не мелочь, а сколько тех, кто на права сдавал более пяти лет, назад вспомнят все правила?

Та же самая ситуация. Если у тебя феноменальная память или тебя лишили зарплаты за такой баг, да, ты скорее всего запомнишь. В остальных случаях, можешь и не обратить внимания. Те 10 раз, что ты будешь читать man ты будешь уверен, что у тебя ничего не перекрывается. А вот на 100 раз, когда ты в man уже не пойдешь (10 лет опыта за спиной, фигли), участки перекроются и ты и не вспомнишь про этот момент. Или не сообразишь, что участки-то могут и перекрываться.

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

>Я не понимаю о чём вы вообще.

это плохо.

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

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

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

> Эээ, не. Речь-то про flash.

ненене Дэвид! Кто про что, а голый про баню. Началось всё в glibc, и его неуёмной страсти к соблюдению стандартов, которую не понимают «рядовые» хомячки и голосуют против. ;-)

Кстати мультик вспомнил, помните? "- Но ведь рога мои!

- А дупла НАШИ!!!"

alx_me ★★☆
()

Ошибки не нужны.

anonymous
()

Проблема в том, что memcpy для перекрывающихся участков памяти теперь работает некорректно (как в общем-то и должно быть согласно документации).

Кто написал эту глупость? Она не работает «некорректно согласно документации». Она работает корректно, но результат непредсказуем, если она копирует перекрывающиеся области. Это не то же самое, что «некорректно».

Вспоминается высказывание Столлмана о том, что «СПО в целом качественнее проприетарного ПО». Ха-ха. Программисты СПО даже не знают как работает memcpy()...

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

>>А какие варианты? Если хочешь ускорения это необходимо.

Скорость нужна при поносе и ловле блох. У вас что ? Всем всегда нужна стабильная работа.

Стабильная работа и игнорирование манов понятия ортогональные. Что мы в данный момент и наблюдаем.

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

> .. туду на след. мажорный релиз

Да, тут вы, возможно, правы. Но вы устойчиво игнорируете мои посылы к стратегии GPL. Я предполагаю политику. Вы точно читали стратегию и цели GPL? Пока всё укладывается. Да, мы противные (это читайте после того как прочитаете про Столмановский меморандум о GPL).

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

>> #ifdef USE_FAST_MEMCPY

:-) мило. Это и есть тот самый зоопарк, первая клетка.

Ну я особо и не ратую за это.

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

>#ifdef USE_FAST_MEMCPY

для тех, кто хочет быстро

логично.

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

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

>Ха-ха. Программисты СПО даже не знают как работает memcpy()...

Как показывает пример flash, проприетарщики тоже не особо знают :)

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

>>Linus Torvalds:

I dunno. I just tested my stupid «mymemcpy.so» against the glibc memcpy() on the particular kind of memcpy that valgrid reports (16-byte aligned 1280-byte memcpy)

Да, молодцы оптимизаторы! :)

читай тред до конца.

--------------------- Timur Iskhodzhanov 2010-11-11 03:10:07 EST

(I'm sorry to jump in the middle of the discussion)

When a program is run under Valgrind it replaces memcpy with its own implementation: http://code.google.com/p/valgrind-variant/source/browse/trunk/valgrind/memche...

The latter is intentionally overlap-safe, so no surprise it 'fixes' the sound for you. Plus it throws a Valgrind overlap report like those you've seen. -----------------------------------

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

>>А если такую проверку делать — как раз и получается memmove.

серьезно?


«Получится функция, не выигрывающая у memmove по скорости _в штатной ситуации_, а никаких плюсов, кроме скорости в обмен на предположение о неперекрытии аргументов, memcpy против memmove всё равно не имеет».

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

> А что, нет? Попробуй выйти на дорогу и пораспрашивать, например, о порядке проезда перекрёстков. Нифига ж не мелочь, а сколько тех, кто на права сдавал более пяти лет, назад вспомнят все правила?

Вспомнят. ЧТо там вспоминать-то?

Та же самая ситуация. Если у тебя феноменальная память или тебя лишили зарплаты за такой баг, да, ты скорее всего запомнишь. В остальных случаях, можешь и не обратить внимания. Те 10 раз, что ты будешь читать man ты будешь уверен, что у тебя ничего не перекрывается.


Если человек программирует на таких языках как C и C++, первое, что он должен держать в зоне своего внимания, это работа с памятью. Такие вещи либо запоминаются, либо запоминается, что у данной функции есть что особенное и надо заглянуть в man.

А вот на 100 раз, когда ты в man уже не пойдешь (10 лет опыта за спиной, фигли), участки перекроются и ты и не вспомнишь про этот момент. Или не сообразишь, что участки-то могут и перекрываться.


А вот и нет. Как раз обратное - на 100 раз уже тупо запомниться, что есть memcpy(), а есть memmove(). Даже на 10 уже.

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

> Программисты СПО даже не знают ...

Оппа! Ананим всё знает и не прощает! А вот программисты Adobe не лучше СПО, по вашей логике. А по моей хуже, так как закрытый код не должен быть красив и строен, за это не платят, как нам напомнил AVL2.

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

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

эту мутотень нормально работать

что бы устранить баг руки не из того места растут легче костыль

склепать

vcore (11.11.2010 9:09:04)

Помолчал бы, хомячок.

anonymous
()

>Линуса Торвальдса, у которого также появились проблемы со звуком

«Ммменя зовут Ли-ли-линус То-то-то-рвальдс и я - ваш бо-бо-бо-блядь».

sun-lsd
()
Ответ на: комментарий от alx_me

>Да, тут вы, возможно, правы. Но вы устойчиво игнорируете мои посылы к стратегии GPL. Я предполагаю политику. Вы точно читали стратегию и цели GPL? Пока всё укладывается. Да, мы противные (это читайте после того как прочитаете про Столмановский меморандум о GPL).

GPL всего лишь позволяет обойтесь малой кровью при таких сбоях. Да, свободный софт имеет преимущество в том плане, что улучшать его можно и нужно всем миром. Это замечательно. Но это не значит, что нужно ставить подножки или что нужно искусственно гробить всех остальных.

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

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

> И пусть те, кто оттестировал программу на новой верси

После этого «логично» я вас классифицировал не скажу как. Вы и сами знаете, что так быть не должно. Этот флаг либо никогда не будет работать, либо будет всегда включён. Альтернатива - распад с форками. Никто, как вы и сами знаете, из копирастов не почешется для исправления своей ошибки если её можно не исправлять.

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

> GPL всего лишь позволяет обойтесь малой кровью при таких сбоях.

Вы не поняли. И не читали. Не осуждаю, здесь таких большинство.

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

> кто мешает дистростроителям использовать старую glibc?

В том то и дело что ничего не мешает. Нонсенс. Они должны выполнять функции посредника-защитника «рядовых ламеров». Не мы. Никто им не мешает, не наставивая на включении этого в head, вернуть взад memcpy как им нужно по жизни. Но head должен быть как он есть.

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

http://www.linkedin.com/in/ulrichdrepper

Consulting Engineer/Technical Director
Red Hat

(Public Company; RHT; Computer Software industry)

April 1996 — September 2010 (14 years 6 months)

он ушел из redhat ,

хотя он коммиттит в git - http://sourceware.org/git/?p=glibc.git;a=shortlog ,

нужно посмотреть багзиллу на предмет «stop reopening» )

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

>«Получится функция, не выигрывающая у memmove по скорости _в штатной ситуации_, а никаких плюсов, кроме скорости в обмен на предположение о неперекрытии аргументов, memcpy против memmove всё равно не имеет».

ты серьезно не понимаешь принципиальной разницы между memmove и memcpy с включеной проверкой аргументов?

И кто тебе сказал, что «Получится функция, не выигрывающая у memmove по скорости»?

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

> I_AM_STUPID_MORON__AND_I_WANT_TO_WRITE_DIRTY_CODE

О, да! Это больше в духе OSS. :-D. Маладца!

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

После этого «логично» я вас классифицировал не скажу как. Вы и сами знаете, что так быть не должно. Этот флаг либо никогда не будет работать, либо будет всегда включён. Альтернатива - распад с форками. Никто, как вы и сами знаете, из копирастов не почешется для исправления своей ошибки если её можно не исправлять.


Конкретно этот разговор вымышлен, но похожие по сути разговоры случались не единожды.

—Алло?
—Здравствуйте, это такой-то, из отдела совместимости Microsoft Windows. Мы нашли в вашей программе баг, из-за которого она не работала. Мы были вынуждены добавить в Windows 95 код для обхода этого бага, чтобы ваша программа продолжала работать.
—Замечательно, большое вам спасибо! До свидания. (Короткие гудки.)
(Набираем номер снова.)
—Алло?
—Алло, ээ… Вы даже не хотите узнать, какой был баг?
—Какая разница? Вы же всё исправили. Спасибо! Что бы мы без вас делали!
—Но, ээ, код в обход бага будет работать только с текущей версией вашей программы. Когда вы выпустите следующую версию, она не заработает.
—Вот оно как?.. Ну, подождите, я свяжу вас с нашими программистами.

Разработчики совершенно не обращают на вас внимания, пока вы не упомянете, что их программа перестанет работать.

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

>Наоборот. Нужно ввести специальный #define I_AM_STUPID_MORON__AND_I_WANT_TO_WRITE_DIRTY_CODE

нет, новое поведение должно требовать новых ключей.

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

>Ха-ха. Программисты СПО даже не знают как работает memcpy()...

Как показывает пример flash, проприетарщики тоже не особо знают :)

Ну, это была одна ошибка в одной программе. А как только memcpy привели в соответствие с документацией, глюки появились «во многих программах». То есть, во всех этих программах разные программисты не знали, как работает memcpy!

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

> И кто тебе сказал, что «Получится функция, не выигрывающая у memmove по скорости»?

Может он в душе аноним, вы с ними поаккуратнее, они всё знают!

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

>mmx sse и прочие SIMD перделки и свистелки имеют небольшой смысл только при сверхбольших объёмах данных.

Дай угадаю, ты пишешь стартапы на похапе за еду?

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

я вот тоже так подумала, пока пропатчить для релиза,
но в апстриме оставить, так что когда текущий svn понемногу переберется в дистрибутивы, и в первую очередь в Федору опять таки, то баги должны бы быть исправлены, ну а если кто не успеет исправить свой кривой код... сами виноваты.

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

>Никто, как вы и сами знаете, из копирастов не почешется для исправления своей ошибки если её можно не исправлять.

Да таких ошибок в опенсорсе до чертиков.

И ты готов заплатить за исправления всех таких ошибок?

Этот флаг либо никогда не будет работать, либо будет всегда включён.

Собственно, это требуется анализировать. Если в 99,9% флаг включен, значит переход состоялся. Можно выносить старый код.

AVL2 ★★★★★
()
Ответ на: комментарий от kim-roader

>Я то надеялся, что я могу заполнить массив первыми двумя элементами при помощи memcpy(array, array + 2, size - 2).

Я не перестаю поражаться, сколько на свете идиотов, которые используют undefined behaviour, а потом удивляются: чего это их быдлоподелка отвалилась после очередного апдейта компилятора/используемых библиотек.

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

> Разработчики совершенно не обращают на вас внимания...

Это были не разработчики, а менеджеры. Надо знать разницу. Кроме того необходимо понимать разницу между кодером и разработчиком. Отличить их очень просто. Скажите что в коде есть дефект, укажите где. Кодер оскорбится и исправит, разработчик исправит аналогичные ситуации везде и попутно улучшит схему взаимодействия модулей, менеджер скажет что нечего соваться не в своё дело и скажет как они обычно обходят соответствующий дефект и клиенту это не нужно.

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

>Это были не разработчики, а менеджеры.

Еще раз. Сначала вы покупаете индусские программы и китайский трикотаж, а потом удивляетесь, что у менеджера в приоритете не те ценности.

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

> Если в 99,9% флаг включен,

У кого включёт. Дистрибутивов более 500.

И ты готов заплатить за исправления всех таких ошибок?

Вы про какую стратегию разработки говорите?

Короче читайте ещё и про 95%. Я пошёл.

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

>Я не перестаю поражаться, сколько на свете идиотов,

это была ирония. отсутствие чувства юмора - тоже криминал...

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

>У этого буржуя еще и процессор поддерживает SSSE. Гавнюг.

Вообще то еще чуть ли не год назад была новость, что у линуса i7 3.2 ггц с 6 гигами памяти. Это при том что для лоровских нищебродов и Core2Duo до сих пор считается суперкомпом, все тогда слюнями изошли.

з.ы. Новость ни о чем. Не баг.

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

>Вы про какую стратегию разработки говорите?

без разницы. Где-то платят деньгами, где-то временем и усилиями.

Короче читайте ещё и про 95%. Я пошёл.

ну, собственно, тому кто взял в голову 95% просто не надо писать глибцы. А судя по всему, Деппер как раз таки из таких.

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

> во-первых увеличьте размер региона ( SZ ) чтобы он значительно превышал обьем L2 кэша

Не совсем так. memcpy в пределах L2/L1 тоже полезен. Но на разных уровнях оптимизация может сказываться по разному.

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

>Стандарт никак не ограничивает реализацию memcpy он лишь говорит от том что при пересечении участков результат не определён, т.е он вполне может быть правильным в том числе. Это вопрос оптимизации. А оптимизация это слово о котором в проекте GNU знают лишь немногие.

То-то и видно, что ты не имеешь понятия о том, что такое оптимизация. memcpy - функция критичная к скорости. Там даже одна лишняя проверка может оказаться критичной. Она копирует тупо и быстро. Это и называется оптимизацией. А для неоптимального, но надежного копирования - memmove.

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

>Так получается у них был глючный memcpy? РЕШЕТО!!!1 Я то надеялся, что я могу заполнить массив первыми двумя элементами при помощи memcpy(array, array + 2, size - 2).

Говнокодер детектед. Куда тебе своими кривыми ручками к С тянуться, этот язык требует аккуратности. Иди в свою уютную семерочку и Visual Studio .NET, она как раз написана говнокодерами и для говнокодеров.

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