Bug 246599 – Using bmalloc somehow triggers a crash in glibc's free when running free(NULL) in glib library constructor

• Component: bmalloc
• Status: RESOLVED INVALID

[N4t3R]

bmalloc component... since using Malloc=1 avoids the issue, we know something that bmalloc is doing must be to blame... still, this is going to be hard to track down. I don't even know what to try next

Per our converstation on Matrix:Epiphany

[N4t3R]

=4618== Memcheck, a memory error detector
==4618== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==4618== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==4618== Command: epiphany www.heise.de
==4618== Parent PID: 4572
==4618== 
==4618== Warning: set address range perms: large range [0x12708000, 0x5270a000) (defined)
==4618== Warning: set address range perms: large range [0x61c88000, 0x261c88000) (defined)
==4618== Warning: set address range perms: large range [0x61c88000, 0x100000000) (noaccess)
==4618== Warning: set address range perms: large range [0x200000000, 0x261c88000) (noaccess)
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
==4618== Conditional jump or move depends on uninitialised value(s)
==4618==    at 0xB0CC1BE: Inspector::RemoteInspector::listingForInspectionTarget(Inspector::RemoteInspectionTarget const&) const (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0xB0CC552: Inspector::RemoteInspector::listingForTarget(Inspector::RemoteControllableTarget const&) const (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0xB0D0C82: Inspector::RemoteInspector::registerTarget(Inspector::RemoteControllableTarget*) (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0xB550EC3: JSC::JSGlobalObject::init(JSC::VM&) (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0xB558BBD: JSC::JSGlobalObject::finishCreation(JSC::VM&) (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0xA698FCA: JSGlobalContextCreateInGroup (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0xA621121: jscContextSetVirtualMachine(_JSCContext*, WTF::GRefPtr<_JSCVirtualMachine>&&) (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0xA624E56: jscContextConstructed(_GObject*) (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618==    by 0x5385B17: g_object_new_internal (gobject.c:2275)
==4618==    by 0x5386F5B: g_object_new_with_properties (gobject.c:2387)
==4618==    by 0x5387B10: g_object_new (gobject.c:2035)
==4618==    by 0xA6217C9: jsc_context_new (in /usr/lib64/libjavascriptcoregtk-4.1.so.0.3.0)
==4618== 
--4618-- WARNING: unhandled amd64-linux syscall: 434
--4618-- You may be able to write your own handler.
--4618-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--4618-- Nevertheless we consider this a bug.  Please report
--4618-- it at http://valgrind.org/support/bug_reports.html.
==4618== Invalid read of size 8
==4618==    at 0xBF79083: ??? (in /usr/lib64/libhandy-1.so.0)
==4618==    by 0xBF7BE04: ??? (in /usr/lib64/libhandy-1.so.0)
==4618==    by 0x53833C4: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==4618==    by 0x5380538: _g_closure_invoke_va (gclosure.c:895)
==4618==    by 0x5399BF8: g_signal_emit_valist (gsignal.c:3456)
==4618==    by 0x5399E01: g_signal_emit (gsignal.c:3606)
==4618==    by 0x4AE00E4: gtk_container_remove (in /usr/lib64/libgtk-3.so.0.2404.30)
==4618==    by 0x4CF5FB3: ??? (in /usr/lib64/libgtk-3.so.0.2404.30)
==4618==    by 0x53867F7: g_object_run_dispose (gobject.c:1448)
==4618==    by 0xBF7BF42: ??? (in /usr/lib64/libhandy-1.so.0)
==4618==    by 0x4AE1BF7: ??? (in /usr/lib64/libgtk-3.so.0.2404.30)
==4618==    by 0x5380280: g_closure_invoke (gclosure.c:832)
==4618==  Address 0x54a02190 is 0 bytes inside a block of size 64 free'd
==4618==    at 0x484518B: free (vg_replace_malloc.c:872)
==4618==    by 0x53833C4: g_cclosure_marshal_VOID__OBJECTv (gmarshal.c:1910)
==4618==    by 0x5380538: _g_closure_invoke_va (gclosure.c:895)
==4618==    by 0x5399BF8: g_signal_emit_valist (gsignal.c:3456)
==4618==    by 0x5399E01: g_signal_emit (gsignal.c:3606)
==4618==    by 0x4AE00E4: gtk_container_remove (in /usr/lib64/libgtk-3.so.0.2404.30)
==4618==    by 0x4CF5FB3: ??? (in /usr/lib64/libgtk-3.so.0.2404.30)... (144 KB left)

[Michael Catanzaro]

Please post your gdb backtrace.

I thought it was a UI process crash, not a web process crash? Your valgrind output is for the UI process, but it's not useful because the libhandy bug https://gitlab.gnome.org/GNOME/libhandy/-/issues/435 is definitely unrelated. You're crashing when glib calls free(NULL) in a library constructor, before main() and long before the UI is created.

[N4t3R]

: GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-slackware-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
https://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from epiphany...
(gdb) break free
Function "free" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (free) pending.
(gdb) run
Starting program: /usr/bin/epiphany www.heise.de
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/debug/libthread_db.so.1".
Breakpoint 1, 0x00007ffff701c9d0 in free () from /usr/lib64/debug/libc.so.6
(gdb) bt
#0 0x00007ffff701c9d0 in free () at /usr/lib64/debug/libc.so.6
#1 0x00007ffff7343ec5 in g_free (mem=<optimized out>) at ../glib/gmem.c:229
#2 0x00007ffff735ac4c in slice_config_init (config=0x7ffff7420530 <allocator+16>)
at ../glib/gslice.c:440
#3 g_slice_init_nomessage () at ../glib/gslice.c:461
#4 0x00007ffff735bc6e in thread_memory_from_self () at ../glib/gslice.c:562
#5 thread_memory_from_self () at ../glib/gslice.c:552
#6 g_slice_alloc (mem_size=mem_size@entry=96) at ../glib/gslice.c:1052
#7 0x00007ffff732b3ce in g_hash_table_new_full
(hash_func=0x7ffff732ce00 <g_str_hash>, key_equal_func=0x7ffff732cde0 <g_str_equal>, key_destroy_func=key_destroy_func@entry=0x0, value_destroy_func=value_destroy_func@entry=0x0) at ../glib/ghash.c:1073
#8 0x00007ffff732b439 in g_hash_table_new
(hash_func=<optimized out>, key_equal_func=<optimized out>)
at ../glib/ghash.c:1036
#9 0x00007ffff734d9fb in g_quark_init () at ../glib/gquark.c:63
#10 0x00007ffff7308f65 in glib_init () at ../glib/glib-init.c:341
#11 glib_init () at ../glib/glib-init.c:330
#12 glib_init_ctor () at ../glib/glib-init.c:455
#13 0x00007ffff7fcddde in call_init.part () at /lib64/ld-linux-x86-64.so.2
#14 0x00007ffff7fcdec0 in _dl_init () at /lib64/ld-linux-x86-64.so.2
#15 0x00007ffff7fe52d0 in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#16 0x0000000000000002 in ()
#17 0x00007fffffffe9bf in ()
#18 0x00007fffffffe9d1 in ()
#19 0x0000000000000000 in ()
(gdb) quit
A debugging session is active.
Inferior 1 [process 7838] will be killed.
Quit anyway? (y or n) y

[Michael Catanzaro]

Why are there no newlines? It's an unreadable mess. :/ Anyway that confirms it is a UI process crash.

[Michael Catanzaro]

Anyway, so far we know that something bmalloc does before main() is somehow, improbably, responsible for this, because the crash does not occur if you disable bmalloc using the Malloc=1 environment variable.

We also know valgrind doesn't show anything interesting. At first I thought this indicated it was likely that memory corruption is to blame, but really all it indicates is that the bug is somewhere in one of the memory allocators, either bmalloc or glibc. Both get disabled when running under valgrind.

Next step: rebuild glibc with -O0 to try to see more specifically where it is crashing inside free(). We want to see a line number there.

[N4t3R]

Srry i copied it on my phone well being at work.

[N4t3R]

```
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-slackware-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from epiphany...
[?2004h(gdb) break free
[?2004l
[?2004hMake breakpoint pending on future shared library load? (y or [n]) y
[?2004l
Breakpoint 1 (free) pending.
[?2004h(gdb) run
[?2004l
Starting program: /usr/bin/epiphany www.heise.de
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/debug/libthread_db.so.1".

Breakpoint 1, __GI___libc_free (mem=mem@entry=0x0) at malloc.c:3330
3330	  if (mem == 0)                              /* free(0) has no effect */
[?2004h[?2004l
[?2004h(gdb) bt
[?2004l
#0  __GI___libc_free (mem=mem@entry=0x0) at malloc.c:3330
#1  0x00007ffff7339ad5 in g_free (mem=mem@entry=0x0) at ../glib/gmem.c:229
#2  0x00007ffff735085c in slice_config_init (config=0x7ffff74134d0 <allocator+16>)
    at ../glib/gslice.c:440
#3  g_slice_init_nomessage () at ../glib/gslice.c:461
#4  0x00007ffff735187e in thread_memory_from_self () at ../glib/gslice.c:562
#5  thread_memory_from_self () at ../glib/gslice.c:552
#6  g_slice_alloc (mem_size=mem_size@entry=96) at ../glib/gslice.c:1052
#7  0x00007ffff732138e in g_hash_table_new_full
    (hash_func=0x7ffff7322dc0 <g_str_hash>, key_equal_func=0x7ffff7322da0 <g_str_equal>, key_destroy_func=key_destroy_func@entry=0x0, value_destroy_func=value_destroy_func@entry=0x0) at ../glib/ghash.c:1073
#8  0x00007ffff73213f9 in g_hash_table_new
    (hash_func=<optimized out>, key_equal_func=<optimized out>)
    at ../glib/ghash.c:1036
#9  0x00007ffff734360b in g_quark_init () at ../glib/gquark.c:63
#10 0x00007ffff72feec5 in glib_init () at ../glib/glib-init.c:341
#11 glib_init () at ../glib/glib-init.c:330
#12 glib_init_ctor () at ../glib/glib-init.c:455
#13 0x00007ffff7fcfabe in call_init () at /lib64/ld-linux-x86-64.so.2
#14 0x00007ffff7fcfba4 in _dl_init () at /lib64/ld-linux-x86-64.so.2
#15 0x00007ffff7fe5790 in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#16 0x0000000000000002 in  ()
#17 0x00007fffffffe9bf in  ()
#18 0x00007fffffffe9d1 in  ()
#19 0x0000000000000000 in  ()
[?2004h(gdb) quit
[?2004l
[?2004hA debugging session is active.

	Inferior 1 [process 13899] will be killed.

Quit anyway? (y or n) y
[?2004l

```

[Michael Catanzaro]

(In reply to N4t3R from comment #7)
> Breakpoint 1, __GI___libc_free (mem=mem@entry=0x0) at malloc.c:3330
> 3330	  if (mem == 0)                              /* free(0) has no effect */

So the crash is here:

https://github.com/bminor/glibc/blob/7363a9a9a097c455a7ddb9386b4c6f7bdf91065f/malloc/malloc.c#L3330

which is absolutely outrageous. I cannot imagine why initializing bmalloc would possibly cause a simple comparison "if (mem == 0)" to crash. It should return there because mem=0x0, not crash.

Let's do two more commands in gdb:

(gdb) info registers

(gdb) disassemble

This is way beyond what I can help debug, but at least now you've collected a bunch of info that will help. Good luck. :/

[Michael Catanzaro]

Well wait a sec, you're not showing the actual crash. That's just a breakpoint that you've set. Not interesting.

Where does it actually crash? Press 'c' and see how far it gets, or step through it with 'n'.

[Michael Catanzaro]

(Now I'm wondering if it's really crashing in glib_init() at all. Have all of these backtraces been to breakpoints, or is it really crashing there?)

[Michael Catanzaro]

So this was a misunderstanding. Your breakpoint that you set does not indicate any bug. In fact, it looks like you have a web process crash, not anything wrong with your UI process at all, so you've been debugging the wrong process. We'll need to continue discussing this off Bugzilla.