Skip to main content ↑ ↓
Topic: What's the point of https://debuginfod.artixlinux.org if it is not maintained? (Read 1430 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Tonight I had to check a bug using valgrind.
And of course valgrind didn't want to start.
The problem? No debug information for the glibc package.

So naturally I check if my debuginfod is running and pointing to the right address.

It is.

So I look at what glibc is installed:
Code: [Select]
glibc 2.41+r65+ge7c419a29575-1

And  then I look at the available images in debuginfod.artixlinux.org:

Code: [Select]
glibc-debug-2.39+r52+gf8e4623421-1-x86_64.pkg.tar.zst
glibc-debug-2.39-1-x86_64.pkg.tar.zst
glibc-debug-2.39-2-x86_64.pkg.tar.zst
glibc-debug-2.39-3-x86_64.pkg.tar.zst
glibc-debug-2.39-4-x86_64.pkg.tar.zst
glibc-debug-2.40+r16+gaa533d58ff-1-x86_64.pkg.tar.zst
glibc-debug-2.40+r16+gaa533d58ff-2-x86_64.pkg.tar.zst
glibc-debug-2.40+r66+g7d4b6bcae91f-1-x86_64.pkg.tar.zst
glibc-debug-2.40-1-x86_64.pkg.tar.zst
glibc-debug-2.41+r2+g0a7c7a3e283a-1-x86_64.pkg.tar.zst
glibc-debug-2.41+r47+g046b33800c3e-1-x86_64.pkg.tar.zst
glibc-debug-2.41+r6+gcf88351b685d-1-x86_64.pkg.tar.zst
glibc-debug-2.41+r9+ga900dbaf70f0-1-x86_64.pkg.tar.zst

A quick check tells me that package was released in April and replaced two weeks later.
-rw-r--r-- 1 root root 10444639 Apr 16 21:19 glibc-2.41+r47+g046b33800c3e-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root      566 Apr 16 21:23 glibc-2.41+r47+g046b33800c3e-1-x86_64.pkg.tar.zst.sig
-rw-r--r-- 1 root root 10444877 Apr 29 19:21 glibc-2.41+r48+g5cb575ca9a3d-1-x86_64.pkg.tar.zst
-rw-r--r-- 1 root root      566 Apr 29 19:24 glibc-2.41+r48+g5cb575ca9a3d-1-x86_64.pkg.tar.zst.sig

Sure, I'm kind of used to it so I know the workaround: I can fetch the sources and rebuild the stuff myself with debug information.
But I would really love for that server to be maintained, if only for glibc. Otherwise, what's the point keeping it around?

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #1 –
Pardon me.  I am not quite sure what you are digging at here.  I am sure it is my ignorance.  Can you possibly explain it again more basically.  I understand we have glibc with debugging that is available.  I don't really understand more than that.

Quote
A quick check tells me that package was released in April and replaced two weeks later.
-rw-r--r-- 1 root root 10444639 Apr 16 21:19 glibc-2.41+r47+g046b33800c3e-1-x86_64.pkg.tar.zst


What package?  That package doesn't seem to have debugging symbols in it. 

I've always understood debugging to be an option in gcc like this

https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

I wasn't aware, or at least I don't remember, that glibc itself can be compiled with versions with debugging symbols or not.  I guess it makes sense since glibc needs to be compiled like anything else.  I have never compiled it, or even thought to compile it.

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #2 –
We also get this when trying to use valgrind. It broke with some recent update
Code: [Select]
==23792== Memcheck, a memory error detector
==23792== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==23792== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
==23792== Command: ./bin/lbry-gtk
==23792== 

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:  
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      memcmp
valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
valgrind:  
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.  The package you need
valgrind:  to install for fix (1) is called
valgrind:  
valgrind:    On Debian, Ubuntu:                 libc6-dbg
valgrind:    On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
valgrind:  
valgrind:  Note that if you are debugging a 32 bit process on a
valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
valgrind:  package (e.g. libc6-dbg:i386).
valgrind:  
valgrind:  Cannot continue -- exiting now.  Sorry.

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #3 –
After some digging around, with the most recent libelf lib32-libelf elfutils debuginfod valgrind packages and the 2.41+r65+ge7c419a29575-1 versions of glibc lib32-glibc packages it works. However, i think these versions of glibc/lib32-glibc came from arch, through the downgrade program

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #4 –
Sorry our automation for the debug packages still has some gap in it somewhere. The toolchain debug packages were there, but they were symlinked which doesn't work with our debuginfod for some reason (??). Should be working now though.

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #5 –
Quote from: mrbrklyn – on
Pardon me.  I am not quite sure what you are digging at here.  I am sure it is my ignorance.  Can you possibly explain it again more basically.  I understand we have glibc with debugging that is available.  I don't really understand more than that.

Quote
A quick check tells me that package was released in April and replaced two weeks later.
-rw-r--r-- 1 root root 10444639 Apr 16 21:19 glibc-2.41+r47+g046b33800c3e-1-x86_64.pkg.tar.zst


What package?  That package doesn't seem to have debugging symbols in it. 

I've always understood debugging to be an option in gcc like this

https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html

I wasn't aware, or at least I don't remember, that glibc itself can be compiled with versions with debugging symbols or not.  I guess it makes sense since glibc needs to be compiled like anything else.  I have never compiled it, or even thought to compile it.
It's not about having debug symbols into the compiled code I'm working on.

Valgrind is a debugging/profiling tool that, among other things, tracks memory usage, overruns, uninitialised data being read, ...
And it can only work if the debug information of some libraries, e.g. glibc, is available. (It needs that to "patch" himself inside.)
Some distribution have the debug symbols packaged separately and some, e.g. Artix, have a "debuginfo" server to make them available.

Here for example, I was trying to track some memory issue deep inside a program and I planned to use valgrind to give me some hints. However since the debuginfo wasn't up to date valgrind refused to launch. My only option was to wait for a fix or recompile glibc myself with debug symbols.


Does this help?

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #6 –
Quote from: Dudemanguy – on
Sorry our automation for the debug packages still has some gap in it somewhere. The toolchain debug packages were there, but they were symlinked which doesn't work with our debuginfod for some reason (??). Should be working now though.
Thank you so much.

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #7 –
Quote from: Dudemanguy – on
Sorry our automation for the debug packages still has some gap in it somewhere. The toolchain debug packages were there, but they were symlinked which doesn't work with our debuginfod for some reason (??). Should be working now though.


If you don't mind me asking, how does one make the error information separate from the main glibc binary?

I see this
https://wiki.archlinux.org/title/Debuginfod

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #8 –
It's just a service that's if installed is used with debuggers/static analysers to pull debug info/symbols for your system (this info is provided by OS packages/maintainers on external server such as https://debuginfod.artixlinux.org/) - Easiest way to trigger this is with gdb when trying to print stacktrace for crashes, before execution it goes over all system libraries and downloads debug symbols at runtime. More info: https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separate-Debug-Files.html

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #9 –
Quote from: Dudemanguy – on
Sorry our automation for the debug packages still has some gap in it somewhere. The toolchain debug packages were there, but they were symlinked which doesn't work with our debuginfod for some reason (??). Should be working now though.
Hi.

I suppose the same issue has occurred.

I don't know how the system is setup but if the symbolic links are present but not visible by debuginfod, would a cronjob that'd run every hour or so and that'd replace every symbolic link with its target work?

Somethink like ...
Code: [Select]
#!/bin/bash
REPOSITORY_DIR=/tmp
set -e
TS=$(date +"%s%N")
find $REPOSITORY_DIR -type l | while read -r symlink; do
    target=$(readlink "$symlink")
    if [ -f "$target" ]; then
        echo "replacing '$symlink' link by its target '$target'"
        mv "$symlink" "$symlink.$TS.bak"
        cp -L "$target" "$symlink"
        rm "$symlink.$TS.bak"
    else
        echo "$symlink target '$target' is not a file"
    fi
done

Where REPOSITORY_DIR is set with the directory of the debug files.

Re: What's the point of https://debuginfod.artixlinux.org if it is not maintained?

Reply #10 –
We fixed it for real this time.