==1342== Memcheck, a memory error detector ==1342== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1342== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==1342== Command: ./bin/yed ==1342==
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: strlen 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.
i've got debuginfod
Title: Re: valgrind doesn't work
Post by: ####### on 07 October 2022, 20:23:52
Reboot, there is some environment variable that is set at boot, it doesn't get set on installation.
Title: Re: valgrind doesn't work
Post by: MESYETI on 07 October 2022, 20:28:48
it works OK here, anyway, although that is not to say there might be a problem for others of course.
Title: Re: valgrind doesn't work
Post by: Dudemanguy on 07 October 2022, 21:53:31
It is supposed to "just work" now since we have a debuginfod. Maybe double check and make sure all of your packages are up to date and from Artix repos?
Title: Re: valgrind doesn't work
Post by: MESYETI on 07 October 2022, 22:21:22
It is supposed to "just work" now since we have a debuginfod. Maybe double check and make sure all of your packages are up to date and from Artix repos?
just updated and still same problem
edit: rebooted, no change
Title: Re: valgrind doesn't work
Post by: MESYETI on 07 October 2022, 22:23:58
==2277== Memcheck, a memory error detector ==2277== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==2277== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==2277== Command: ls ==2277==
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: strlen 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.
Title: Re: valgrind doesn't work
Post by: ####### on 20 October 2022, 15:23:24
There are some conf files for debuginfod, check if you have .pacnew versions?
The concept is this debuginfod package accesses the debug symbols which are in an online server rather than on your system. For this to work the glibc package on your machine must match the online version(s) so you must be fully updated and not doing anything weird with your package management or using unusual packages, like some special GLIBC from the AUR. I guess the web request could fail, possibly due to security restrictions you have enabled, or the versions don't match because you have an old glibc. Also you can always use the traditional method of building glibc and anything else you need with debug symbols enabled, it can be done fairly easily by altering some values in /etc/makepkg.conf and possibly the related PKGBUILD's, that's how I always used to use valgrind and gdb. If this is also a longstanding installation that has stopped working then perhaps try reinstalling it after removal, as it seems a fresh install is working for those who have tried, and MESYETI had an old existing install? Also re the shell environment version, possibly if you are not using BASH as your shell, this could potentially cause difficulties.
Title: Re: valgrind doesn't work
Post by: s33k0r on 27 November 2022, 21:53:15
i have the same issue with valgrind, and maybe the solution...
--2022-11-27 21:52:43-- http://debuginfod.artixlinux.org/ Resolving debuginfod.artixlinux.org (debuginfod.artixlinux.org)... 209.126.11.233 Connecting to debuginfod.artixlinux.org (debuginfod.artixlinux.org)|209.126.11.233|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: https://debuginfod.artixlinux.org/ [following] --2022-11-27 21:52:43-- https://debuginfod.artixlinux.org/ Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt' Connecting to debuginfod.artixlinux.org (debuginfod.artixlinux.org)|209.126.11.233|:443... connected. ERROR: The certificate of ‘debuginfod.artixlinux.org’ is not trusted. ERROR: The certificate of ‘debuginfod.artixlinux.org’ has expired. The certificate has expired
Title: Re: valgrind doesn't work
Post by: nous on 30 November 2022, 11:29:38
==8172== Memcheck, a memory error detector ==8172== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==8172== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==8172== Command: ./newsraft -l flog ==8172==
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: strlen 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.
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.
has to do something with the issue? It seems we have a stripped ld in repos:
~ $ valgrind --debuginfo-server=https://debuginfod.artixlinux.org ls
doesn't work either.
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 28 December 2022, 14:30:51
I think I've found what's the issue here! Debug package might be okay overall except for strlen symbol because when glibc is build with optimization it just yields out any strlen calls and we end up without symbols for it. This patch https://www.openembedded.org/pipermail/openembedded-core/2016-December/248444.html implies
build flag in glibc will fix the valgrind error. I hope anyone here can put this flag to glibc debug package? Thanks
Title: Re: [SOLVED] valgrind doesn't work
Post by: Dudemanguy on 29 December 2022, 06:24:42
The glibc-debug works just fine for me. However, I do get that error if I don't install glibc-debug. Is that supposed to happen? I'm pretty sure I've used valgrind in the past plenty of times without necessarily needing glibc debug symbols.
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 29 December 2022, 17:18:16
The glibc-debug works just fine for me. However, I do get that error if I don't install glibc-debug. Is that supposed to happen? I'm pretty sure I've used valgrind in the past plenty of times without necessarily needing glibc debug symbols.
I had it working for a couple of hours recently so I thought someone did put this -fno-builtin-strlen flag into glibc debug package and was about to go to the forum to thank whoever did it for very much prompt fix, but I just tested valgrind and it doesn't work again :(
Btw how do you get to install glibc-debug? I don't have this package in my repositories. I thought it is fetched from Artix's debuginfod server every time I launch valgrind...
Title: Re: [SOLVED] valgrind doesn't work
Post by: Dudemanguy on 29 December 2022, 21:43:34
Just enable the debug repos in your pacman.conf ($repo-debug). Basically the same as how it works in Arch.
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 29 December 2022, 22:27:06
That didn't do the trick, but valgrind seems to be working again. Looks like it requires some rest from time to time C:
Title: Re: [SOLVED] valgrind doesn't work
Post by: Dudemanguy on 29 December 2022, 22:51:29
Yeah that's what I meant. The mirrors that carry the debug packages might be different, and unfortunately I don't remember if it was noted down anywhere (I'm using a dev one not a public one).
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 30 December 2022, 08:38:52
Can I somehow also get to these repositories? What is in your pacman.conf and mirrorlist exactly? I'm asking because valgrind is broken again... I wonder why it does work in periods like that, damn
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 30 December 2022, 08:59:32
Yeah that's what I meant. The mirrors that carry the debug packages might be different, and unfortunately I don't remember if it was noted down anywhere (I'm using a dev one not a public one).
I've tried pinging debuginfod.artixlinux.org and found out that it redirects to one of several servers and I thought that some servers have bad debug package (without -fno-builtin-strlen flag) and because after I connect to a single server it caches these invalid symbols which I continue to use for some period of time and get error regardless of valgrind restart.
To try all possible servers debuginfod.artixlinux.org redirects me to I did this:
while sleep 1 do rm -rf ~/.cache/debuginfod_client rm -rf ~/.debuginfod.sqlite valgrind ls done
And after a couple of minutes I didn't get even one success :( Can you tell if there were attempts at adding -fno-builtin-strlen flag? Why sometimes it works and sometimes it doesn't? I just don't get it
Title: Re: [SOLVED] valgrind doesn't work
Post by: ####### on 30 December 2022, 14:08:56
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.
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 30 December 2022, 14:56:15
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.
I tried plenty of mirrors - all of them hold the same set of packages I have installed (except for a few which return 404 but they were on the bottom of my mirrorlist anyway). Are you saying you have working valgrind right now? Can you test simple C program?
I compile it with gcc -g and run valgrind ./a.out and it fails, I can't believe it's just my local thing since I installed Artix just a couple of days ago it couldn't deviate so much... Where I can report that I want -fno-builtin-strlen flag in the glibc debug package which is on debuginfod server?
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 30 December 2022, 15:02:03
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...
Title: Re: [SOLVED] valgrind doesn't work
Post by: h3xo on 30 December 2022, 16:01:03
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....
Title: Re: [SOLVED] valgrind doesn't work
Post by: ####### on 30 December 2022, 23:00:50
$ 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?
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 30 December 2022, 23:45:34
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 :)
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 31 December 2022, 12:01:09
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? ???
[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
Title: Re: [SOLVED] valgrind doesn't work
Post by: ####### on 31 December 2022, 14:49:24
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.
Title: Re: [SOLVED] valgrind doesn't work
Post by: tenshi on 08 January 2023, 20:17:07
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?
Title: Re: [SOLVED] valgrind doesn't work
Post by: jfffffffra4 on 08 January 2023, 20:38:04
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 :)
Title: Re: [SOLVED] valgrind doesn't work
Post by: jspaces on 08 January 2023, 22:29:51
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.
# 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
# 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...
$ 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.
Title: Re: [SOLVED] valgrind doesn't work
Post by: ####### on 09 January 2023, 03:26:20
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.
Title: Re: [SOLVED] valgrind doesn't work
Post by: arveex on 04 November 2023, 09:24:01
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
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