LINUX.ORG.RU

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

 ,


0

2

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

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

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

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

★★★★★

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

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

>Я так понимаю что юмористов на ЛОР-е полно, ослоумие так и хлещет, а вот с программистами напряг.

На совсем так. Это не на лоре, это в real world с программистами напряг.

Почитайте, пожалуйста, описание memcpy и его отличие от memmove. Это стандарт! Его обязаны соблюдать.

ну так что с самого начала мешало перезаписывать пересекающиеся блоки? И самое главное, зачем это делать теперь, если скорость реально не увеличилась?

Сейчас же нужно первым пунктом потыкать мордой программистов в man.

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

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

>Кхе-кхе, а что мешало разработчикам glibc реализовать корректную работу функции с самого начала, не?

Я надеюсь, ты не в самом деле такой, а притворяешься. memcpy и memmove ВСЕГДА работали правильно.

linuxfan
()

заберите у пятизвёздочного хотя бы одну и отдайте alx_me!

/me ненавидит дефективных, не читающих документацию

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

Ну тогда GPL3 во все поля. Типа, с нашей душой и пониманием, хоЧем вам всемерно помочь! Не для этого разве Столман GPL придумал? Как раз повод перетащить в OSS кого-нибудь. Ну есть они хотят свои поделки запускать у нас. А они скорее всего его уже в бизнеспланы включили...

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

> GNU/Linux - ОС для специалистов.

Ну и сидите уныло в своем 1%. А нормальные люди софт для пользователя пишут, а не наоборот...

anonymous
()

И самое главное, зачем это делать теперь, если скорость реально не увеличилась?


т.е. соптимизировали под сссе4.2, а работает с той же скоростью, как поделка торвальдза? а вы лопухи развесили и ведётесь - торвальдз же сказал!
и будете здесь повторяться десятки раз (непонятно для кого) вместо того, чтобы написать бенчмарк и ткнуть носом в цифры...

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

Я опасаюсь «отнять и поделить». Сам опасаюсь, и вам не советую. Отнять и перевести в госфонд, можно. Но чтобы прямой личной выгоды не было. А то будет как в высшем образовании. Контрактников холют и лелеют вместо того чтобы гнать. А если бы они денюжку в центр перечисляли а оттуда уже обезличенно в ВУЗы, было бы дело. Ну если коррупцию опустить ;-). Так и со звёздочками. Если конечно наблюдается их строгий дефицит, по типу внутренней валюты ЛОР-а. :-D

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

GNU/Linux - ОС для специалистов.


Ну и сидите уныло в своем 1%. А нормальные люди софт для пользователя пишут, а не наоборот...


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

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

Windows более профессионально сделана там есть печеньки.

RtlCopyMemory function. Its implementation is provided inline.

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

Да сидите-сидите. Мне и нам ваш головняк не нужен. Я не хакер, а чтобы под win/mac писать нужно им быть, иначе ничего путного не напишешь. Плюс полное наплевательство на стандарты. Куча версий одного и того-же. Вечная отладка. Наелись спасибо. До сих пор плАчу смотрю как мой сосед мучается под винды пишет. Несчастный человек. Самая неблагодарная работа - поддержка конечного пользователя. А вот с 1% это вы наверное про десктоп? Так уже более 5 вроде, и растёт (проклятые лемминги). А на нормальных станциях >80%. Оригиналов ставящих на сервер win рассматривать не хочется. Плохо что денюжки выдавливают в экосистему GNU/Linux всё больше таких маргиналов как вы. Не надо. Пусть мы без этих денего будем развиваться медленнее, да. Но не помрём. До этих денег как-то жили.

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

>Они помнят: «Use memmove(3) if the memory areas do overlap». Всё, что ещё обсуждать.

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

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

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

> Оригиналов ставящих на сервер win рассматривать не хочется

Это вовсе не оригинально. Просто нищебродам не понять богатых людей.

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

> И где таких неадекватов то находят?

уже и поржать нельзя.. :(

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

>т.е. соптимизировали под сссе4.2, а работает с той же скоростью, как поделка торвальдза? а вы лопухи развесили и ведётесь - торвальдз же сказал! и будете здесь повторяться десятки раз (непонятно для кого) вместо того, чтобы написать бенчмарк и ткнуть носом в цифры...

Ну если тебе бенчмарки Линуса не подошли, то чем мои бенчмарки помогут?

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

> Я что-то пропустил? Вроде SSE3 уже давным-давным поддерживается AMD.

SSE3 и SSSE3 - это не совсем одно и то же. ;)

Правда у моего Atlhon 64 X2 как раз почему-то cpuinfo и не показывает флага sse3.

Это флаг pni.

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

>Ну тогда GPL3 во все поля. Типа, с нашей душой и пониманием, хоЧем вам всемерно помочь!

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

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

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

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

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

> а работает с той же скоростью

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

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

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

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

Pavval ★★★★★
()

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

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

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

Меня всегда удивляли такие вот псевдо-контра комментарии. Ты чего хотел сказать? Что в большинстве случаев смысла в таких оптимизациях вообще нет? Да и в небольшом проценте «имеют небольшой смысл»? Я вроде о том же говорю. Глупость сделали и вместо того, чтобы быстро исправить ее, залупились и даже на мнение Линуса положили. Мудаки, что и требовалось доказать.

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

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


правда?

rtk
()

и даже на мнение Линуса положили. Мудаки, что и требовалось доказать.


нассали на изваяние боженьки))

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

> Ну всё, предсказываю массовый суицид среди обитателей ЛОРа!!!

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

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

> и даже на мнение Линуса положили

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

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

> Так получается у них был глючный memcpy?

У кого у них? Руки до вылизывания яиц^W memcpy не доходили, а теперь дошли. Стандарт говорит что так должно быть.

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

>и вместо того, чтобы быстро исправить ее

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

devl547 ★★★★★
()

Позицию Линуса хорошо поясняет чужой коммент:

In spite of the NOTABUG, hopefully the glibc developers or Fedora will come up with a more permanent solution because if we have to wait for Adobe to fix flash, hell in several dimensions will have frozen over multiple times.

unsigned ★★★★
()

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

«Зато так нагляднее!», как говорил один товарищ в толксах.

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

Если код открыт. А он открыт. Можно попросить помочь. За небольшое вознаграждение. Список memcpy ограничен grep-ом. Их не может быть сотни на одну программу. Они обычно лежат в основе иерерхии. Весь вопрос в простой постановке звучит как: нужно ли здесь поменять memcpy на memmove. Если сложнее то: нужно ли пересмотреть алгоритм вызова memcpy или сделать тупой s/memcpy/memmove/? Это не сложно, это нудно.

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

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

Это жестокий мир. Но это и есть жизнь - альтернатива: смерть.

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

>а вот результаты:

devl547@ideapad ~/Desktop $ time ./test_memmove

real   0m0.001s
user   0m0.000s
sys   0m0.000s

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

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

>hopefully the glibc developers or Fedora will come up with a more permanent solution

ну так это, костыль с ld_preload. когда были проблемы с lahf его уже использовали.

devl547 ★★★★★
()

Линус че-то не Ъ. В либерасты скатился. То есть троекратное ускорение memcpy ему не «not enough reason».

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

Абалденной насыщености информацией результат! Вы там хоть цикл поставьте какой-то. Хоть полсекунды набейте и укажите прокачку. На уровне погрешности единократный вызов даже первый вызов программы не закешировал. Лучше setitimer с REAL поставить и гонять данный до прихода ALRM. Потом поделить время на прокачку или наоборот.

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

Ну залуди что-нибудь такое, если делать нечего...

#include <string.h> #include <stdlib.h>

#ifndef MAX_OFFSET #define MAX_OFFSET (sizeof (long long)) #endif

#ifndef MAX_COPY #define MAX_COPY (1024 * sizeof (long long)) #endif

#ifndef MAX_EXTRA #define MAX_EXTRA (sizeof (long long)) #endif

#define MAX_LENGTH (MAX_OFFSET + MAX_COPY + MAX_EXTRA)

#define MAX_COUNT 1000

static union { char buf[MAX_LENGTH]; long long align_int; long double align_fp; } u1, u2;

main () { int off1, off2, len, i,count; char *p, *q;

for (off1 = 0; off1 < MAX_OFFSET; off1++) for (off2 = 0; off2 < MAX_OFFSET; off2++) for (len = 1; len < MAX_COPY; len++) { for (count=0;count<MAX_COUNT;count++) p = memcpy (u1.buf + off1, u2.buf + off2, len); if (p != u1.buf + off1) abort (); } exit (0); }

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

>Вы там хоть цикл поставьте какой-то

вот это толщина. осиль посмотреть код Сильви и ее результаты.

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

Так все-таки ускорение есть? А то что-то здесь выше писали, что никакого ускорения и не наблюдается...

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

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

Если индус не в состоянии понять, что так будет только до очередной версии, то это его, индуса, проблемы. Такой extrem programming не нужен.

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