On 10/4/21 9:44 PM, Dominique Martinet wrote:
Chet Ramey wrote on Mon, Oct 04, 2021 at 09:23:11PM -0400:
- I could reproduce the same as Julien, with -DDISABLE_MALLOC_WRAPPERS
the crash still happens when bash is run directly but nothing complains
in valgrind.
I assume you mean using system
Chet Ramey wrote on Mon, Oct 04, 2021 at 09:23:11PM -0400:
> > - I could reproduce the same as Julien, with -DDISABLE_MALLOC_WRAPPERS
> > the crash still happens when bash is run directly but nothing complains
> > in valgrind.
>
> I assume you mean using systemd. Has anyone tried running a bash
On 10/4/21 8:39 PM, Dominique Martinet wrote:
(not sure how that works? bash internal
malloc just passes to free pointers it doesn't know about?)
What does this mean? What pointers it doesn't know about? (If bash realloc
or free gets a pointer that wasn't allocated by the bash malloc, it
throw
On 10/4/21 8:15 PM, Dominique Martinet wrote:
(I've been following this with Julien as I can reproduce the behaviour
on my nixos system -- you don't have to run the latest systemd, just
install the derivation and use its path in LD_LIBRARY_PATH instead of
the system's... That also probably could
Dominique Martinet wrote on Tue, Oct 05, 2021 at 09:15:48AM +0900:
> - I could reproduce the same as Julien, with -DDISABLE_MALLOC_WRAPPERS
> the crash still happens when bash is run directly but nothing complains
> in valgrind.
> This could mean that systemd is overflowing bash malloc safeguards
Hello,
(I've been following this with Julien as I can reproduce the behaviour
on my nixos system -- you don't have to run the latest systemd, just
install the derivation and use its path in LD_LIBRARY_PATH instead of
the system's... That also probably could bring its own set of
incompatibility but
On Okt 04 2021, Chet Ramey wrote:
> You'd think. This is the kind of overflow that will produce that error
> message from the bash malloc:
Only after the fact. valgrind finds it before it is happening, and even
if the overflow hits a padding between memory blocks.
$ valgrind ./a.out
==31974==
On 10/4/21 4:44 PM, Andreas Schwab wrote:
On Okt 04 2021, Chet Ramey wrote:
I suspect this is a buffer overflow introduced between systemd-247 and
systemd-249. It's not caught when building bash without the bash malloc
because the default libc malloc probably doesn't do the bounds checking
the
On 10/4/21 5:28 PM, Julien Moutinho wrote:
On Okt 04 2021, Chet Ramey wrote:
I suspect this is a buffer overflow introduced between systemd-247 and
systemd-249. It's not caught when building bash without the bash malloc
because the default libc malloc probably doesn't do the bounds checking
the
On Okt 04 2021, Chet Ramey wrote:
> I suspect this is a buffer overflow introduced between systemd-247 and
> systemd-249. It's not caught when building bash without the bash malloc
> because the default libc malloc probably doesn't do the bounds checking
> the bash malloc does, even without malloc
On Okt 04 2021, Chet Ramey wrote:
> On 10/3/21 11:59 PM, Julien Moutinho wrote:
>> Bash Version: 5.1
>> Patch Level: 8
>> Release Status: release
>> Architecture: x86_64-linux
>>
>> Description:
>>
>> bash-5.1 reaches crashing code paths
>> when launched by systemd-249 or valgrind.
>> I cannot g
Le lun. 04 oct. 2021 14h51 -0400, Chet Ramey a écrit :
> It's a problem with valgrind, described in another thread with this
> subject. Build bash with -DDISABLE_MALLOC_WRAPPERS to work around it.
Thanks Chet, that flag makes those crashes disappear.
However the crash after _nss_systemd_getpwuid_r(
On 10/3/21 11:59 PM, Julien Moutinho wrote:
> Bash Version: 5.1
> Patch Level: 8
> Release Status: release
> Architecture: x86_64-linux
>
> Description:
>
> bash-5.1 reaches crashing code paths
> when launched by systemd-249 or valgrind.
> I cannot get such crashes when bash is built using:
> ./c
On 10/4/21 12:23 PM, Julien Moutinho wrote:
> Le lun. 04 oct. 2021 10h34 +0200, Andreas Schwab a écrit :
>> Here is a patch:
> Thanks Andreas, that particular crash disappears with this patch.
> However the crash after _nss_systemd_getpwuid_r() is still happening for me,
> and valgrind can still fi
On 10/4/21 12:27 PM, Andreas Schwab wrote:
> On Okt 04 2021, Chet Ramey wrote:
>
>> Nope. These are all functions internal to bash and the bash malloc, and
>> they are all defined.
>
> The problem is that the xmalloc macro redirects directly to the internal
> malloc implementation, whereas the xf
On Okt 04 2021, Chet Ramey wrote:
> Nope. These are all functions internal to bash and the bash malloc, and
> they are all defined.
The problem is that the xmalloc macro redirects directly to the internal
malloc implementation, whereas the xfree function calls it indirectly
through the free funct
Le lun. 04 oct. 2021 10h34 +0200, Andreas Schwab a écrit :
> Here is a patch:
Thanks Andreas, that particular crash disappears with this patch.
However the crash after _nss_systemd_getpwuid_r() is still happening for me,
and valgrind can still find a similar crash after source_builtin():
$ nix -L
On 10/4/21 11:08 AM, Andreas Schwab wrote:
> On Okt 04 2021, Chet Ramey wrote:
>
>> Nope, I don't buy that as the reason. xfree (name of function) and xfree(x)
>> (macro defined in xmalloc.h) are not the same thing.
>
> That's exactly the problem. You cannot pass the return value from
> sh_xmall
On Okt 04 2021, Chet Ramey wrote:
> Nope, I don't buy that as the reason. xfree (name of function) and xfree(x)
> (macro defined in xmalloc.h) are not the same thing.
That's exactly the problem. You cannot pass the return value from
sh_xmalloc to xfree, only sh_xfree.
> and everything works cor
On 10/4/21 10:17 AM, Andreas Schwab wrote:
> On Okt 04 2021, Chet Ramey wrote:
>
>> On 10/4/21 4:34 AM, Andreas Schwab wrote:
>>> On Okt 04 2021, Julien Moutinho wrote:
>>>
- bash crashes inside valgrind too,
but apparently something different is happening
because it crashes eve
On Mon, Oct 4, 2021, 9:09 AM Ilkka Virta wrote:
> On Mon, Oct 4, 2021 at 4:46 PM Chet Ramey wrote:
>
> > Bash reports the error it gets back from execve. In this case, it's
> > probably that the loader specified for the executable isn't present on
> your
> > system.
> >
>
> OTOH, for a script, B
On Okt 04 2021, Chet Ramey wrote:
> On 10/4/21 4:34 AM, Andreas Schwab wrote:
>> On Okt 04 2021, Julien Moutinho wrote:
>>
>>> - bash crashes inside valgrind too,
>>> but apparently something different is happening
>>> because it crashes even without systemd being involved:
>>>
>>> $ nix buil
Found out that the declare statement does not properly set all variable
flags before assign values:
unset arr
declare -i -a arr=(1 2 3)
declare -p arr
declare -ai arr=([0]="1" [1]="2" [2]="3")
this is ok
declare +i -a arr=(hello world)
declare -p arr
declare -a arr=([0]="0" [1]="0")
this
On 10/4/21 4:34 AM, Andreas Schwab wrote:
> On Okt 04 2021, Julien Moutinho wrote:
>
>> - bash crashes inside valgrind too,
>> but apparently something different is happening
>> because it crashes even without systemd being involved:
>>
>> $ nix build .#bash5-with-bash-malloc
>> $ valgrind res
On Mon, Oct 4, 2021 at 4:46 PM Chet Ramey wrote:
> Bash reports the error it gets back from execve. In this case, it's
> probably that the loader specified for the executable isn't present on your
> system.
>
OTOH, for a script, Bash checks to see if the problem is with the
interpreter and repor
On 10/3/21 6:05 PM, Andrea Monaco wrote:
>
> Hello,
>
>
> I'm using bash 5.0.3 on GNU/Linux. When I mount a GNU/Hurd filesystem and
> try to run an executable found there, I get for example:
>
> bash: ./ext2fs: No such file or directory
>
> This seems a misleading error to me. The file is th
On Okt 04 2021, Julien Moutinho wrote:
> - bash crashes inside valgrind too,
> but apparently something different is happening
> because it crashes even without systemd being involved:
>
> $ nix build .#bash5-with-bash-malloc
> $ valgrind result/bin/bash --norc -c true
>> ==307088== Memcheck,
27 matches
Mail list logo
