LINUX.ORG.RU

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

 ,


0

2

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

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

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

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

★★★★★

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

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

>Ну так они и исправили. А то что остальные не осилили - это их проблемы.

Одним серьезным аогументом против выпуска софта под линукс больше.

AVL2 ★★★★★
()

не понимаювсей этой поднявшейся вони вокруг пустяка.

ой, дайте нам ворнинг или крэш вместо неопределённого поведения...

а я крут - я написал инжект, сохраняющий совместимость с поделками криворученков...


а что не включить мыслительный орган и не добавить в инжект проверку с выбрасыванием ворнинга? - тогда каждый крутин, не умеющий (или брезгующий) читать документацию, увидит письменное свидетельство о криворучие (в виде ворнинга)...
да, это будет работать медленнее, зато можно продолжать смотреть ютубу и богомерзкие баннера...

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

http://article.gmane.org/gmane.comp.lib.glibc.alpha/15278

From: H.J. Lu <hongjiu.lu <at> intel.com> Subject: PATCH: Improve 64bit memcpy/memmove for Atom, Core 2 and Core i7 Newsgroups: gmane.comp.lib.glibc.alpha Date: 2010-06-25 21:40:11 GMT (19 weeks, 5 days, 11 hours and 17 minutes ago)

Hi,

This patch includes optimized 64bit memcpy/memmove for Atom, Core 2 and Core i7. It improves memcpy by up to 3X on Atom, up to 4X on Core 2 and up to 1X on Core i7. It also improves memmove by up to 3X on Atom, up to 4X on Core 2 and up to 2X on Core i7.

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

>Похоже, зависит от версии gcc, флагов и фазы луны. Или исходники пропатчили.

а также от наличия #include <string.h>

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

Прошу прощения, а что были проблемы с возвратом void *dest в memcpy? Ъ.

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

> Одним серьезным аогументом против выпуска софта под линукс больше

Ну слава богу! Быдлокодеры будут обходить нас стороной. Хоть вирусов не будет.

То есть НЕ признавать свои ошибки это признак умного программиста под windows? Я вас правильно понял?

alx_me ★★☆
()

>/home/torvalds/mymemcpy.so

/home/torvalds/

/torvalds



Как дерзко :)

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

>То есть выпуск быдлокода, не соответствующего стандарту - это нормально?

не то, чтобы нормально, но востребовано. Люди платят за скорость и реализованный функционал. Ни разу не видел, чтобы платили за «небыдлокод»

И мешает этому в том числе отсутствие удобных средств аудита кода. В том числе закрытого.

В принципе, наличие в коде вызова ненадежной функции memcpy уже должно быть криминалом.

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

В принципе, наличие в коде вызова ненадежной функции memcpy уже должно быть криминалом.


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

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

> пруф

Пуф-пуф!

Написано: SSE,MMX что нам намекает на блочные пересылки по 128 бит и больше. То есть чем больше массив тем больше выигрыш. Однако на анализ размера буфера уходит время, и если он небоьшой, то анализ съедает то время которое он мог бы уже копировать. Кроме того размер буфера редко чётко попадает в align что требует обработки в конце копирования и/или в начале. Что тут пруфить?

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

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

Может, вам еще и фотошоп с «вордом» подавай?

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

да-да, это фича. Опенсорц такой опенсорц...

Вот и еще один, никогда не читающий манов...

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

> Люди платят за скорость и реализованный функционал.

Выше было про леммингов. Могу добавить что Люди платят за расширяемость, структуру, прозрачность и логическую безупречность. За то что вы сказали платят нувориши и бараны ничерта не смыслящие в области куда они залезли, либо умные временщики.

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

> Опенсорц такой опенсорц...

Какое оригинальное имя, и главное с претензией на ослоумие. Читайте man memcpy и выше по тексту, там всё есть.

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

>То есть НЕ признавать свои ошибки это признак умного программиста под windows? Я вас правильно понял?

при чем тут свои или не свои ошибки? Речь идет о миллионах копиях. И о пользователях, которых сделали крайними.

Еще раз, шла бы речь про некую либу, например, libiconv, которая используется в pure-ftpd. Это было бы одно. Но в основной либе системы не должно быть таких резких движений. Все последовательно и с планом поэтапного исправления ситуации.

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

> > Наш ответ: -static

Такой ответ может дать лишь Adobe, а флэш нужен нам, и уже сейчас.

Не понял чем «нам» не угодил statifier? Кроме того gnash и lightspark, не?

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

>Да причём тут оптимизация? Вам нужно скопировать область памяти. Вы крутой программист. Мы знаете что что-то там про mem чего-то ам и нужно. В открываете man и читаете. Это школьники ничего не читают, потому-то знают.

Тебе сколько лет?

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

Нет это вы не поняли. GNU/Linux нет множества версий. Есть одна - последняя. Поэтому крайних быть не может. Они исправили, вы обновились - всё. Если сами не можете исправить, не обновляйтесь и ждите (это я пользователям, не вам лично).

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

>и в чём её ненадёжность? она не работает? не копирует данные? теряет часть данных?

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

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

>Написано: SSE,MMX что нам намекает на блочные пересылки по 128 бит и больше. То есть чем больше массив тем больше выигрыш. Однако на анализ размера буфера уходит время, и если он небоьшой, то анализ съедает то время которое он мог бы уже копировать. Кроме того размер буфера редко чётко попадает в align что требует обработки в конце копирования и/или в начале. Что тут пруфить?

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

Да и данные обычно килобайтами гоняются. А если у теюя специальный случай, то никто тебе не мешает memmove или bcopy юзать.

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

Для меня уже всё поздно. Это ваш ответ на мой, где я вам сказал что мне 32. Там же я вам сказал что я более 5 лет разрабатываю ПО под GNU/Linux и не Java. Ещё вопросы интимные будут? Я уже потею.

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

>Одним серьезным аогументом против выпуска софта под линукс больше.

конечно, куда удобней поддерживать зоопарк undocumented bugs и т.п.

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

>А почему она не выдает segfault?

Потому что while(n--) {*p++ = *q++}; абсолютно легальный код (и соответствующий ассемблерный, конечно, тоже) независимо от взаиморасположения p и q. Чтобы сегфолтнуться, надо специально проверить, что |p-q|<n. А если такую проверку делать — как раз и получается memmove.

Разве что желающим девелоперам выдать специальную отладочную glibc, чтобы заменили mamcpy там, где надо.

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

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

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

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

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

WFrag ★★★★
()

Решето /post

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

>Нет это вы не поняли. GNU/Linux нет множества версий. Есть одна - последняя. Поэтому крайних быть не может. Они исправили, вы обновились - всё. Если сами не можете исправить, не обновляйтесь и ждите (это я пользователям, не вам лично).

Во первых, не обновившись ты и не узнаешь, что там сломалось, а обновившись, поздно пить боржом.

во вторых, при обновлениях обновляется куча программ. Что там сломало все - кто его знает.

Так что рекомендация должна быть следующая. При установке убедитесь, что весь ваш софт работает и больше не обновляйтесь. Никогда.

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

Ну и так, на всякий случай. в линукс есть множество версий. Есть сонеймы. Есть LD_LIBRARY_PATH.

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

> Разве что желающим девелоперам выдать специальную отладочную glibc,

:-D жжоте! Их кучи и многие завязаны на переменные окружения, то есть динамически включаешь/выключаешь. Есть расширения для отладки, короче :-D!

А SEGV даётся только при попытке доступа к не выделенной памяти или RO/const или iomap портам. А так, в своей памяти топчи как хочешь, свому потоку, братскому, благо езыг Цэ это позволяет, но требует наличия отсутствия ламера за игровым столом. ;-)

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

>конечно, куда удобней поддерживать зоопарк undocumented bugs и т.п.

Везде свои недостатки. Но поломка софта, это поломка софта. На это должны были быть особые причины.

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

Не поверите, каждый раз читаю, всё время путаю dest и source. :-) На память в таких узловых вещах я не полагаюсь. Не так часто это нужно чтобы зубить. Но когда надо, понтоваться мне уже не надо, я лучше прочту ещё разик.

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

>Не поверите, каждый раз читаю, всё время путаю dest и source. :-) На память в таких узловых вещах я не полагаюсь. Не так часто это нужно чтобы зубить. Но когда надо, понтоваться мне уже не надо, я лучше прочту ещё разик.

Вот! А кто-то (чуть более умный :) который помнит позиции src и dest пишет код с багами!

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

>Выше было про леммингов. Могу добавить что Люди платят за расширяемость, структуру,

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

прозрачность и логическую безупречность.

В каких это мирах?

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

вы думаете что флеш компилят без -O2


Запросто. Коммерческий код вообще очень редко компиляют с -O2. Максимум на что их хватает на -Os, а так -O0 -d.

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

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

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

> А лучше вообще не пользуйтесь линуксом, потому что всем похрен, что там у вас сломалось и самое главное, как вы там будете выходить из ситуации.

Единственный способ выйти из ситуации это родить. Я не понимаю о чём вы вообще. Вы о рядовых пользователях, и я вам о рядовых. Вы о ситуации как она есть животрепещущая, и я вам о том же. И опять про рядовых. Вы где видели чтобы рядовой польщователь в чём-то там хотел разобраться? Единственный привычный и интуйтивно понятный способ устранить проблему для них это переустановить(им не привыкать). Для тех кто понял как ЭТО работает - обновить систему когда на форуме дадут отмашку. Чем это будет отличаться от m$ sp10 для Vist-ы? Я уже беру за скобки тот факт что тот кто не желает учится должен оставаться на windows. Программисты уже наелись продуктом билли и его лозунга что домохозяйка должна пользоваться компьютером. Леммингу губят экосистему которая создала то что они так жаждут - стабильность и красоту. То что эта красота периодически становится на медосмотр не простого ума дело. Может он будет и против периодических кризисов науки. Так пусть вообще не пользуется вычислитеьной техникой - она ведь продукт этой самой науки.

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

>>конечно, куда удобней поддерживать зоопарк undocumented bugs и т.п.

Везде свои недостатки. Но поломка софта, это поломка софта. На это должны были быть особые причины.

Как вариант можно сделать

#ifdef USE_FAST_MEMCPY

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

и объявить memcpy deprecated. А через год сделать как надо. Но где гарантия, что за год кто-то почешется? ИМХО надо именно так. Тогда и результат будет. И маны начнут уважать. Это как однострочник на perl. Жестоко, но действенно.

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

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

Если бы программы писались как-то иначе, этот аргумент бы ещё имел смысл :)

Попрбуйте пообщаться с простыми пользователями или QA, предварительно выключив «ЧСВ программиста».

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

> которая через пол-года сдохнет при обновлении глибца

Стандарт никто не отменял. Обновление glibc не при чём. Если код открыт проблема будет устранена в кратчайшие сроки. Открывайте код. В этом стратегия GPL.

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

тут в теме дали несколько полезныз рекомендаций:

во-первых увеличьте размер региона ( SZ ) чтобы он значительно превышал обьем L2 кэша
во-вторых перед циклом заполните чем-нибудь память
memset ( area1, 32, SZ ) ;
например

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

Хочется писать через жопу, милости просим в мир .NET/Java и прочей виртуальщины. Тут же речь про системные библиотеки. Я уверен что в Java уже обошли, если он был, этот вопрос. То есть им думать не надо, за них уже подумали.

Если я грубоват, то замените «через жопу» на «не париться».

alx_me ★★☆
()

>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)


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

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

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


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

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