On Fri, Jan 15, 2021 at 6:23 PM Jeffrey Walton <[email protected]> wrote:
>
> On Fri, Jan 15, 2021 at 5:03 PM 'Evgenii Stepanov' via
> address-sanitizer <[email protected]> wrote:
> >
> > I think this "malloc.c" could be a problem. The way control jumped from
> > _dlerror_run to a non-ASan malloc is definitely not right.
>
> I don't see malloc.c in the Bash sources on Savannah. However, there's
> one in a site called Fossies at
> https://fossies.org/dox/bash-5.1/malloc_8c_source.html#l00817 .
>
> Could this be the cause of the mapping problem on line 848:
>
> /* Silently reject too-large requests. XXX - can increase this if HAVE_MMAP
> */
> if (nunits >= NBUCKETS)
> return ((PTR_T) NULL);
OK, so I had a little more time to work with this. I started
installing the source code in $prefix/src (and used
-fdebug-prefix-map) so the debugger would work.
The code is failing earlier than the test above. It is failing in prologue code:
Program received signal SIGSEGV, Segmentation fault.
0x00005555556fd300 in internal_malloc (n=n@entry=0x20, file=file@entry=0x0,
line=line@entry=0x0, flags=flags@entry=0x2) at malloc.c:824
824 {
(gdb) list
819 static PTR_T
820 internal_malloc (n, file, line, flags) /* get a block */
821 size_t n;
822 const char *file;
823 int line, flags;
824 {
825 register union mhead *p;
826 register int nunits;
827 register char *m, *z;
828 long nbytes;
(gdb)
Jeff
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/address-sanitizer/CAH8yC8mdWaqpjzw7TodgWnnsRWvHLr%2BaXtPjrqWoHrDbX5nxEQ%40mail.gmail.com.
