Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: [SOLVED] valgrind doesn't work (Read 5395 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: [SOLVED] valgrind doesn't work

Reply #30 –
Quote from: ####### – on
I have no debug repos in my pacman.conf, just system, world, galaxy, lib32, universe, omniverse, extra, community and multilib, but valgrind always worked fine for me. However if it's mirror related, it has been my experience that often some Artix mirrors are better synced / updated than others, indeed I was updating a fresh install just recently and got a package not found error, looked at the mirrorlist, commented out the top one, it worked then. So possibly check /etc/pacman.d/mirrorlist. Failing that, perhaps try configuring an alternative dns nameserver as another possibility? Occasionally it can help with odd connection issues.

It's not a connection issue either... I can do telnet debuginfod.artixlinux.org  8002 fine. Can we remove this big SOLVED mark from thread? It's giving me goosebumps since the whole thing is so hopeless...

Re: [SOLVED] valgrind doesn't work

Reply #31 –
Quote from: jfffffffra4 – on
You mean like this?

Code: [Select]
[system-debug]
Include = /etc/pacman.d/mirrorlist

[world-debug]
Include = /etc/pacman.d/mirrorlist

[galaxy-debug]
Include = /etc/pacman.d/mirrorlist

That didn't do the trick, but valgrind seems to be working again.
Looks like it requires some rest from time to time C:
Are those repos working on Your distro? I got errors, that $repo-debug doesn't exist on [mirror].

And all in all can valgrind be fixed by user or we need to wait for developers?

Re: [SOLVED] valgrind doesn't work

Reply #32 –
Quote from: h3xo – on
Are those repos working on Your distro? I got errors, that $repo-debug doesn't exist on [mirror].

And all in all can valgrind be fixed by user or we need to wait for developers?

No, these mirrors don't exist. At least I got 404 on them.

The problem is in the debuginfod remote thing for sure.. It was working for a couple of hours and now it doesn't while I didn't change my system at all (didn't even update or install any packages). The most viable assumption is debug package is corrupted on the server and maybe putting -fno-builtin-strlen flag will work but I'm not sure where I should contact about it....

Re: [SOLVED] valgrind doesn't work

Reply #33 –
Looks like it is still working here:
Code: [Select]
$ nano valgrindtest.c
$ gcc -g valgrindtest.c -o valgrindtest
$ valgrind ./valgrindtest 
==3335== Memcheck, a memory error detector
==3335== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3335== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==3335== Command: ./valgrindtest
==3335== 
==3335== 
==3335== HEAP SUMMARY:
==3335==     in use at exit: 0 bytes in 0 blocks
==3335==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==3335== 
==3335== All heap blocks were freed -- no leaks are possible
==3335== 
==3335== For lists of detected and suppressed errors, rerun with: -s
==3335== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
$ pakku -Qi valgrind debuginfod
Name            : valgrind
Version         : 3.19.0-5
Description     : Tool to help find memory-management problems in programs
Architecture    : x86_64
URL             : http://valgrind.org/
Licenses        : GPL
Groups          : None
Provides        : valgrind-multilib
Depends On      : glibc  perl  debuginfod
Optional Deps   : lib32-glibc: 32-bit ABI support [installed]
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : valgrind-multilib
Installed Size  : 86.28 MiB
Packager        : Artix Build Bot <[email protected]>
Build Date      : Tue 02 Aug 2022 09:20:50 AM BST
Install Date    : Fri 30 Sep 2022 03:07:55 AM BST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

Name            : debuginfod
Version         : 0.188-1
Description     : Handle ELF object files and DWARF debugging information (debuginfod)
Architecture    : x86_64
URL             : https://sourceware.org/elfutils/
Licenses        : LGPL3  GPL3
Groups          : None
Provides        : None
Depends On      : gcc-libs  glibc  libarchive  libarchive.so=13-64  libelf=0.188  libmicrohttpd  libmicrohttpd.so=12-64  sqlite  libsqlite3.so=0-64
Optional Deps   : elfutils=0.188: for translations [installed]
Required By     : valgrind
Optional For    : binutils
Conflicts With  : None
Replaces        : None
Installed Size  : 355.40 KiB
Packager        : Artix Build Bot <[email protected]>
Build Date      : Wed 30 Nov 2022 09:05:54 PM GMT
Install Date    : Sun 04 Dec 2022 04:03:53 PM GMT
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature
So, unless there is some strange Taured parallel universe thing going on, you can probably rule out the 'global' causes, it's something to do with your particular setup, or internet connection. There is such a thing as online content caching or blocking, which is why I suggested trying another dns server, especially if you have some oddball ISP. I sometimes go to look at this forum and get an error then refresh the page and it appears, some of these Artix resources aren't like big multinational sites, they get briefly overloaded. Also check versions and origins of relevant things carefully, have you got any Arch repos enabled above Artix ones, did you migrate from Arch and still have some Arch packages at the same version as Artix ones, do you have Gremlins, Testing or other non standard  packages which might not match versions? It's unlikely, but have you checked your drive health and FS?

Re: [SOLVED] valgrind doesn't work

Reply #34 –
Quote from: ####### – on
So, unless there is some strange Taured parallel universe thing going on, you can probably rule out the 'global' causes, it's something to do with your particular setup, or internet connection. There is such a thing as online content caching or blocking, which is why I suggested trying another dns server, especially if you have some oddball ISP. I sometimes go to look at this forum and get an error then refresh the page and it appears, some of these Artix resources aren't like big multinational sites, they get briefly overloaded. Also check versions and origins of relevant things carefully, have you got any Arch repos enabled above Artix ones, did you migrate from Arch and still have some Arch packages at the same version as Artix ones, do you have Gremlins, Testing or other non standard  packages which might not match versions? It's unlikely, but have you checked your drive health and FS?

Well, I don't know if it is related, but I put Yandex DNS into my /etc/resolv.conf file to avoid DDNS of my ISP and it seems working for now. I hope it'll last  :-\ The thing is that local experiments with network break stuff like that is so annoying... Thank you for your patience everyone :)

Re: [SOLVED] valgrind doesn't work

Reply #35 –
Bad news: it's broken once again - DNS thing didn't solve it. Moreover, I tested valgrind setup in my Arch Linux machine with "oddball" DDNS my ISP provides and it works fine. Any more ideas?  ???

My system is updated, my repos in pacman.conf:

Code: [Select]
[system]
Include = /etc/pacman.d/mirrorlist

[world]
Include = /etc/pacman.d/mirrorlist

[galaxy]
Include = /etc/pacman.d/mirrorlist

[universe]
Server = https://universe.artixlinux.org/$arch
Server = https://mirror1.artixlinux.org/universe/$arch
Server = https://mirror.pascalpuffke.de/artix-universe/$arch
Server = https://artixlinux.qontinuum.space/artixlinux/universe/os/$arch
Server = https://mirror1.cl.netactuate.com/artix/universe/$arch
Server = https://ftp.crifo.org/artix-universe/

[extra]
Include = /etc/pacman.d/mirrorlist-arch

[community]
Include = /etc/pacman.d/mirrorlist-arch

If it functions like that, working for a couple of hours and then breaks while I don't change anything on my system at all I insist that the problem is in the server which runs this debuginfod daemon. Maybe there are too strict firewall rules for frequent requests? Are there any IP blocks by geolocation?

If this problem continues to be that irritably unresolvable, could I maybe somehow download these debug packages which debuginfod fetches from debuginfod.artixlinux.org myself just to finally stop dealing with this shit

Re: [SOLVED] valgrind doesn't work

Reply #36 –
A couple of years ago or whatever before this debuginfod thing appeared, if you wanted to get a proper stack trace from strace or valgrind etc, all you needed to do was compile the packages which would get called in the trace (ie the package and the libs it used) with debugging symbols and not strip them. This is fairly easy and there are guides on the Arch wiki to help you. Mostly you can make a couple of changes to /etc/makepkg.conf and also in the PKGBUILD, and you can use makepkg then. It might take a bit of time to set up but once you have figured out the config it's very easy and should work even if offline, don't know how it will work with the current valgrind and it's dependency on the debuginfod package, but you can always build your own valgrind too. The PKGBUILD for valgrind-git in the AUR looks to have no dependency on debuginfod. TBH this whole setup seems more a convenience to help ordinary users get a meaningful stack trace for bug reports, because if you are really debugging issues you're often going to be swapping package versions and creating modified ones that wouldn't work with the database anyway. If you are using wireless you might be getting temporary connection problems from that too, incidentally.

Re: [SOLVED] valgrind doesn't work

Reply #37 –
valgrind is broken for me as well.
Trying debuginfod-find yields what I assume is a 404 error:
Quote
$ debuginfod-find debuginfo /usr/bin/ld.so
Server query failed: No such file or directory
but https://debuginfod.artixlinux.org/packages lists glibc-debug.
Is there some way to mirror these -debug packages? I think artix mirrors used to have them in $repo-debug, but that doesn't seem to be the case any more.

Edit: just as I say that, debuginfod decides to grace me with debuginfo:
Spoiler (click to show/hide)

Further requests are hit-and-miss. /usr/bin/ruby has no such file or directory, but /usr/bin/rsync returns results. Even trying to get ld.so again doesn't work:
Quote
$ curl -L https://debuginfod.artixlinux.org/buildid/c177c50fe3563f80e1e8ff4dcefc29a862783bd4/debuginfo --verbose
...
< HTTP/2 404
< server: nginx
< date: Sun, 08 Jan 2023 19:45:16 GMT
< content-type: text/plain; charset=utf-8
< content-length: 9
<
* Connection #0 to host debuginfod.artixlinux.org left intact
not found%
Is this some nginx proxy in front of mirrors, only one of which has the data?

Re: [SOLVED] valgrind doesn't work

Reply #38 –
Quote from: tenshi – on
valgrind is broken for me as well.
Trying debuginfod-find yields what I assume is a 404 error:but https://debuginfod.artixlinux.org/packages lists glibc-debug.
Is there some way to mirror these -debug packages? I think artix mirrors used to have them in $repo-debug, but that doesn't seem to be the case any more.

I don't want to be a negative nancy now, but I reckon you won't get any help here since the developers have this attitude like it's stupid users break their system and whine around because Artix great servers are so out of doubt! I was so disappointed that so much things are just broken on Artix that wrote this big piece of text just for myself (never posted it, its purpose was to keep me from trying to use Artix again); here it is, enjoy:

There are a couple of things one should consider before going with Artix:

1) having multiple different init systems just divides an already small
community of the project into much smaller groups;

2) package management is very sloppy (kernel modules are out of sync with the
kernel package, some programs are supplied only partly: there are some
extensions present from libreoffice while the libreoffice itself is simply
missing, mpd is in the repositories while mpc - its primary client - isn't,
packages sit in the testing repositories for a very long time despite the
commitment to the rolling release concept);

3) given their repositories have not a very rich set of packages they decide to
just drop support for repositories from Arch Linux by default and leave users to
packages with all the shortcomings mentioned in the previous paragraph (there
was no good reason for this as the packages from the Arch Linux repositories
were working fine except for stuff that is bound to systemd somehow);

4) infrastructure behind the package building is very awkward - they have this
Gitea instance which contains "organizations" which contain package projects
with names beginning with the same letter, like "packagesA", "packagesB" and so
on... this means that it is difficult to apply changes to multiple packages at
once, and in general, such a system is pretty easy to turn into a mess (compare
it to distributions with one big repo for all the package recipes, where it is
much more convenient to keep track of what is going on);

5) all the scripts for working with package repositories are written with the
idea of interacting and synchronization with Arch Linux repositories while they
officially bailed on packages from Arch Linux... also this shit requires Ruby...
apparently shell scripts for moving files around are not enough... damn...

6) valgrind and debuginfod setup just doesn't work despite everything on my end
is configured the same way as on Arch Linux... long forum thread of issues about
non-working valgrind didn't resonate with developers out there and of all
responses none was at least a little useful, all calling my setup into question,
although I said that exactly the same setup is on the machine next to me with
Arch Linux installed and valgrind does work with debuginfod nicely.

This is probably the most toxic thing I have written in my life - try to not get
offended here. So much good feedback around Artix Linux I observed for a long
time and the shit I get when I install it to my hardware just couldn't go
without leaving a putrid trace like that. This thing is not so great, I don't feel
sorry for writing this as it is quite necessary to balance out all these great reviews
about how Artix is fancy and cool...

This was written on 01.01.2023. I hope in your time everything got better :)

Re: [SOLVED] valgrind doesn't work

Reply #39 –
I was checking out if I could get the debug packages from a mirror to see if one could install the library debug package for glibc. I tested each server that exist in the Artix mirrorlist file.
Only the Hungary server appears to have the debug repositories currently so I created the custom mirrorlist file to prevent all the negative hits when updating.
Code: [Select]
# vim /etc/pacman.conf
[system-debug]
Include = /etc/pacman.d/mirrorlist-debug
[world-debug]
Include = /etc/pacman.d/mirrorlist-debug
[galaxy-debug]
Include = /etc/pacman.d/mirrorlist-debug

# vim /etc/pacman.d/mirrorlist-debug
# Hungary
Server = https://quantum-mirror.hu/mirrors/pub/artix-linux/$repo/os/$arch
Code: [Select]
# pacman -Syu glibc-debug
:: Synchronising package databases...
 jspaces is up to date
 system is up to date
 world is up to date
 galaxy is up to date
 lib32 is up to date
 universe is up to date
 moksha is up to date
 omniverse is up to date
 system-debug is up to date
 world-debug is up to date
 galaxy-debug is up to date
 extra is up to date
 community is up to date
 multilib is up to date
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (1) glibc-debug-2.36-6

Total Download Size:    28.71 MiB
Total Installed Size:  100.94 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages...
 glibc-debug-2.36-6-x86_64                       28.7 MiB  7.11 MiB/s 00:04 [##########################################] 100%
(1/1) checking keys in keyring                                              [##########################################] 100%
(1/1) checking package integrity                                            [##########################################] 100%
(1/1) loading package files                                                 [##########################################] 100%
(1/1) checking for file conflicts                                           [##########################################] 100%
(1/1) checking available disk space                                         [##########################################] 100%
:: Processing package changes...
(1/1) installing glibc-debug                                                [##########################################] 100%
:: Running post-transaction hooks...
(1/1) Refreshing PackageKit...
Code: [Select]
$ vim test.c
int main(void) {
	int a = 5 - 6;
	return 0;
}
Code: [Select]
$ gcc -g test.c -o test
$ valgrind test
==1357== Memcheck, a memory error detector
==1357== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1357== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1357== Command: test
==1357== 
==1357== 
==1357== HEAP SUMMARY:
==1357==     in use at exit: 0 bytes in 0 blocks
==1357==   total heap usage: 29 allocs, 29 frees, 4,240 bytes allocated
==1357== 
==1357== All heap blocks were freed -- no leaks are possible
==1357== 
==1357== For lists of detected and suppressed errors, rerun with: -s
==1357== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
It looks like the test file submitted actual was successfully completed. So it looks like the debug package was required since without it fails.
Why do all the other mirrors do not have the debug repositories?
Seems to me that the mirror sites themselves maybe the cause of the issue of not having those debug repositories on their mirrors. It is a fairly new feature so most likely the mirror sites may not have the debug repositories configured to be synchronized. Oh well, your guess is as good as mine.

Re: [SOLVED] valgrind doesn't work

Reply #40 –
It's more difficult to resolve a problem if it can't be easily replicated, and for the most part the mirrors aren't Artix controlled, but provided for free by various generous third party benefactors, in terms of who can access the network settings. There have also been other similar nebulous problems for certain users at certain times reaching Arch and AUR resources in the past incidentally. Don't mistake all forum participants or even devs for being anything other than enthusiastic Artix users! Remember if someone suggests something and it DOESN'T work that's good info for future ideas. You can't say people aren't trying to help you as it's now page 3 of this thread  :D
jspaces research looks promising, perhaps you are a long way from Hungary or don't have that entry enabled or near the top of your mirrorlist or something?
Incidentally the DNS server swap suggested a connection issue in the internet itself because you got a bit of an improvement there for a while, perhaps you got connected via another physical line or something, the fact Arch worked with both is irrelevant because connections should work, so it indicated it was neither your setup or the Artix mirror. Perhaps in time more mirrors might carry these packages, if they are indeed absent on some.

Edit: extra note re - "4) infrastructure behind the package building"
Each package is in it's own separate git repo. But if you clone one and do ls -laR you will find the hidden .artixlinux directory (as well as the hidden .git directory) and the agent.yaml file by which means the whole set can be manipulated, just not with git as you expected.

Re: [SOLVED] valgrind doesn't work

Reply #41 –
tldr: use https://debuginfod.elfutils.org/

I built and installed glibc-debug from artix gitea/glibc - the PKGBUILD already had debug enabled, it produces both glibc and glibc-debug packages (and glibc-locales)
Had to pass --nocheck to makepkg, otherwise it fails because of some "intl/gettext", this seems to be a glibc issue, I found it in some NEWS file among the sources.

Anyway, this didn't seem to do any good. There are now

/usr/lib/debug/usr/lib/ld-linux-x86-64.so.2.debug
/usr/lib/debug/usr/lib32/ld-linux.so.2.debug

with

/usr/lib/debug/usr/lib/ld-linux-x86-64.so.2.debug: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=6b02b2602b577dfe5a93ccd80f0632ea0c23a9a2, with debug_info, not stripped

but valgrind doesn't seem to magically find/use them.... maybe this can be configured somewhere somehow.

Perhaps one isn't supposed to install glibc-debug, just keep it somewhere and run a local instance of debuginfod over it, like documented here:

https://sourceware.org/elfutils/Debuginfod.html

I didn't try that out though, because using

https://debuginfod.elfutils.org/

just works. I ended up with

export DEBUGINFOD_URLS="https://debuginfod.artixlinux.org/ https://debuginfod.elfutils.org/"
 

Re: [SOLVED] valgrind doesn't work

Reply #42 –
Quote from: arveex – on
tldr: use https://debuginfod.elfutils.org/

I built and installed glibc-debug from artix gitea/glibc - the PKGBUILD already had debug enabled, it produces both glibc and glibc-debug packages (and glibc-locales)
Had to pass --nocheck to makepkg, otherwise it fails because of some "intl/gettext", this seems to be a glibc issue, I found it in some NEWS file among the sources.

Anyway, this didn't seem to do any good. There are now

/usr/lib/debug/usr/lib/ld-linux-x86-64.so.2.debug
/usr/lib/debug/usr/lib32/ld-linux.so.2.debug

with

/usr/lib/debug/usr/lib/ld-linux-x86-64.so.2.debug: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=6b02b2602b577dfe5a93ccd80f0632ea0c23a9a2, with debug_info, not stripped

but valgrind doesn't seem to magically find/use them.... maybe this can be configured somewhere somehow.

Perhaps one isn't supposed to install glibc-debug, just keep it somewhere and run a local instance of debuginfod over it, like documented here:

https://sourceware.org/elfutils/Debuginfod.html

I didn't try that out though, because using

https://debuginfod.elfutils.org/

just works. I ended up with

export DEBUGINFOD_URLS="https://debuginfod.artixlinux.org/ https://debuginfod.elfutils.org/"

So we know have to manually compile glibc-debug on each new release? Ugh, annoying.