#12 Invalid pointer when verifying root userhelper
Opened by spresti. Modified

While running mock inside of a --privileged fedora container in a GitHub action we have encountered a 'munmap_chunk(): invalid pointer' while running mock.

After trying to repo it the only way we found to repro it was inside the github action, to do so we are using tmate, after that is setup we can cook.

Steps:
- ssh into tmate session
- mock --rebuild --enablerepo=updates-testing rpms/*.src.rpm (though mock does it to)

Result:
munmap_chunk(): invalid pointer

To further debug we used gdp
- gdp --args mock
- run
- t a a bt

Result:

Thread 1 (Thread 0x7fddb0f19a80 (LWP 467) "userhelper"):
#0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1  0x00007fddb1213163 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:78
#2  0x00007fddb11b9fde in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#3  0x00007fddb11a1942 in __GI_abort () at abort.c:79
#4  0x00007fddb11a27a7 in __libc_message_impl (fmt=fmt@entry=0x7fddb13553cd "%s\n") at ../sysdeps/posix/libc_fatal.c:132
#5  0x00007fddb121d265 in malloc_printerr (str=str@entry=0x7fddb1358048 "munmap_chunk(): invalid pointer") at malloc.c:5772
#6  0x00007fddb121d53c in munmap_chunk (p=p@entry=0x5619e4b625a0) at malloc.c:3040
#7  0x00007fddb122201a in __GI___libc_free (mem=mem@entry=0x5619e4b625b0) at malloc.c:3388
#8  0x00007fddb141cec5 in g_free (mem=0x5619e4b625b0) at ../glib/gmem.c:208
#9  0x00005619e32fcafb in wrap (prompt=<optimized out>, user=0x5619e4b61f50 "root", program=<optimized out>, data=0x7ffe8b712ef0, text_conv=0x7ffe8b712e90, argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/usermode-1.114-10.fc41.x86_64/userhelper.c:2097
#10 main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/usermode-1.114-10.fc41.x86_64/userhelper.c:2517

This seems to come from mock doing a check to verify root.

Currently you can see this failure here


Metadata Update from @spresti:
- Issue private status set to: True

Also, after some more debugging I found that issue might stem from a change with glibc. After downgrading to glibc-2.40-14.fc41 we no longer get the error. Instead we get Insufficient rights, (running as root)

Metadata Update from @spresti:
- Issue private status set to: False (was: True)

Metadata