[Bug 2038386] [NEW] gcc -fsanitize=leak crashes immediately

Alexandre Ferrieux 2038386 at bugs.launchpad.net
Tue Oct 3 22:11:46 UTC 2023


Public bug reported:

The Leak Sanitizer in the gcc version bundled with Ubuntu 20.04.6 LTS
has a fatal issue that makes the compiled program crash immediately
(even before main()) with:

  ==28797==Sanitizer CHECK failed: ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:53 
  ((!lsan_init_is_running)) != (0) (0, 0)

This can be exercised even with a trivial program like this one:

  #include <stdio.h>
  #include <stdlib.h>

  int main(int argc,char **argv)
  {
    void *x;
  
    x=malloc(1789);
    printf("Hey I managed to allocate pointer %p !!!\n",x);
    free(x);
    
    exit(0);
  }

compiled with

  gcc -fsanitize=leak foo.c

Then executing "./a.out" yields the above error.

The root cause is an unwarranted assumption that "dlopen() calls only calloc()".
Specific code in liblsan.so allows to solve the chicken-and-egg problem between "dlopen calls calloc" and "instrumenting calloc needs dlopen", and thanks to this, __lsan_init() can then heavily call dlopen(). However, no such think is done for malloc(), which nowadays is also called by dlopen(). As a result, within __lsan_init(), an unprotected malloc() is called by dlopen(), yielding an assert (as the instrumented malloc refuses execution during init).

The initial detection, analysis and (brutal) workaround are documented here: 
https://github.com/magma/magma/issues/15279#issuecomment-1742247833

This bug has been fixed in gcc11+ (by reimplementation of a clean dlopen-specific allocator), but not in gcc9 or gcc10 (which are EOS).
The consequence is that gcc -fsanitize=leak is unusable on 20.04.6 LTS.


---

Description: Ubuntu 20.04.6 LTS
Release: 20.04

gcc:
  Installed: 4:9.3.0-1ubuntu2
  Candidate: 4:9.3.0-1ubuntu2
  Version table:
 *** 4:9.3.0-1ubuntu2 500
        500 http://fr.archive.ubuntu.com/ubuntu focal/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gcc 4:9.3.0-1ubuntu2
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.27
Architecture: amd64
CasperMD5CheckResult: skip
Date: Tue Oct  3 23:51:25 2023
InstallationDate: Installed on 2023-06-22 (103 days ago)
InstallationMedia: Ubuntu 20.04.6 LTS "Focal Fossa" - Release amd64 (20230316)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: gcc-defaults
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gcc-defaults (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug focal

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-defaults in Ubuntu.
https://bugs.launchpad.net/bugs/2038386

Title:
  gcc -fsanitize=leak crashes immediately

Status in gcc-defaults package in Ubuntu:
  New

Bug description:
  The Leak Sanitizer in the gcc version bundled with Ubuntu 20.04.6 LTS
  has a fatal issue that makes the compiled program crash immediately
  (even before main()) with:

    ==28797==Sanitizer CHECK failed: ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:53 
    ((!lsan_init_is_running)) != (0) (0, 0)

  This can be exercised even with a trivial program like this one:

    #include <stdio.h>
    #include <stdlib.h>

    int main(int argc,char **argv)
    {
      void *x;
    
      x=malloc(1789);
      printf("Hey I managed to allocate pointer %p !!!\n",x);
      free(x);
      
      exit(0);
    }

  compiled with

    gcc -fsanitize=leak foo.c

  Then executing "./a.out" yields the above error.

  The root cause is an unwarranted assumption that "dlopen() calls only calloc()".
  Specific code in liblsan.so allows to solve the chicken-and-egg problem between "dlopen calls calloc" and "instrumenting calloc needs dlopen", and thanks to this, __lsan_init() can then heavily call dlopen(). However, no such think is done for malloc(), which nowadays is also called by dlopen(). As a result, within __lsan_init(), an unprotected malloc() is called by dlopen(), yielding an assert (as the instrumented malloc refuses execution during init).

  The initial detection, analysis and (brutal) workaround are documented here: 
  https://github.com/magma/magma/issues/15279#issuecomment-1742247833

  This bug has been fixed in gcc11+ (by reimplementation of a clean dlopen-specific allocator), but not in gcc9 or gcc10 (which are EOS).
  The consequence is that gcc -fsanitize=leak is unusable on 20.04.6 LTS.

  
  ---

  Description: Ubuntu 20.04.6 LTS
  Release: 20.04

  gcc:
    Installed: 4:9.3.0-1ubuntu2
    Candidate: 4:9.3.0-1ubuntu2
    Version table:
   *** 4:9.3.0-1ubuntu2 500
          500 http://fr.archive.ubuntu.com/ubuntu focal/main amd64 Packages
          100 /var/lib/dpkg/status

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: gcc 4:9.3.0-1ubuntu2
  ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
  Uname: Linux 5.4.0-26-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.27
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Tue Oct  3 23:51:25 2023
  InstallationDate: Installed on 2023-06-22 (103 days ago)
  InstallationMedia: Ubuntu 20.04.6 LTS "Focal Fossa" - Release amd64 (20230316)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=fr_FR.UTF-8
   SHELL=/bin/bash
  SourcePackage: gcc-defaults
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/2038386/+subscriptions




More information about the foundations-bugs mailing list