Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 526
    • Issues 526
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 93
    • Merge requests 93
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #2921
Closed
Open
Created Sep 28, 2021 by Michał Kępień@michalOwner

Unhandled NULL returns from jemalloc's mallocx()

As documented, jemalloc's mallocx() function can return NULL:

The mallocx() and rallocx() functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned to indicate insufficient contiguous memory was available to service the allocation request.

However, mem_get() does not account for that possibility as commit fcc68147 (!5012 (merged)) removed a NULL check which was previously there. This raises several issues:

  1. Segmentation faults may now happen instead of abort()s. This was proven to be possible by GitLab CI (see GDB output below).

  2. Behavior is inconsistent between jemalloc-enabled and non-jemalloc builds. The latter checks whether each pointer returned by the system malloc() function is NULL and abort()s if it is. The former does not (see GDB output below).

Click here to fold/expand GDB output
Core was generated by `/builds/isc-projects/bind9/lib/isc/tests/.libs/mem_test'.
Program terminated with signal SIGABRT, Aborted.
#0  0xf7f29069 in __kernel_vsyscall ()
[Current thread is 1 (Thread 0xe13f8b40 (LWP 7031))]
(gdb) bt
#0  0xf7f29069 in __kernel_vsyscall ()
#1  0xf7cae382 in raise () from /lib/i386-linux-gnu/libc.so.6
#2  0xf7c982b6 in abort () from /lib/i386-linux-gnu/libc.so.6
#3  0xf7e80cf7 in ?? () from /usr/lib/i386-linux-gnu/libcmocka.so.0
#4  0xf7e80d40 in ?? () from /usr/lib/i386-linux-gnu/libcmocka.so.0
#5  <signal handler called>
#6  0xf7dc06ca in ?? () from /lib/i386-linux-gnu/libc.so.6
#7  0xf7ed108a in memset (__len=<optimized out>, __ch=190, __dest=0x0) at /usr/i686-linux-gnu/include/bits/string_fortified.h:71
#8  mem_get (size=<optimized out>, ctx=0xf5437000) at mem.c:344
#9  isc__mem_get (ctx=0xf5437000, size=65534, file=0x565c4008 "mem_test.c", line=439) at mem.c:752
#10 0x565c164e in mem_thread (arg=0xf5437000) at mem_test.c:439
#11 0xf7ef1996 in isc__trampoline_run (arg=0x57bb1d00) at trampoline.c:185
#12 0xf7e63fd2 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#13 0xf7d796d6 in clone () from /lib/i386-linux-gnu/libc.so.6
(gdb) frame 8
#8  mem_get (size=<optimized out>, ctx=0xf5437000) at mem.c:344
344			memset(ret, 0xbe, size); /* Mnemonic for "beef". */
(gdb) print ret
$1 = 0x0
Assignee
Assign to
Time tracking