标签: eglibc

我有一个可执行文件,几乎只依赖于libc.ldd的输出是:

libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b53156b9000)
libutil.so.1 => /lib64/libutil.so.1 (0x00002b53158d5000)
librt.so.1 => /lib64/librt.so.1 (0x00002b5315ad8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b5315ce2000)
libm.so.6 => /lib64/libm.so.6 (0x00002b5315ee6000)
libc.so.6 => /lib64/libc.so.6 (0x00002b5316169000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a06600000)

我已经编译了这个和旧的CentOS 6.运行/lib64/libc.so.6说:

GNU C Library stable release version 2.5, by Roland McGrath et al.
...

在任何其他版本的linux上运行此可执行文件有多安全？具体来说,在Ubuntu和Debian机器上运行是否安全eglibc？我编译的可执行文件似乎在12.04 LTS上正常运行但是我可以相信这没有微妙的错误并且还运行在这些发行版的其他版本上吗？

[这是冗长而充满细节的.我的具体问题由下面的粗体字问题引入.]

摘要

我们在valgrind下运行一些测试套件,遇到一个对我来说没什么意义的错误.我正在寻找有关更详细地弄清楚可能出错的建议.

• Valgrind抱怨"写8号无效".
• 从运行到运行,错误是一致的,但是应该是不相关的代码更改,不同的编译器/ stdlib版本等.
• 写入的地址位于堆栈中,据我所知,这是我们编写代码的完全合理的地址.
• 它的对齐与写入的大小一致.
• 它发生的地方深入标准库内部.

所有这些都闻起来好像真正的问题在其他地方:某些东西正在变得腐败并导致后来的混乱.但这是valgrind报告的第一个问题,所以如果在其他地方有内存踩踏,那么valgrind就无法抓住它.我怀疑要么我错过了一些明显的东西,要么有一个微妙的问题,那些具有比我更有专业知识的人可能能够指出我.

一些细节

以下是一些细节和一些具体问题.

这是在x64硬件上运行Ubuntu 14.04的Linux机器上.

这是valgrind在一个相当典型的例子中的抱怨:

==14259== Invalid write of size 8
==14259==    at 0x662BBC9: __printf_fp (printf_fp.c:663)
==14259==    by 0x6629792: vfprintf (vfprintf.c:1660)
==14259==    by 0x664D578: vsnprintf (vsnprintf.c:119)
==14259==    by 0x52DCE0F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==14259==    by 0x52E3263: std::ostreambuf_iterator<char, std::char_traits<char> > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::_M_insert_float<double>(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, char, double) const (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==14259==    by 0x52E354F: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, double) const …

我正在调用malloc_info(3)并获取 XML 输出。

我在网上找到的所有内容都说明了“这可能会发生变化，我们不会费心记录它”。

但这对于调查潜在内存碎片问题的人来说并不是非常有用。

以下是一些片段：

<malloc version="1">
  <heap nr="0">
    <sizes>
      <size from="257" to="257" total="257" count="1"/>
    </sizes>
    <total type="fast" count="0" size="0"/>
    <total type="rest" count="1" size="257"/>
    <system type="current" size="303104"/>
    <system type="max" size="303104"/>
    <aspace type="total" size="303104"/>
    <aspace type="mprotect" size="303104"/>
  </heap>

  <heap nr="1">
    <sizes>
      <size from="17" to="32" total="96" count="3"/>
      <!-- etc. -->
      <size from="10609" to="10609" total="10609" count="1"/>
      <unsorted from="145" to="209" total="740" count="4"/>
    </sizes>
    <total type="fast" count="95" size="7328"/>
    <total type="rest" count="2633564" size="112589836"/>
    <system type="current" size="2032623616"/>
    <system type="max" size="2032947200"/>
    <aspace type="total" size="19451904"/>
    <aspace …

为了磨练我的C技能,我下载了eglibc源代码,我遇到了strncpy.我不明白他为什么要区分n <= 4并进行4次测试的情况.

int
STRNCMP (const char *s1, const char *s2, size_t n)
{
  unsigned char c1 = '\0';
  unsigned char c2 = '\0';

  if (n >= 4)
    {
      size_t n4 = n >> 2;
      do
    {
      c1 = (unsigned char) *s1++;
      c2 = (unsigned char) *s2++;
      if (c1 == '\0' || c1 != c2)
        return c1 - c2;
      c1 = (unsigned char) *s1++;
      c2 = (unsigned char) *s2++;
      if (c1 == '\0' || c1 != c2)
        return c1 - …