glibc | 易学教程

《Glibc内存管理》笔记DAY2

阅读更多关于《Glibc内存管理》笔记DAY2

目录 Ptmalloc内存管理设计 Main_arena 与 non_main_arena chunk 的组织空闲 chunk 容器 sbrk 与 mmap 内存分配概述内存回收概述边界标记法内容来源 Ptmalloc内存管理设计具有长生命周期的大内存分配使用 mmap。特别大的内存分配总是使用 mmap。具有短生命周期的内存分配使用 brk，因为用 mmap 映射匿名页，当发生缺页异常时，linux 内核为缺页分配一个新物理页，并将该物理页清 0，一个 mmap 的内存块需要映射多个物理页，导致多次清 0 操作，很浪费系统资源，所以引入了 mmap分配阈值动态调整机制，保证在必要的情况下才使用 mmap 分配内存。尽量只缓存临时使用的空闲小内存块，对大内存块或是长生命周期的大内存块在释放时都直接归还给操作系统。对空闲的小内存块只会在 malloc 和 free 的时候进行合并，free 时空闲内存块可能放入 pool 中，不一定归还给操作系统。收缩堆的条件是当前 free 的块大小加上前后能合并 chunk 的大小大于 64KB，并且堆顶的大小达到阈值，才有可能收缩堆，把堆最顶端的空闲内存返回给操作系统。需要保持长期存储的程序不适合用 ptmalloc 来管理内存。为了支持多线程，多个线程可以从同一个分配区（arena）中分配内存，ptmalloc假设线程

自定义镜像上传阿里云

阅读更多关于自定义镜像上传阿里云

主要内容： 1、alpine制作jdk镜像 2、Alpine制作jre镜像（瘦身） 3、Docker镜像上传至阿里云 alpine制作jdk镜像 alpine Linux简介 1.Alpine Linux是一个轻型Linux发行版，它不同于通常的Linux发行版，Alpine采用了musl libc 和 BusyBox以减少系统的体积和运行时的资源消耗。 2.Alpine Linux提供了自己的包管理工具：apk(注意：ubuntu中是apt-get)，我们可以通过https://pkgs.alpinelinux.org/packages 查询包信息 3.Alpine Docker镜像继承了Alpine Linux发行版的这些优势，相比于其他Linux Docker镜像，它的体积非常小对比常用的、没有压缩过的基础镜像（查看当前的:latest标签）： Alpine - 4.8MB centos - 124.8 MB Debian - 125.1MB Centos - 196MB 4.建议使用Alpine Linux 3.10.0版本，这也是 v3.10 稳定系列的首个版本 alpine:3.10 基于alpine制作JDK8镜像 #1.下载镜像 docker pull alpine:latest #2.创建并编辑dockerfile touch Dockerfile vi

Since the Standard C committee did not standardize a simple replacement for gets(), what should it be?

阅读更多关于 Since the Standard C committee did not standardize a simple replacement for gets(), what should it be?

问题 The gets function was first deprecated in C99 and finally removed in C11. Yet there is no direct replacement for it in the C library. fgets() is not a drop-in replacement because it does not strip the final '\n' , which may be absent at the end of file. Many programmers get it wrong too. There is a one-liner to remove the linefeed: buf[strcspn(buf, "\n")] = '\0'; , but it is non-trivial and often calls for an explanation. It may be inefficient as well. This is counter-productive. Many

Static linking of Glibc

阅读更多关于 Static linking of Glibc

问题 How can i compile my app linking statically glibc library, but only the code needed for my app? (Not all lib) Now my compile command: g++ -o newserver test.cpp ... -lboost_system -lboost_thread -std=c++0x Thanks! 回答1: That's what -static does (as described in another answer): unneeded modules won't get linked into your program. But your expectations on the amount of stuff which is needed (in a sense that we can't convince linker to the contrary) may be too optimistic. If you trying to do it

How compatible are different versions of glibc?

阅读更多关于 How compatible are different versions of glibc?

问题 Specifically: Is it assured somehow that all versions of glibc 2.x are binary compatible? If not, how can I run a binary (game) on my system which has been compiled for a different version? Can I install glibc in a different folder? My specific problem is the compatibility between glibc 2.14 (what I have) and 2.15 (what the game wants). I might also get a version for glibc 2.13 but I'm not sure if that will run on 2.14. 回答1: In general, running binaries that were compiled for an older glibc

Pthread mutex assertion error

阅读更多关于 Pthread mutex assertion error

问题 I'm encountering the following error at unpredictable times in a linux-based (arm) communications application: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed. Google turns up a lot of references to that error, but little information that seems relevant to my situation. I was wondering if anyone can give me some ideas about how to troubleshoot this error. Does anyone know of a common cause for this assertion? Thanks in advance. 回答1: Rock solid for

What is the recommended way to perform source-level debugging of system library calls?

阅读更多关于 What is the recommended way to perform source-level debugging of system library calls?

问题 I have a need to debug into some calls in system libraries, to understand how the calls differ, and why one or another would be failing. It is now common for Linux distros to provide stripped system libraries and separate debug symbol files. For example, /lib/libc-2.8.so is stripped of symbols, leaving behind a section named .gnu_debuglink that contains info to find a separate debug file. The separate debug files are installable through a debug package, and contain symbolic info needed by gdb

Linking GLIBC statically and proprietary software licensing [closed]

阅读更多关于 Linking GLIBC statically and proprietary software licensing [closed]

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 4 years ago . I have basic understanding problem with open source and licenses. Could someone please clarify some questions for the below scenario. Excuse me if it is very basic I'm writing a proprietary software in which i plan to use some open source libraries. I will also need glibc and a C compiler, but did not want to

Configuring for a compiler different than the default while running configure

阅读更多关于 Configuring for a compiler different than the default while running configure

问题 I am compiling the glibc library. Before I could do that, I need to run configure . However, for compiling glibc, I need to use the gcc compiler which is not the default compiler on the machine. The manual says the following. It may also be useful to set the CC and CFLAGS variables in the environment when running configure. CC selects the C compiler that will be used, and CFLAGS sets optimization options for the compiler. Now my problem is that I don't have any administrative rights on that

glibc backtrace - can't redirect output to file

阅读更多关于 glibc backtrace - can't redirect output to file

问题 I'm in the process of debugging a C program (that I didn't write). I have all of the internal debugging tools (a whole bunch of printf's) enabled, and I wrote a small PHP script that uses proc_open() and just grabs both stdout and stderr, and time-coordinates them in one file. At the moment, the binary is dieing with a realloc() error that's caught by glibc, and a glibc backtrace is printed, beginning with: *** glibc detected *** /sbin/rsyslogd: realloc(): invalid next size: