LINUX.ORG.RU

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

 ,


0

2

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

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

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

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

★★★★★

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

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

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

Г-н Танненбаум, перелогиньтесь.

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

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

Угу. «Ulrich is the only supported developer».

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

>devl547@ideapad ~/Desktop $ time ./test_memmove

real 0m0.001s

user 0m0.000s sys 0m0.000s

и вот так всегда) от обьема данных не зависит.

А объем какой? Надо хотя бы гигабайт. На современных компах ПСП - десятки гигабайт в секунду, на меньших объемах будет слишком большая погрешность.

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

>и вот так всегда) от обьема данных не зависит.

И тебя это не наводит на мысль о том, что gcc просто отбрасывает ненужные фрагменты кода?

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

> Людям свойственно ошибаться, будть это крутой программист или нет.

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

Такие ошибки объяснимы, понятны и простительны. Непростительно то, что эта поделка не гонялась под valgrind'ом, который такие баги выявляет на раз.

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

> Линус слушает музыку ? Или от куда у него на компьютере звуки различные ?

Он смотрит ролике в проприетрном флеше на компе с процом поддерживающим ssse. Ему давно пора прикрыть kernel.org и устроится уже на нормальную работу в микрософт.

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

Ты когда-нибудь сравнивал по производительности memcpy и memmove? Очень поучительно - разница в 5-6 раз. Так что 'суперкорректная' memcpy, которая внутри как memmove никому не нужна. А если добавить еще и проверку - не перекрываются ли области - это тоже универсальные тормоза, хотя и меньшие. И добавлять эту проверку чтобы гарантировать работу в очень редких ситуациях перекрытия - значит немного затормозить все. А зачем?? К тому же любой приличный программер это знает.

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

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

Touche! Как минимум, можно предложить оптимизацию ветвления — и тогда получаются действительно принципиально разные функции при формально одинаковом результате.

Я ступил.

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

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

Таких престарелых маразматиков следует гнать из профессии ссаными тряпками.

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

>Такие ошибки объяснимы, понятны и простительны. Непростительно то, что эта поделка не гонялась под valgrind'ом, который такие баги выявляет на раз.

Да. Тоже склонен так думать.

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

Я так думаю, если почитать тред и выгнать из профессии всех тех, кого местные специалисты считают непригодными, то и работать некому будет.

WFrag ★★★★
()

Вообще, это даже хорошо, что многие быдлопрограммы поломались. Будет всем быдлокодерам типа AVL2 урок, что расчитывать на недокументированные возможности библиотеки - это как строить дом на потухшем вулкане, в надежде что он никогда не проснется. Тут вам не винда,никто не будет вставлять костыли что бы быдлопрограмма не валилась. Жестоко, но справедливо.

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

>Ты когда-нибудь сравнивал по производительности memcpy и memmove? Очень поучительно - разница в 5-6 раз.

Ээээ. Я так думаю, в теории не может быть разница 5-6 раз работать. На не пересекающихся областях ничего не мешает memmove вызывать memcpy, а проверка пересекаемости — это константное время.

А на пересекающихся областях и смысла сравнивать нет, memcpy на них не обязан работать.

Где я не прав? Возможно, речь идёт об определённых размерах данных, где сравнение пары значений начинает играть роль?

WFrag ★★★★
()

забавно, но, благодаря данной (пустяковой) теме, моё мнение о белке и фанате несколько изменилось в лучшую сторону ;)

rtk
()

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

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

> и объявить memcpy deprecated. А через год сделать как надо

сделать deprecated функцию, описанную в официальном стандарте на язык?

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

> Будет всем быдлокодерам типа AVL2 урок, что расчитывать на недокументированные возможности библиотеки.

Да они не используют недокументированные, они просто нифига не знают как что memcpy нельзя на пересекающихся областях использовать. В целом им пофиг что написать memcpy или memmove - всего 4 буквы разные.

Вообще линукс превращается если не уже превратился в помойку. Всякие dbusы, xmlы нечитаемые нередактируемые и неудобно обрабатываемые и непонятно вообще зачем нужные, ядро распухает туда всё подряд засовывают - (уже три системы procfs, sysfs, debugfs), gcc с каждым релизом производит всё более объёмный код, а теперь главный разраб за поддержку абсолютно безумно кривого поделия adobe flash. Появляются какие сервисы индексации ставящиеся вместе с kde-base и какие-то 'особые kde-сервисы', которые надо редактировать 'особыми утилитами'. Конфиги давно уже не поправить просто в файлах - появились всякие реестры типа gconf и нездоровые ini-файлы а-ля win3.11. Ещё и opensolaris скончался. Куда идти? На freebsd?

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

-D_FORTIFY_SOURCE=2

переопределяет в исходниках strcpy sprintf на варианты с проверкой буфера,
вполне можно что-то сделать и для замены memcpy на memmove, для обделенных интеллектом , которые не могут сделать это сами.

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

Куда идти? На freebsd?

Кто-то что-то говорил про Plan9

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

>Ещё и opensolaris скончался.

Только не говори, что ты всерьез рассматривал это как вариант десктопной ОС. Я попробовал, очень сильно не понравилось.

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

>вполне можно что-то сделать и для замены memcpy на memmove, для обделенных интеллектом , которые не могут сделать это сами.

#include <string.h>
#define memcpy memmove
linuxfan
()
Ответ на: комментарий от WFrag

> На пенсию, наверное? :)

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

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

> Линус тоже федору юзает?

Что называется, ВНЕЗАПНО!

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

> Только не говори, что ты всерьез рассматривал это как вариант десктопной ОС. Я попробовал, очень сильно не понравилось.

Я работал только не с просто Solaris. Многое делать неудобно, но вот чего там вообще нет - так это мусора, всё четко и понятно работает.

gena2x ★★★
()

А вообще по теме, классно. Похоже у меня должно быть 4x. А так как от memcpy может засисеть процентов 10 производительности надо обновиться :)

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

>Я работал только не с просто Solaris. Многое делать неудобно, но вот чего там вообще нет - так это мусора, всё четко и понятно работает.

Работать удаленно через ssh и держать на рабочем месте — это очень различные вещи.

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

>это обычный closed source софт.

сейчас точно не скажу, но вроде в последней стабильной версии wine (xine-lib? хз) при configure идёт проверка на старые версии binutils по шаблону 2.1[N] - угадайте какая сейчас актуальная версия binutils и что выдаёт эта проверка? =) обычный софт, написанный обычными людьми

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

Выпуск федоры откладывать не надо. Этот дистр как раз и сделан, чтобы улучшать мир. А вот ставить Федору можно только через пол-года.

тут согласен

Без нвидии, флеша и пр. он не юзабелен.

чего это?

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

>лично мне же не совсем ясно с какого перепугу откладывать выпуск дистрибутива - из-за отвалившегося flash?

А так же еще неопределенного кол-ва других прог?

факты есть? в студию

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

флэш нужен нам, и уже сейчас

кому нам, хомячкам с «ютуба»?

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

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

то есть Вы хотите что происходило всё как происходит, но на протяжении полугода? да Вы бюрократ, батенька

//никто и не почешется пока мордой его не тыкнешь

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

> Вообще линукс превращается если не уже превратился в помойку. Всякие dbusы, xmlы нечитаемые нередактируемые и неудобно обрабатываемые и непонятно вообще зачем нужные, ядро распухает туда всё подряд засовывают - (уже три системы procfs, sysfs, debugfs), gcc с каждым релизом производит всё более объёмный код, а теперь главный разраб за поддержку абсолютно безумно кривого поделия adobe flash. Появляются какие сервисы индексации ставящиеся вместе с kde-base и какие-то 'особые kde-сервисы', которые надо редактировать 'особыми утилитами'. Конфиги давно уже не поправить просто в файлах - появились всякие реестры типа gconf и нездоровые ini-файлы а-ля win3.11.

At last GNU/Linux is Enterprise Ready!

Manhunt ★★★★★
()

ttt: use memcpy correctly and problem solved

mmm: memcpy is stil fully usable. You just have to use it in the way it has always been documented to operate


а торвальдз - просто жирный троллина...

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

>А объем какой? Надо хотя бы гигабайт. На современных компах ПСП - десятки гигабайт в секунду, на меньших объемах будет слишком большая погрешность.

Быстродействие очень сильно снижает MMU, и память выделяется походу обращения к ней, а не сразу. На практике скорость перемещения/копирования ~1GB/s

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

>то есть Вы хотите что происходило всё как происходит, но на протяжении полугода? да Вы бюрократ, батенька

Я хочу, чтобы проблема была видна сразу в логах, а не в колонках хрипами флеша. Ничто ведь не мешало добавить в эту версию memcpy проверку аргументов с руганью в логи.

AVL2 ★★★★★
()

Я использовал пару раз memcpy заведомо неправильно, но когда по логике и результатам теста она работала корректно. Хорошо хоть носиты поставил, легко отгрепал эти места.

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

>а торвальдз - просто жирный троллина...

Нет, г-н Торвальдс прав, использовать memcpy для перемещения перекрывающихся блоков если она это позволяет это грязных хак. лучше бы использовали memmove()

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

Ничто ведь не мешало добавить в эту версию memcpy проверку аргументов с руганью в логи.

ничто не мешало писать придерживаясь стандарта

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

Собственно, одни криворукие некорректно пишут, а другие криворукие ведут себя как слон в посудной лавке.

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

> он был, если я правильно понимаю, не бажным до glibc 2.12

Судя по прототипу void *memcpy(void *restrict s1, const void *restrict s2, size_t n);

restriсt

код у них бажный с IEEE Std 1003.1-2001, просто не было нормальной memcpy, на которой этот баг проявлялся...

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

криворукие некорректно пишут,

вот собственно и всё, весь источник проблем в данной ситуации, на то чтобы таких проблем не было и пишутся указания и стандарты, но упырям это всё не указ (ведь работает же, а тогда какие проблемы), правда?

представь: я сделал либу, а ты влез в её внутренние скрытые структуры и на основании этой информации написал код; потом я сделал рефакторинг, не изменяя внешнего интерфейса и у тебя всё отвалилось; и если после всего этого ты прибежал бы ко мне выяснять почему моя либа плохая такая то я ответил бы что ты сам тебе злобный «буратина» и был бы прав

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

>представь: я сделал либу, а ты влез в её внутренние скрытые структуры и на основании этой информации написал код;

А так зачастую и приходится делать.

потом я сделал рефакторинг, не изменяя внешнего интерфейса и у тебя всё отвалилось; и если после всего этого ты прибежал бы ко мне выяснять почему моя либа плохая такая то я ответил бы что ты сам тебе злобный «буратина» и был бы прав

ты прав во всех смыслах. Связался с невменяемым автором либы - сам себе злобный «буратина».

Собственно, весь мой месседж и состоит в том, что мимо glibc не пройдешь. Поэтому это особый случай. Монополия, если хочешь. Со всеми вытекающими...

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

>>представь: я сделал либу, а ты влез в её внутренние скрытые структуры и на основании этой информации написал код;

А так зачастую и приходится делать.

потом я сделал рефакторинг, не изменяя внешнего интерфейса и у тебя всё отвалилось; и если после всего этого ты прибежал бы ко мне выяснять почему моя либа плохая такая то я ответил бы что ты сам тебе злобный «буратина» и был бы прав

ты прав во всех смыслах. Связался с невменяемым автором либы - сам себе злобный «буратина».

Собственно, весь мой месседж и состоит в том, что мимо glibc не пройдешь. Поэтому это особый случай. Монополия, если хочешь. Со всеми вытекающими...

Мне вот страшнее всего что такие как ты потроллил люди есть и пишут софт для атомных элекростанций, плотин, самолетов и кардиостимуляторов. Искренне надеюсь, что никто не пострадает от твоих фантазий.

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

>представь: я сделал либу, а ты влез в её внутренние скрытые структуры и на основании этой информации написал код;

А так зачастую и приходится делать.

основание?

ты прав во всех смыслах. Связался с невменяемым автором либы - сам себе злобный «буратина».

это пусть останется на Вашей совести

Собственно, весь мой месседж и состоит в том, что мимо glibc не пройдешь.

4.2 злостное, да хоть свою запили

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

>основание?

куцая документация, необходимость сделать что-то выходящее за рамки стандартного.

4.2 злостное, да хоть свою запили

Тогда уж и ядро заодно запилить и готова своя ось.

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