2010-11-13

Linus又骂人stupid

Views: 36074 | 15 Comments

最近, 有位用户向 bugzilla.redhat.com 报告他用 Fedora Linux 上网听 MP3 音乐时, 会播放出奇怪的声音. Linux 之父 Linus Torvalds 参与了讨论, 并最终找出原因, 竟然是 glibc 升级了 memcpy() 函数, 导致浏览器的 Abobe Flash Player 插件出现问题.

这真是太强大了, 竟然能从上网听音乐追查到几乎是软件最底层基础的 memcpy() 函数! 如果你想知道他是如何一步一步找出 BUG 的原因的, 可以自己去看贴. (我个人不得不表示非常佩服他们敏锐的技术嗅觉和科学精神!)

这个 BUG 的原因是, 某位 glibc 贡献者(看邮件地址应该是 Intel 公司的某华裔工程师)提交了一个速度更快的 memcpy() 函数的实现并被采纳. 但是, 这个速度更快的 memcpy() 并没有像它的前一个版本一样对源内存和目的内存重叠的情况做兼容, 所以导致了 Flash 插件出问题.

Glibc 认为, memcpy() 函数的手册清楚的说明, memcpy() 所操作的两块内存不能重叠:

MEMCPY(3)                  Linux Programmer's Manual                 MEMCPY(3)

NAME
       memcpy - copy memory area

SYNOPSIS
       #include 

       void *memcpy(void *dest, const void *src, size_t n);

DESCRIPTION
       The  memcpy()  function  copies  n bytes from memory area src to memory
       area dest.  The memory areas should not overlap.  Use memmove(3) if the
       memory areas do overlap.

新版本的 memcpy() 完全遵守标准, 没有任何问题, 完全是 Adobe 的程序员没有编写正确的代码导致了 BUG, 应该算在 Adobe 的头上, 所以把这个报告标记为"NOTABUG(不是 BUG)".

Linus 老大不屑地说, 在 Linux 内核里我们就用了我们自己的非常漂亮的 memcpy(), 而且经过简单测试, 还比所谓的 glibc 的新版本 memcpy() 还要快呢, glibc 的那个速度更快的新版本 memcpy() 根本就是愚蠢至极("There's no real reason to do the copy backwards that I can see, so doing it that way is just stupid."). 毕竟是在 glibc 升级之后才导致了 BUG 的出现, 简单地推卸责任会让用户非常失望.

事情似乎告了一段落, 但是这些个国外的大牛人们的争论, 让我们看到了做技术的人所应该具有的科学态度, 他们据理力争, 反驳有理有据的争论(讨论)方式值得我们学习. 特别是他们敏锐的观察和思考"领域外"的技术细节的精神 - 谁能想到浏览器放音乐出现破音竟然是 glibc 的升级后导致的? - 往往是我们缺少的.

-------------------------------
做个调查: 你支持 Linus 从用户角度考虑? 还是支持 glibc 从标准角度考虑?

你支持谁?

  • 支持 Linus 从用户角度考虑 (53%, 115 Votes)
  • 支持 glibc 从标准角度考虑 (44%, 95 Votes)
  • 弃权 (3%, 8 Votes)

Total Voters: 218

Loading ... Loading ...

Related posts:

  1. 苹果乔布斯撰文说明为何拒绝Flash
  2. 关于 C++ 中的函数指针
  3. SSDB 使用 jemalloc
  4. 把Firefox的播放背景音乐功能去掉
  5. 使用 jemalloc 编译过程出错的问题
Posted by ideawu at 2010-11-13 16:00:08

15 Responses to "Linus又骂人stupid"

  • 唉 今天我就碰到这问题了,我们用的ScientificLinux6.2,用的就是RedHat的内核,glibc版本是2.12,我们的网络数据流解码memcpy从后向前拷贝的内容都是乱的。搜了一下就搜到者文章了。。现在都改成memmove了。。。工作机器上的glibc2.13是没有问题的,应该是后来glibc认识到问题的严重性了? Reply
  • 虽然linus很神,但这次没这么神,通过valgrind给出的警告很容易能做出这个判断。 Reply
  • 按标准,Adobe去改。 Reply
  • 那就让他们骂吧 Reply
  • 大略看了一下bugreport的讨论,最开始发现是glibc问题的是Michael Young,Sitsofe Wheeler跟踪了一下,然后才是Linus 抓到问题根源 :) Reply
  • glibc当然没有错,但是能否考虑一下使用新的memcpy(),毕竟要做到更好 Reply
  • 别忘了14是个以用户为主的发行版。先别扯皮了。把问题解决了再说吧。 Reply
  • 是标准有问题吧,如果能处理为什么不处理重叠的问题?给用户添麻烦?

    =======================================================

    要处理重叠问题的话,请使用memmove()函数。 Reply
  • 是标准有问题吧,如果能处理为什么不处理重叠的问题?给用户添麻烦? Reply
  • linus是这样说的:
    You can call it "crap software" all you like, but the thing is, if memcpy
    doesn’t warn about overlaps, there’s no test coverage, and in that case even
    well-designed software will have bugs.

    Then the question becomes one of "Why break it?"

    关键在于 没有“警告”了 Reply
    所以, linus一方面认为memcpy的标准不应该要求"should not overlap", 另一方面, glibc应该像前一个版本那样正确地处理overlap的情况. Reply

« [1][2] » 1/2

Leave a Comment