{"thread":{"id":"62472","subject":"[RFC]: Test Were failing on Fedora Linux.","startedAt":"2024-11-09T06:01:53Z","lastAt":"2024-11-20T23:26:53Z","messageCount":18,"participants":["Usman Akinyemi","Christian Couder","Andreas Schwab","Todd Zullinger","Jeff King","Junio C Hamano","Toon Claes"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"506888","messageId":"CAPSxiM9GZLKNbyCmgpz6b7Z-MLe8TfMaatR8FPNwvsHA411dtA@mail.gmail.com","threadId":"62472","inReplyTo":null,"subject":"[RFC]: Test Were failing on Fedora Linux.","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-11-09T06:01:41Z","receivedAt":"2024-11-09T06:01:53Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"Hello,\n\nI was trying to build the Git project on Fedora Linux. I just\ninstalled the Fedora.\n\nI followed through the steps in the Submitting a Patch. About 42 tests\nwere failing.\n\nI noticed that there are some directories created that did not get deleted.\n\n*'trash directory.t0000-basic'\n'trash directory.t0001-init'\n'trash directory.t0003-attributes'\n'trash directory.t0004-unwritable'\n'trash directory.t0008-ignores'\n'trash directory.t0012-help'\n'trash directory.t0017-env-helper'\n'trash directory.t0018-advice'\n'trash directory.t0020-crlf'\n'trash directory.t0021-conversion'\n'trash directory.t0027-auto-crlf'\n'trash directory.t0040-parse-options'\n'trash directory.t0041-usage'\n'trash directory.t0061-run-command'\n'trash directory.t0070-fundamental'\n'trash directory.t0090-cache-tree'\n'trash directory.t0202-gettext-perl'\n'trash directory.t0203-gettext-setlocale-sanity'\n'trash directory.t0210-trace2-normal'\n'trash directory.t0300-credentials'\n'trash directory.t0301-credential-cache'\n'trash directory.t0302-credential-store'\n'trash directory.t0303-credential-external*\n\nAny idea of what I am missing ?\n\nThank you.\nUsman.\n"},{"id":"506889","messageId":"CAP8UFD1-HsYsPRQwWMo8ipf-VdqF+9=HUTTr4BhEArR=V3ucxA@mail.gmail.com","threadId":"62472","inReplyTo":"CAPSxiM9GZLKNbyCmgpz6b7Z-MLe8TfMaatR8FPNwvsHA411dtA@mail.gmail.com","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-11-09T08:12:18Z","receivedAt":"2024-11-09T08:12:31Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sat, Nov 9, 2024 at 7:02 AM Usman Akinyemi\n wrote:\n>\n> Hello,\n>\n> I was trying to build the Git project on Fedora Linux. I just\n> installed the Fedora.\n>\n> I followed through the steps in the Submitting a Patch. About 42 tests\n> were failing.\n\nPlease tell us how exactly you ran the tests and what was the output\nthat showed some tests failed.\n\nYou can run each failing test with some options like -i and -v to get\nmore information, like for example:\n\n$ ./t0000-basic.sh -i -v\n\n> I noticed that there are some directories created that did not get deleted.\n>\n> *'trash directory.t0000-basic'\n> 'trash directory.t0001-init'\n> 'trash directory.t0003-attributes'\n> 'trash directory.t0004-unwritable'\n> 'trash directory.t0008-ignores'\n> 'trash directory.t0012-help'\n> 'trash directory.t0017-env-helper'\n> 'trash directory.t0018-advice'\n> 'trash directory.t0020-crlf'\n> 'trash directory.t0021-conversion'\n> 'trash directory.t0027-auto-crlf'\n> 'trash directory.t0040-parse-options'\n> 'trash directory.t0041-usage'\n> 'trash directory.t0061-run-command'\n> 'trash directory.t0070-fundamental'\n> 'trash directory.t0090-cache-tree'\n> 'trash directory.t0202-gettext-perl'\n> 'trash directory.t0203-gettext-setlocale-sanity'\n> 'trash directory.t0210-trace2-normal'\n> 'trash directory.t0300-credentials'\n> 'trash directory.t0301-credential-cache'\n> 'trash directory.t0302-credential-store'\n> 'trash directory.t0303-credential-external*\n>\n> Any idea of what I am missing ?\n\nWhen a test fails, the directory where the test was run is not deleted\nso that it can be inspected to see what went wrong in the test. So it\nis to be expected that these directories were not deleted if the\ncorresponding tests failed.\n\nBest,\nChristian.\n"},{"id":"506895","messageId":"CAPSxiM9UGLVrOh6XR5fn38ginCVKMOc7yQMcm+qsaF3bi+anSw@mail.gmail.com","threadId":"62472","inReplyTo":"CAP8UFD1-HsYsPRQwWMo8ipf-VdqF+9=HUTTr4BhEArR=V3ucxA@mail.gmail.com","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-11-09T09:32:54Z","receivedAt":"2024-11-09T09:33:06Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Sat, Nov 9, 2024 at 3:12 AM Christian Couder\n wrote:\n>\n> On Sat, Nov 9, 2024 at 7:02 AM Usman Akinyemi\n> wrote:\n> >\n> > Hello,\n> >\n> > I was trying to build the Git project on Fedora Linux. I just\n> > installed the Fedora.\n> >\n> > I followed through the steps in the Submitting a Patch. About 42 tests\n> > were failing.\n>\n> Please tell us how exactly you ran the tests and what was the output\n> that showed some tests failed.\n>\n> You can run each failing test with some options like -i and -v to get\n> more information, like for example:\n>\n> $ ./t0000-basic.sh -i -v\nHello Christian,\n\nI was using make before. I tried to run the single test as above, the error was\nERROR: ld.so: object 'libc_malloc_debug.so.0' from LD_PRELOAD cannot\nbe preloaded (cannot open shared object file): ignored\nI tried to check this online, but, all the solutions I found were not\nresolving it.\n\nI look for libc_malloc_debug.so.0 and it is located in /usr/lib\nuniqueusman@fedora:~/git/t$ sudo find / -name \"libc_malloc_debug.so.0\"\nfind: ‘/run/user/1000/gvfs’: Permission denied\nfind: ‘/run/user/1000/doc’: Permission denied\n/usr/lib/libc_malloc_debug.so.0\n\nThank you.\nUsman\n\n>\n> > I noticed that there are some directories created that did not get deleted.\n> >\n> > *'trash directory.t0000-basic'\n> > 'trash directory.t0001-init'\n> > 'trash directory.t0003-attributes'\n> > 'trash directory.t0004-unwritable'\n> > 'trash directory.t0008-ignores'\n> > 'trash directory.t0012-help'\n> > 'trash directory.t0017-env-helper'\n> > 'trash directory.t0018-advice'\n> > 'trash directory.t0020-crlf'\n> > 'trash directory.t0021-conversion'\n> > 'trash directory.t0027-auto-crlf'\n> > 'trash directory.t0040-parse-options'\n> > 'trash directory.t0041-usage'\n> > 'trash directory.t0061-run-command'\n> > 'trash directory.t0070-fundamental'\n> > 'trash directory.t0090-cache-tree'\n> > 'trash directory.t0202-gettext-perl'\n> > 'trash directory.t0203-gettext-setlocale-sanity'\n> > 'trash directory.t0210-trace2-normal'\n> > 'trash directory.t0300-credentials'\n> > 'trash directory.t0301-credential-cache'\n> > 'trash directory.t0302-credential-store'\n> > 'trash directory.t0303-credential-external*\n> >\n> > Any idea of what I am missing ?\n>\n> When a test fails, the directory where the test was run is not deleted\n> so that it can be inspected to see what went wrong in the test. So it\n> is to be expected that these directories were not deleted if the\n> corresponding tests failed.\nOhh, thanks for this.\n>\n> Best,\n> Christian.\n"},{"id":"506904","messageId":"CAP8UFD2=imvtamewLN+VvKDK83aL7NhGAb=MjvHQ2OwaK-n5UQ@mail.gmail.com","threadId":"62472","inReplyTo":"CAPSxiM9UGLVrOh6XR5fn38ginCVKMOc7yQMcm+qsaF3bi+anSw@mail.gmail.com","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2024-11-09T14:01:41Z","receivedAt":"2024-11-09T14:01:55Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi Usman,\n\nOn Sat, Nov 9, 2024 at 10:33 AM Usman Akinyemi\n wrote:\n>\n> On Sat, Nov 9, 2024 at 3:12 AM Christian Couder\n> wrote:\n\n> > You can run each failing test with some options like -i and -v to get\n> > more information, like for example:\n> >\n> > $ ./t0000-basic.sh -i -v\n>\n> I was using make before. I tried to run the single test as above, the error was\n> ERROR: ld.so: object 'libc_malloc_debug.so.0' from LD_PRELOAD cannot\n> be preloaded (cannot open shared object file): ignored\n> I tried to check this online, but, all the solutions I found were not\n> resolving it.\n\nFirst, as a workaround, maybe you can try:\n\n$ TEST_NO_MALLOC_CHECK=1 ./t0000-basic.sh -i -v\n\nto see if things work when disabling malloc checks.\n\nAnyway the issue might be related to how your shared libraries are\ninstalled, so using ldconfig might help:\n\n$ sudo ldconfig\n\nAlternatively you can try replacing the following line in t/test-lib.sh:\n\n LD_PRELOAD=\"libc_malloc_debug.so.0\"\n\nwith:\n\n LD_PRELOAD=\"/usr/lib/libc_malloc_debug.so.0\"\n\nThis is a hack but it might help understand what's going on if it works.\n\n> I look for libc_malloc_debug.so.0 and it is located in /usr/lib\n> uniqueusman@fedora:~/git/t$ sudo find / -name \"libc_malloc_debug.so.0\"\n> find: ‘/run/user/1000/gvfs’: Permission denied\n> find: ‘/run/user/1000/doc’: Permission denied\n> /usr/lib/libc_malloc_debug.so.0\n\nYeah, not sure why it doesn't work while you have it.\n\nBest,\nChristian.\n"},{"id":"506906","messageId":"87msi85vc9.fsf@igel.home","threadId":"62472","inReplyTo":"CAP8UFD2=imvtamewLN+VvKDK83aL7NhGAb=MjvHQ2OwaK-n5UQ@mail.gmail.com","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2024-11-09T14:35:02Z","receivedAt":"2024-11-09T14:43:15Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Nov 09 2024, Christian Couder wrote:\n\n> Yeah, not sure why it doesn't work while you have it.\n\nIt's probably of the wrong architecture.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"},{"id":"506907","messageId":"CAPSxiM9AwwmoPcoGs57A8HtwZVMOH5Kzgsa4ju7DqhFjMAeKSQ@mail.gmail.com","threadId":"62472","inReplyTo":"CAP8UFD2=imvtamewLN+VvKDK83aL7NhGAb=MjvHQ2OwaK-n5UQ@mail.gmail.com","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-11-09T14:59:09Z","receivedAt":"2024-11-09T14:59:21Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Sat, Nov 9, 2024 at 9:01 AM Christian Couder\n wrote:\n>\n> Hi Usman,\n>\n> On Sat, Nov 9, 2024 at 10:33 AM Usman Akinyemi\n> wrote:\n> >\n> > On Sat, Nov 9, 2024 at 3:12 AM Christian Couder\n> > wrote:\n>\n> > > You can run each failing test with some options like -i and -v to get\n> > > more information, like for example:\n> > >\n> > > $ ./t0000-basic.sh -i -v\n> >\n> > I was using make before. I tried to run the single test as above, the error was\n> > ERROR: ld.so: object 'libc_malloc_debug.so.0' from LD_PRELOAD cannot\n> > be preloaded (cannot open shared object file): ignored\n> > I tried to check this online, but, all the solutions I found were not\n> > resolving it.\n>\n> First, as a workaround, maybe you can try:\n>\n> $ TEST_NO_MALLOC_CHECK=1 ./t0000-basic.sh -i -v\n>\n> to see if things work when disabling malloc checks.\n>\n> Anyway the issue might be related to how your shared libraries are\n> installed, so using ldconfig might help:\n>\n> $ sudo ldconfig\n>\n> Alternatively you can try replacing the following line in t/test-lib.sh:\n>\n> LD_PRELOAD=\"libc_malloc_debug.so.0\"\n>\n> with:\n>\n> LD_PRELOAD=\"/usr/lib/libc_malloc_debug.so.0\"\n>\n> This is a hack but it might help understand what's going on if it works.\nHi Christian.\n\nThanks for this, the problem was due to the architecture, the one\n/usr/lib/libc_malloc_debug.so.0 was 32bit,\nI had to download the 64bit by downloading glibc-utils.x86_64. I did\nnot face this when I was using Arch Linux.\n\nThank you.\nUsman.\n>\n> > I look for libc_malloc_debug.so.0 and it is located in /usr/lib\n> > uniqueusman@fedora:~/git/t$ sudo find / -name \"libc_malloc_debug.so.0\"\n> > find: ‘/run/user/1000/gvfs’: Permission denied\n> > find: ‘/run/user/1000/doc’: Permission denied\n> > /usr/lib/libc_malloc_debug.so.0\n>\n> Yeah, not sure why it doesn't work while you have it.\n>\n> Best,\n> Christian.\n"},{"id":"506908","messageId":"CAPSxiM_h2yEZcUPP33q8HHdn6kqq7SbvzNq8eEFda81ZgY6R2w@mail.gmail.com","threadId":"62472","inReplyTo":"87msi85vc9.fsf@igel.home","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-11-09T15:02:08Z","receivedAt":"2024-11-09T15:02:19Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Sat, Nov 9, 2024 at 9:35 AM Andreas Schwab wrote:\n>\n> On Nov 09 2024, Christian Couder wrote:\n>\n> > Yeah, not sure why it doesn't work while you have it.\n>\n> It's probably of the wrong architecture.\nHi Andreas,\nThanks for responding.\nIt was actually the wrong Architecture. Thank you. Just curious, any\nreason why the 32bit was present instead of the\n64bit ?, I will normally think the operating system should ship 64bit\nby default.\n\nUsman Akinyemi.\n>\n> --\n> Andreas Schwab, schwab@linux-m68k.org\n> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1\n> \"And now for something completely different.\"\n"},{"id":"506910","messageId":"Zy-IYwjb_RO5NW-s@teonanacatl.net","threadId":"62472","inReplyTo":"CAPSxiM_h2yEZcUPP33q8HHdn6kqq7SbvzNq8eEFda81ZgY6R2w@mail.gmail.com","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Todd Zullinger","fromEmail":"tmz@pobox.com","sentAt":"2024-11-09T16:05:55Z","receivedAt":"2024-11-09T16:05:58Z","isPatch":false,"sender":{"key":"tmz@pobox.com","avatar":"https://avatars.githubusercontent.com/u/806319?v=4"},"body":"Usman Akinyemi wrote:\n> On Sat, Nov 9, 2024 at 9:35 AM Andreas Schwab wrote:\n>>\n>> On Nov 09 2024, Christian Couder wrote:\n>>\n>>> Yeah, not sure why it doesn't work while you have it.\n>>\n>> It's probably of the wrong architecture.\n> Hi Andreas,\n> Thanks for responding.\n> It was actually the wrong Architecture. Thank you. Just curious, any\n> reason why the 32bit was present instead of the\n> 64bit ?, I will normally think the operating system should ship 64bit\n> by default.\n\nThe 64-bit libc_malloc_debug.so.0 is in /lib64 and was moved\nto the glibc-utils package in Fedora 40, with 2c1b0f0 (Move\nmemory tracing libraries to glibc-utils, 2024-05-15)¹. The\ncommit message notes:\n\n On x86_64, glibc-utils will now only contain the 64-bit\n version of these libraries but still need the 32-bit\n version (in order to support tracing i686 applications).\n Therefore, on i686 the libraries remain in the main\n glibc package.\n\nIf you're interested in installing the various dependencies\nneeded to run the test suite on Fedora, take a look at the\nFedora git package spec file².\n\nThe BuildRequires contain a substantial set of dependencies\nwhich enable as many of the tests as practical to run when\nbuilding the packages (I believe more tests are run there\nthan are run in the git project's CI for most runs,\nactually :).\n\nSee also the %check section of the test suite for some tests\nwhich are skipped and other comments which might be useful.\n\n¹ https://src.fedoraproject.org/rpms/glibc/c/2c1b0f0\n² https://src.fedoraproject.org/rpms/git/blob/rawhide/f/git.spec\n\n-- \nTodd\n"},{"id":"506913","messageId":"20241109190012.GA588841@coredump.intra.peff.net","threadId":"62472","inReplyTo":"Zy-IYwjb_RO5NW-s@teonanacatl.net","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-11-09T19:00:12Z","receivedAt":"2024-11-09T19:00:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 09, 2024 at 11:05:55AM -0500, Todd Zullinger wrote:\n\n> The 64-bit libc_malloc_debug.so.0 is in /lib64 and was moved\n> to the glibc-utils package in Fedora 40, with 2c1b0f0 (Move\n> memory tracing libraries to glibc-utils, 2024-05-15)¹. The\n> commit message notes:\n> \n> On x86_64, glibc-utils will now only contain the 64-bit\n> version of these libraries but still need the 32-bit\n> version (in order to support tracing i686 applications).\n> Therefore, on i686 the libraries remain in the main\n> glibc package.\n> \n> If you're interested in installing the various dependencies\n> needed to run the test suite on Fedora, take a look at the\n> Fedora git package spec file².\n\nHmm. I wonder if our test scripts could be a little more forgiving here.\n\nThe glibc malloc debugging stuff has always been turned on by default\nsince a731fa916e (Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the\ntest suite for detecting heap corruption, 2012-09-14). Back then the\nsetup just involved setting some environment variables. If we were on a\nsystem where it didn't exist, it was no big deal. We'd just run without\nit.\n\nThat changed in 131b94a10a (test-lib.sh: Use GLIBC_TUNABLES instead of\nMALLOC_CHECK_ on glibc >= 2.34, 2022-03-04). Now that glibc split this\nout into libc_malloc_debug.so, we have to add it to LD_PRELOAD. We only\ndo that when we detect glibc, but it sounds like it's possible to have\nglibc but not the malloc debug library. In which case we'll produce\nerrors (at the very least it seems like ld.so will complain to stderr,\nwhich perhaps is the source of the test failures here).\n\nCan we do a better job of detecting that the library is available?\n\nI don't offhand know of a good portable way to ask the system about\navailable libraries. But I guess just doing something like:\n\n err=$(LD_PRELOAD=libc_malloc.so.0 git version 2>&1 >/dev/null)\n if test -z \"$err\"\n then\n\t...seemed to work...\n fi\n\nwould do it? I dunno. Maybe this is not a common enough thing to worry\nabout. It just seems bad for us to make life harder for people running\nthe tests for an optional thing.\n\n Side note: The glibc malloc stuff seems a bit more redundant these\n days, since we run with ASan in CI (which I'd expect to catch a\n superset of what the malloc debugging would). There is some value in\n catching things sooner, though (I don't usually do an ASan run on my\n workstation, and of course some people may not use CI at all).\n\n-Peff\n"},{"id":"506914","messageId":"CAPSxiM9=4be8X=Tjz1BJ_uO-bobi4LR=aR=zcq3XgbL0J6ZMvg@mail.gmail.com","threadId":"62472","inReplyTo":"Zy-IYwjb_RO5NW-s@teonanacatl.net","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-11-09T19:09:40Z","receivedAt":"2024-11-09T19:09:52Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Sat, Nov 9, 2024 at 11:05 AM Todd Zullinger wrote:\n>\n> Usman Akinyemi wrote:\n> > On Sat, Nov 9, 2024 at 9:35 AM Andreas Schwab wrote:\n> >>\n> >> On Nov 09 2024, Christian Couder wrote:\n> >>\n> >>> Yeah, not sure why it doesn't work while you have it.\n> >>\n> >> It's probably of the wrong architecture.\n> > Hi Andreas,\n> > Thanks for responding.\n> > It was actually the wrong Architecture. Thank you. Just curious, any\n> > reason why the 32bit was present instead of the\n> > 64bit ?, I will normally think the operating system should ship 64bit\n> > by default.\n>\n> The 64-bit libc_malloc_debug.so.0 is in /lib64 and was moved\n> to the glibc-utils package in Fedora 40, with 2c1b0f0 (Move\n> memory tracing libraries to glibc-utils, 2024-05-15)¹. The\n> commit message notes:\n>\n> On x86_64, glibc-utils will now only contain the 64-bit\n> version of these libraries but still need the 32-bit\n> version (in order to support tracing i686 applications).\n> Therefore, on i686 the libraries remain in the main\n> glibc package.\n>\n> If you're interested in installing the various dependencies\n> needed to run the test suite on Fedora, take a look at the\n> Fedora git package spec file².\n>\n> The BuildRequires contain a substantial set of dependencies\n> which enable as many of the tests as practical to run when\n> building the packages (I believe more tests are run there\n> than are run in the git project's CI for most runs,\n> actually :).\n>\nHi Todd,\n\nThanks for the explanation,\n\nI really appreciate it.\n\nUsman.\n> See also the %check section of the test suite for some tests\n> which are skipped and other comments which might be useful.\n>\n> ¹ https://src.fedoraproject.org/rpms/glibc/c/2c1b0f0\n> ² https://src.fedoraproject.org/rpms/git/blob/rawhide/f/git.spec\n>\n> --\n> Todd\n"},{"id":"506915","messageId":"CAPSxiM-9KboQharGmRVZQNs=Wor4-Zw_06ixb-Rs1NGJzEt1yQ@mail.gmail.com","threadId":"62472","inReplyTo":"20241109190012.GA588841@coredump.intra.peff.net","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Usman Akinyemi","fromEmail":"usmanakinyemi202@gmail.com","sentAt":"2024-11-09T19:12:04Z","receivedAt":"2024-11-09T19:12:16Z","isPatch":false,"sender":{"key":"usmanakinyemi202@gmail.com","avatar":"https://avatars.githubusercontent.com/u/86585626?v=4"},"body":"On Sat, Nov 9, 2024 at 2:00 PM Jeff King wrote:\n>\n> On Sat, Nov 09, 2024 at 11:05:55AM -0500, Todd Zullinger wrote:\n>\n> > The 64-bit libc_malloc_debug.so.0 is in /lib64 and was moved\n> > to the glibc-utils package in Fedora 40, with 2c1b0f0 (Move\n> > memory tracing libraries to glibc-utils, 2024-05-15)¹. The\n> > commit message notes:\n> >\n> > On x86_64, glibc-utils will now only contain the 64-bit\n> > version of these libraries but still need the 32-bit\n> > version (in order to support tracing i686 applications).\n> > Therefore, on i686 the libraries remain in the main\n> > glibc package.\n> >\n> > If you're interested in installing the various dependencies\n> > needed to run the test suite on Fedora, take a look at the\n> > Fedora git package spec file².\n>\n> Hmm. I wonder if our test scripts could be a little more forgiving here.\n>\n> The glibc malloc debugging stuff has always been turned on by default\n> since a731fa916e (Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the\n> test suite for detecting heap corruption, 2012-09-14). Back then the\n> setup just involved setting some environment variables. If we were on a\n> system where it didn't exist, it was no big deal. We'd just run without\n> it.\n>\n> That changed in 131b94a10a (test-lib.sh: Use GLIBC_TUNABLES instead of\n> MALLOC_CHECK_ on glibc >= 2.34, 2022-03-04). Now that glibc split this\n> out into libc_malloc_debug.so, we have to add it to LD_PRELOAD. We only\n> do that when we detect glibc, but it sounds like it's possible to have\n> glibc but not the malloc debug library. In which case we'll produce\n> errors (at the very least it seems like ld.so will complain to stderr,\n> which perhaps is the source of the test failures here).\n>\n> Can we do a better job of detecting that the library is available?\n>\n> I don't offhand know of a good portable way to ask the system about\n> available libraries. But I guess just doing something like:\n>\n> err=$(LD_PRELOAD=libc_malloc.so.0 git version 2>&1 >/dev/null)\n> if test -z \"$err\"\n> then\n> ...seemed to work...\n> fi\n>\n> would do it? I dunno. Maybe this is not a common enough thing to worry\n> about. It just seems bad for us to make life harder for people running\n> the tests for an optional thing.\n>\n> Side note: The glibc malloc stuff seems a bit more redundant these\n> days, since we run with ASan in CI (which I'd expect to catch a\n> superset of what the malloc debugging would). There is some value in\n> catching things sooner, though (I don't usually do an ASan run on my\n> workstation, and of course some people may not use CI at all).\n>\nHi Peff,\n\nThis is definitely a good suggestion. I think at atleast we should\nhave this stated in INSTALL instructions.\n\nWhat do you think ?\n\nUsman\n\n> -Peff\n"},{"id":"506960","messageId":"xmqq7c9aihvx.fsf@gitster.g","threadId":"62472","inReplyTo":"20241109190012.GA588841@coredump.intra.peff.net","subject":"Re: [RFC]: Test Were failing on Fedora Linux.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-11-11T03:11:46Z","receivedAt":"2024-11-11T03:11:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I don't offhand know of a good portable way to ask the system about\n> available libraries. But I guess just doing something like:\n>\n> err=$(LD_PRELOAD=libc_malloc.so.0 git version 2>&1 >/dev/null)\n> if test -z \"$err\"\n> then\n> \t...seemed to work...\n> fi\n>\n> would do it?\n\nI do not necessarily view it as \"asking the system about available\nlibraries\"; we are checking if we can sensibly run things with this\nset to LD_PRELOAD. And presumably the answer was \"no\" in the\noriginal report, so it is a very direct way to ensure that we are\nsetting it to a sensible value. I like it.\n\nThe above did not work for me until I did \"s/malloc/&_debug/\" on the\ncommand line. At this point in the start-up sequence in the test\nframework, we should be able to run \"git\" from the PATH just fine,\nso it would be a good way to check if we can trigger the malloc\ncheck with the way how we expect to be able to trigger it.\n\nThanks.\n"},{"id":"506965","messageId":"20241111070134.GA675125@coredump.intra.peff.net","threadId":"62472","inReplyTo":"xmqq7c9aihvx.fsf@gitster.g","subject":"[PATCH] test-lib: check malloc debug LD_PRELOAD before using","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-11-11T07:01:34Z","receivedAt":"2024-11-11T07:01:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 11, 2024 at 12:11:46PM +0900, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > I don't offhand know of a good portable way to ask the system about\n> > available libraries. But I guess just doing something like:\n> >\n> > err=$(LD_PRELOAD=libc_malloc.so.0 git version 2>&1 >/dev/null)\n> > if test -z \"$err\"\n> > then\n> > \t...seemed to work...\n> > fi\n> >\n> > would do it?\n> \n> I do not necessarily view it as \"asking the system about available\n> libraries\"; we are checking if we can sensibly run things with this\n> set to LD_PRELOAD. And presumably the answer was \"no\" in the\n> original report, so it is a very direct way to ensure that we are\n> setting it to a sensible value. I like it.\n\nYeah, I agree that is a better way to think about it; it is more\ndirectly asking what we want to know. So here it is as an actual patch.\n\n> The above did not work for me until I did \"s/malloc/&_debug/\" on the\n> command line.\n\nOops, yes. I should have said \"not tested\". ;) On the other hand,\nwriting the wrong name is an easy way to test the failure mode. I pulled\nit out into a variable in the patch below so we only have to write it\nonce.\n\nI tested before and after with a typo'd version of the library name and\nit seems to work. But it would be great to get confirmation from Usman\nthat this fixes the problem.\n\n-- >8 --\nSubject: [PATCH] test-lib: check malloc debug LD_PRELOAD before using\n\nThis fixes test failures across the suite on glibc platforms that don't\nhave libc_malloc_debug.so.0.\n\nWe added support for glibc's malloc checking routines long ago in\na731fa916e (Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test\nsuite for detecting heap corruption, 2012-09-14). Back then we didn't\nneed to do any checks to see if the platform supported it. We were just\nsetting some environment variables which would either enable it or not.\n\nThat changed in 131b94a10a (test-lib.sh: Use GLIBC_TUNABLES instead of\nMALLOC_CHECK_ on glibc >= 2.34, 2022-03-04). Now that glibc split this\nout into libc_malloc_debug.so, we have to add it to LD_PRELOAD. We only\ndo that when we detect glibc, but it's possible to have glibc but not\nthe malloc debug library. In that case LD_PRELOAD will complain to\nstderr, and tests which check for an empty stderr will fail.\n\nYou can work around this by setting TEST_NO_MALLOC_CHECK, which disables\nthe feature entirely. But it's not obvious to know you need to do that.\nInstead, since this malloc checking is best-effort anyway, let's just\nautomatically disable it when the LD_PRELOAD appears not to work. We can\ncheck it by running something simple that should work (and produce\nnothing on stderr) like \"git version\".\n\nSigned-off-by: Jeff King \n---\n t/test-lib.sh | 7 +++++--\n 1 file changed, 5 insertions(+), 2 deletions(-)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex a278181a05..4fe757fe9a 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -593,9 +593,12 @@ then\n \t}\n else\n \t_USE_GLIBC_TUNABLES=\n+\t_USE_GLIBC_PRELOAD=libc_malloc_debug.so.0\n \tif _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&\n \t _GLIBC_VERSION=${_GLIBC_VERSION#\"glibc \"} &&\n-\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null\n+\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null &&\n+\t stderr=$(LD_PRELOAD=$_USE_GLIBC_PRELOAD git version 2>&1 >/dev/null) &&\n+\t test -z \"$stderr\"\n \tthen\n \t\t_USE_GLIBC_TUNABLES=YesPlease\n \tfi\n@@ -607,7 +610,7 @@ else\n \t\tif test -n \"$_USE_GLIBC_TUNABLES\"\n \t\tthen\n \t\t\tg=\n-\t\t\tLD_PRELOAD=\"libc_malloc_debug.so.0\"\n+\t\t\tLD_PRELOAD=$_USE_GLIBC_PRELOAD\n \t\t\tfor t in \\\n \t\t\t\tglibc.malloc.check=1 \\\n \t\t\t\tglibc.malloc.perturb=165\n-- \n2.47.0.495.g1253739cc1\n\n"},{"id":"507202","messageId":"87zfm3iggu.fsf@iotcl.com","threadId":"62472","inReplyTo":"20241111070134.GA675125@coredump.intra.peff.net","subject":"Re: [PATCH] test-lib: check malloc debug LD_PRELOAD before using","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2024-11-13T10:19:13Z","receivedAt":"2024-11-13T10:19:30Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Jeff King writes:\n\n> Subject: [PATCH] test-lib: check malloc debug LD_PRELOAD before using\n>\n> This fixes test failures across the suite on glibc platforms that don't\n> have libc_malloc_debug.so.0.\n\nAs I ran into this issue not so long as well, I'm really supportive of\nadding a fix for this.\n\n> We added support for glibc's malloc checking routines long ago in\n> a731fa916e (Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the test\n> suite for detecting heap corruption, 2012-09-14). Back then we didn't\n> need to do any checks to see if the platform supported it. We were just\n> setting some environment variables which would either enable it or not.\n>\n> That changed in 131b94a10a (test-lib.sh: Use GLIBC_TUNABLES instead of\n> MALLOC_CHECK_ on glibc >= 2.34, 2022-03-04). Now that glibc split this\n> out into libc_malloc_debug.so, we have to add it to LD_PRELOAD. We only\n> do that when we detect glibc, but it's possible to have glibc but not\n> the malloc debug library. In that case LD_PRELOAD will complain to\n> stderr, and tests which check for an empty stderr will fail.\n>\n> You can work around this by setting TEST_NO_MALLOC_CHECK, which disables\n> the feature entirely. But it's not obvious to know you need to do that.\n> Instead, since this malloc checking is best-effort anyway, let's just\n> automatically disable it when the LD_PRELOAD appears not to work. We can\n> check it by running something simple that should work (and produce\n> nothing on stderr) like \"git version\".\n>\n> Signed-off-by: Jeff King \n> ---\n> t/test-lib.sh | 7 +++++--\n> 1 file changed, 5 insertions(+), 2 deletions(-)\n>\n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index a278181a05..4fe757fe9a 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -593,9 +593,12 @@ then\n> \t}\n> else\n> \t_USE_GLIBC_TUNABLES=\n> +\t_USE_GLIBC_PRELOAD=\n> \tif _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&\n> \t _GLIBC_VERSION=${_GLIBC_VERSION#\"glibc \"} &&\n> -\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null\n> +\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null &&\n> +\t stderr=$(LD_PRELOAD=$_USE_GLIBC_PRELOAD git version 2>&1 >/dev/null) &&\n\nCan we assume some version of git is in the $PATH here? I see $PATH and\n$GIT_EXEC_PATH are only determined at line 1440 and further.\n\n> +\t test -z \"$stderr\"\n> \tthen\n> \t\t_USE_GLIBC_TUNABLES=YesPlease\n\nShall we include a warning in a else clause to inform the user the tests\nwere started with malloc check, but libc_malloc_debug.so.0 was not found\nand they should either install it or run with TEST_NO_MALLOC_CHECK?\n\n> \tfi\n> @@ -607,7 +610,7 @@ else\n> \t\tif test -n \"$_USE_GLIBC_TUNABLES\"\n> \t\tthen\n> \t\t\tg=\n> -\t\t\tLD_PRELOAD=\"libc_malloc_debug.so.0\"\n> +\t\t\tLD_PRELOAD=$_USE_GLIBC_PRELOAD\n> \t\t\tfor t in \\\n> \t\t\t\tglibc.malloc.check=1 \\\n> \t\t\t\tglibc.malloc.perturb=165\n> -- \n> 2.47.0.495.g1253739cc1\n\nI've tested this patch with and without having glibc-utils installed, in\ncombination of having TEST_NO_MALLOC_CHECK set/unset and seems to work\nlike a charm.\n\n\n--\nToon\n"},{"id":"507246","messageId":"20241114012729.GA1148710@coredump.intra.peff.net","threadId":"62472","inReplyTo":"87zfm3iggu.fsf@iotcl.com","subject":"Re: [PATCH] test-lib: check malloc debug LD_PRELOAD before using","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-11-14T01:27:29Z","receivedAt":"2024-11-14T01:27:31Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 13, 2024 at 11:19:13AM +0100, Toon Claes wrote:\n\n> > diff --git a/t/test-lib.sh b/t/test-lib.sh\n> > index a278181a05..4fe757fe9a 100644\n> > --- a/t/test-lib.sh\n> > +++ b/t/test-lib.sh\n> > @@ -593,9 +593,12 @@ then\n> > \t}\n> > else\n> > \t_USE_GLIBC_TUNABLES=\n> > +\t_USE_GLIBC_PRELOAD=\n> > \tif _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&\n> > \t _GLIBC_VERSION=${_GLIBC_VERSION#\"glibc \"} &&\n> > -\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null\n> > +\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null &&\n> > +\t stderr=$(LD_PRELOAD=$_USE_GLIBC_PRELOAD git version 2>&1 >/dev/null) &&\n> \n> Can we assume some version of git is in the $PATH here? I see $PATH and\n> $GIT_EXEC_PATH are only determined at line 1440 and further.\n\nHmm, good question. This is after the \"you do not seem to have built\ngit\" check, so I thought we were OK. But of course that one is using:\n\n \"${GIT_TEST_INSTALLED:-$GIT_BUILD_DIR}/git$X\"\n\nSo the check is probably running some system \"git\" and not the built\none. That mostly works out anyway since the real variable there is the\nLD_PRELOAD, not the specific version of git. And that's why testing it\nworked for me. But on a system without an existing git in the $PATH at\nall, it would disable the preload, even though it would work fine.\n\nSo some possible fixes are:\n\n - use a more complete path, as the earlier check does\n\n - delay the malloc-debug checking until after we've set up the $PATH\n\n - use a different program. We care about the preload working, so:\n\n LD_PRELOAD=$_USE_GLIBC_PRELOAD ls\n\n would mostly work the same. Though I suppose if you want to get\n really crazy, it's possible that \"ls\" might not be linked in the\n same way as our built git (e.g., it could be statically linked\n against a different libc).\n\nSo I guess just moving it is probably the least-bad option.\n\n> > +\t test -z \"$stderr\"\n> > \tthen\n> > \t\t_USE_GLIBC_TUNABLES=YesPlease\n> \n> Shall we include a warning in a else clause to inform the user the tests\n> were started with malloc check, but libc_malloc_debug.so.0 was not found\n> and they should either install it or run with TEST_NO_MALLOC_CHECK?\n\nI'm not sure. It is optional, and many systems will happily run without\nit. Just identifying glibc ones that happen not to have the debug\nlibrary installed seems weird when, say, Windows or FreeBSD similarly\nrun without it. And we'd be forcing the user to set TEST_NO_MALLOC_CHECK\nunless they want to be spammed with the warning from every single test\nscript that is run.\n\nAt that point we should almost just revert my patch and let it fail when\nthe preload doesn't work (the only advantage is that we could produce a\nmore useful message).\n\n-Peff\n"},{"id":"507247","messageId":"20241114013912.GA1155455@coredump.intra.peff.net","threadId":"62472","inReplyTo":"20241114012729.GA1148710@coredump.intra.peff.net","subject":"[PATCH 2/1] test-lib: move malloc-debug setup after $PATH setup","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-11-14T01:39:12Z","receivedAt":"2024-11-14T01:39:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Originally, the conditional definition of the setup/teardown functions\nfor malloc checking could be run at any time, because they depended only\non command-line options and the system getconf function.\n\nBut since 02d900361c (test-lib: check malloc debug LD_PRELOAD before\nusing, 2024-11-11), we probe the system by running \"git version\". Since\nthis code runs before we've set $PATH to point to the version of Git we\nintend to test, we actually run the system version of git.\n\nThis mostly works, since what we really care about is whether the\nLD_PRELOAD works, and it should work the same with any program. But\nthere are some corner cases:\n\n 1. You might not have a system git at all, in which case the preload\n will appear to fail, even though it could work with the actual\n built version of git.\n\n 2. Your system git could be linked in a different way. For example, if\n it was built statically, then it will ignore LD_PRELOAD entirely,\n and we might assume that the preload works, even though it might\n not when used with a dynamic build.\n\nWe could give a more complete path to the version of Git we intend to\ntest, but features like GIT_TEST_INSTALLED make that not entirely\ntrivial. So instead, let's just bump the setup until after we've set up\nthe $PATH. There's no need for us to do it early, as long as it is done\nbefore the first test runs.\n\nReported-by: Toon Claes \nSigned-off-by: Jeff King \n---\nTested by removing \"git\" from my $PATH and checking whether it was used.\nI didn't do a full test with the static version, but I confirmed that:\n\n gcc -static foo.c\n LD_PRELOAD=bogus.so ./a.out\n\ndoes not complain.\n\n t/test-lib.sh | 100 +++++++++++++++++++++++++-------------------------\n 1 file changed, 50 insertions(+), 50 deletions(-)\n\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 4fe757fe9a..6c60e8adae 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -577,56 +577,6 @@ case $GIT_TEST_FSYNC in\n \t;;\n esac\n \n-# Add libc MALLOC and MALLOC_PERTURB test only if we are not executing\n-# the test with valgrind and have not compiled with conflict SANITIZE\n-# options.\n-if test -n \"$valgrind\" ||\n- test -n \"$SANITIZE_ADDRESS\" ||\n- test -n \"$SANITIZE_LEAK\" ||\n- test -n \"$TEST_NO_MALLOC_CHECK\"\n-then\n-\tsetup_malloc_check () {\n-\t\t: nothing\n-\t}\n-\tteardown_malloc_check () {\n-\t\t: nothing\n-\t}\n-else\n-\t_USE_GLIBC_TUNABLES=\n-\t_USE_GLIBC_PRELOAD=libc_malloc_debug.so.0\n-\tif _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&\n-\t _GLIBC_VERSION=${_GLIBC_VERSION#\"glibc \"} &&\n-\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null &&\n-\t stderr=$(LD_PRELOAD=$_USE_GLIBC_PRELOAD git version 2>&1 >/dev/null) &&\n-\t test -z \"$stderr\"\n-\tthen\n-\t\t_USE_GLIBC_TUNABLES=YesPlease\n-\tfi\n-\tsetup_malloc_check () {\n-\t\tlocal g\n-\t\tlocal t\n-\t\tMALLOC_CHECK_=3\tMALLOC_PERTURB_=165\n-\t\texport MALLOC_CHECK_ MALLOC_PERTURB_\n-\t\tif test -n \"$_USE_GLIBC_TUNABLES\"\n-\t\tthen\n-\t\t\tg=\n-\t\t\tLD_PRELOAD=$_USE_GLIBC_PRELOAD\n-\t\t\tfor t in \\\n-\t\t\t\tglibc.malloc.check=1 \\\n-\t\t\t\tglibc.malloc.perturb=165\n-\t\t\tdo\n-\t\t\t\tg=\"${g#:}:$t\"\n-\t\t\tdone\n-\t\t\tGLIBC_TUNABLES=$g\n-\t\t\texport LD_PRELOAD GLIBC_TUNABLES\n-\t\tfi\n-\t}\n-\tteardown_malloc_check () {\n-\t\tunset MALLOC_CHECK_ MALLOC_PERTURB_\n-\t\tunset LD_PRELOAD GLIBC_TUNABLES\n-\t}\n-fi\n-\n # Protect ourselves from common misconfiguration to export\n # CDPATH into the environment\n unset CDPATH\n@@ -1486,6 +1436,56 @@ GIT_ATTR_NOSYSTEM=1\n GIT_CEILING_DIRECTORIES=\"$TRASH_DIRECTORY/..\"\n export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_ATTR_NOSYSTEM GIT_CEILING_DIRECTORIES\n \n+# Add libc MALLOC and MALLOC_PERTURB test only if we are not executing\n+# the test with valgrind and have not compiled with conflict SANITIZE\n+# options.\n+if test -n \"$valgrind\" ||\n+ test -n \"$SANITIZE_ADDRESS\" ||\n+ test -n \"$SANITIZE_LEAK\" ||\n+ test -n \"$TEST_NO_MALLOC_CHECK\"\n+then\n+\tsetup_malloc_check () {\n+\t\t: nothing\n+\t}\n+\tteardown_malloc_check () {\n+\t\t: nothing\n+\t}\n+else\n+\t_USE_GLIBC_TUNABLES=\n+\t_USE_GLIBC_PRELOAD=libc_malloc_debug.so.0\n+\tif _GLIBC_VERSION=$(getconf GNU_LIBC_VERSION 2>/dev/null) &&\n+\t _GLIBC_VERSION=${_GLIBC_VERSION#\"glibc \"} &&\n+\t expr 2.34 \\<= \"$_GLIBC_VERSION\" >/dev/null &&\n+\t stderr=$(LD_PRELOAD=$_USE_GLIBC_PRELOAD git version 2>&1 >/dev/null) &&\n+\t test -z \"$stderr\"\n+\tthen\n+\t\t_USE_GLIBC_TUNABLES=YesPlease\n+\tfi\n+\tsetup_malloc_check () {\n+\t\tlocal g\n+\t\tlocal t\n+\t\tMALLOC_CHECK_=3\tMALLOC_PERTURB_=165\n+\t\texport MALLOC_CHECK_ MALLOC_PERTURB_\n+\t\tif test -n \"$_USE_GLIBC_TUNABLES\"\n+\t\tthen\n+\t\t\tg=\n+\t\t\tLD_PRELOAD=$_USE_GLIBC_PRELOAD\n+\t\t\tfor t in \\\n+\t\t\t\tglibc.malloc.check=1 \\\n+\t\t\t\tglibc.malloc.perturb=165\n+\t\t\tdo\n+\t\t\t\tg=\"${g#:}:$t\"\n+\t\t\tdone\n+\t\t\tGLIBC_TUNABLES=$g\n+\t\t\texport LD_PRELOAD GLIBC_TUNABLES\n+\t\tfi\n+\t}\n+\tteardown_malloc_check () {\n+\t\tunset MALLOC_CHECK_ MALLOC_PERTURB_\n+\t\tunset LD_PRELOAD GLIBC_TUNABLES\n+\t}\n+fi\n+\n if test -z \"$GIT_TEST_CMP\"\n then\n \tif test -n \"$GIT_TEST_CMP_USE_COPIED_CONTEXT\"\n-- \n2.47.0.527.gfb211c7f3b\n"},{"id":"507763","messageId":"87ttc2rp2e.fsf@iotcl.com","threadId":"62472","inReplyTo":"20241114013912.GA1155455@coredump.intra.peff.net","subject":"Re: [PATCH 2/1] test-lib: move malloc-debug setup after $PATH setup","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2024-11-20T13:51:21Z","receivedAt":"2024-11-20T13:51:36Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Jeff King writes:\n\n> Originally, the conditional definition of the setup/teardown functions\n> for malloc checking could be run at any time, because they depended only\n> on command-line options and the system getconf function.\n>\n> [...snip...]\n>\n> if test -z \"$GIT_TEST_CMP\"\n> then\n> \tif test -n \"$GIT_TEST_CMP_USE_COPIED_CONTEXT\"\n> -- \n> 2.47.0.527.gfb211c7f3b\n\nFor what it's worth, I've tested this patch and I wanted to quickly\nconfirm this works as expected.\n\n-- \nToon\n"},{"id":"507796","messageId":"xmqq4j41ij0l.fsf@gitster.g","threadId":"62472","inReplyTo":"87ttc2rp2e.fsf@iotcl.com","subject":"Re: [PATCH 2/1] test-lib: move malloc-debug setup after $PATH setup","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-11-20T23:26:50Z","receivedAt":"2024-11-20T23:26:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Toon Claes writes:\n\n> Jeff King writes:\n>\n>> Originally, the conditional definition of the setup/teardown functions\n>> for malloc checking could be run at any time, because they depended only\n>> on command-line options and the system getconf function.\n>>\n>> [...snip...]\n>>\n>> if test -z \"$GIT_TEST_CMP\"\n>> then\n>> \tif test -n \"$GIT_TEST_CMP_USE_COPIED_CONTEXT\"\n>> -- \n>> 2.47.0.527.gfb211c7f3b\n>\n> For what it's worth, I've tested this patch and I wanted to quickly\n> confirm this works as expected.\n\nThanks, both.\n"}]}