[Bug 2038386] Re: gcc -fsanitize=leak crashes immediately

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


** Description changed:

  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)
+   ==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>
+   #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);
-   }
+   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
+   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).
+ 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 thing 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: 
+ 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
+   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
+  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)

-- 
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 thing 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