[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22085: 25.0.50; src/gmalloc.c hit by gcc >= 5 optimization
From: |
Wolfgang Jenkner |
Subject: |
bug#22085: 25.0.50; src/gmalloc.c hit by gcc >= 5 optimization |
Date: |
Thu, 03 Dec 2015 18:53:25 +0100 |
User-agent: |
Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.1.50 (berkeley-unix) |
On systems which use src/gmalloc.c but don't define HYBRID_MALLOC that
file defines global replacements for malloc and other memory management
functions.
Strictly speaking, this results in undefined behaviour according to ISO
C11 (wg14 n1570 draft) 7.1.3 and 7.22.3.
But it used to work. However, with recent gcc versions and the default
optimization level (-O2), most of the definition of calloc is replaced
with a call to calloc (which the linker resolves to a call to that same
calloc). Chances are temacs crashes because some library calls calloc.
This happens with the gcc 5.2.0 release and also with the 6.0.0 20151108
snapshot.
Please find below a self-contained test program which shows the problem
(try gcc5 -Wall -g -O2 callocopt.c -o callocopt && ./callocopt 666, and
then with -O instead of -O2, or even with -O2 -fno-optimize-strlen).
For comparison purposes, I note that, meanwhile, the issue has also
surfaced here
http://permalink.gmane.org/gmane.os.freebsd.devel.cvs.src/210733
Back to the problem with gmalloc.c, I'd suggest the simple
toolchain-independent work-around given in the patch below.
A real fix is to use hybrid malloc.
callocopt.c
Description: Test program
0001-src-gmalloc.c-Always-define-gmalloc-and-friends.patch
Description: gcc 5 optimization work-around for gmalloc
- bug#22085: 25.0.50; src/gmalloc.c hit by gcc >= 5 optimization,
Wolfgang Jenkner <=