Paul Dufresne, le dim. 28 févr. 2021 01:01:10 -0500, a ecrit:
> #26 0x031e5fa4 in abort () at /lib/i386-gnu/libc.so.0.3
> #27 0x03279e6f in () at /lib/i386-gnu/libc.so.0.3
> #28 0x0328177d in () at /lib/i386-gnu/libc.so.0.3
> #29 0x03282bbd in () at /lib/i386-gnu/libc.so.0.3
> #30 0x0817f5f1 in
Rebuild vim again... this time the error was double free or prec != ...
something.
Also the error is in vim-gtk3.
I have use ps, to find pid of the test.
run gdb
attach pid_of_the_test
file vim (in gtk3)
bt
note that 0 is the last thing happened.
So in a vim_free (#30), it aborted, much
Joshua Branson, le sam. 27 févr. 2021 09:34:05 -0500, a ecrit:
> Paul Dufresne writes:
> > Le ven., 26 févr. 2021 23:29:01 -0500 Jessica Clarke
> > écrit
> >>
> > > I'd advise you to not delve too deeply into malloc. This is likely a
> > > buffer overflow that then corrupts the (inli
Paul Dufresne writes:
> Le ven., 26 févr. 2021 23:29:01 -0500 Jessica Clarke
> écrit
>>
> > I'd advise you to not delve too deeply into malloc. This is likely a
> > buffer overflow that then corrupts the (inline) state maintained by
> > malloc, so you really need to be looking at v
Really, malloc() is used by *all* other software in Debian Hurd, I don't
think it is where the bug lies, it'd appear in other software. Better
look at vim.
Samuel
Le ven., 26 févr. 2021 23:29:01 -0500 Jessica Clarke
écrit
>
> I'd advise you to not delve too deeply into malloc. This is likely a
> buffer overflow that then corrupts the (inline) state maintained by
> malloc, so you really need to be looking at vim.
>
> Jess
I have an i
Le ven., 26 févr. 2021 23:13:56 -0500 Jessica Clarke
écrit
>
> The low 3 bits of the actual size are known to always be 0, so they
> aren't stored and instead replaced with the 3 flags. The diagram
> doesn't make that overly clear, but if you re-read all the text it
> should.
On 27 Feb 2021, at 02:38, Paul Dufresne wrote:
>
> Here is the relevant part in malloc.c:
I'd advise you to not delve too deeply into malloc. This is likely a
buffer overflow that then corrupts the (inline) state maintained by
malloc, so you really need to be looking at vim.
Jess
> /*
>
Here is the relevant part in malloc.c:
/*
Search for a chunk by scanning bins, starting with next largest
bin. This search is strictly by best-fit; i.e., the smallest
(with ties going to approximately the least recently used) chunk
that fits is selected.
On 27 Feb 2021, at 03:57, Paul Dufresne wrote:
>
> This looks like one of these moments I think I am brighter than I am... but
> here my reasoning of the problem so far:
>
> I am using https://github.com/bminor/glibc/blob/master/malloc/malloc.c
>
> In it we see:
>
>> chunk-> +-+-+-+-+-+-+-+-+
This looks like one of these moments I think I am brighter than I am... but
here my reasoning of the problem so far:
I am using https://github.com/bminor/glibc/blob/master/malloc/malloc.c
In it we see:
> chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |
Paul Dufresne, le ven. 26 févr. 2021 20:58:55 -0500, a ecrit:
> > > vim: malloc.c:4034: _int_malloc: Assertion `(unsigned long) (size) >=
> (unsigned long) (nb)' failed.
>
> Strangely, the error seems to be seen by many people, in different projects:
That is probably just saying that there is
> > vim: malloc.c:4034: _int_malloc: Assertion `(unsigned long) (size) >=
> > (unsigned long) (nb)' failed.
Strangely, the error seems to be seen by many people, in different projects:
This one have found a fix, in a small C program (in 2010):
https://www.linuxquestions.org/questions/programm
Paul Dufresne, le ven. 26 févr. 2021 18:29:01 -0500, a ecrit:
> Le ven., 26 févr. 2021 16:48:57 -0500 Samuel Thibault
> écrit
>
> > Paul Dufresne, le ven. 26 févr. 2021 16:42:16 -0500, a ecrit:
> > > Got this on daily image (was a few days I did not tried):
> > > vim depends on vi
Le ven., 26 févr. 2021 16:48:57 -0500 Samuel Thibault
écrit
> Paul Dufresne, le ven. 26 févr. 2021 16:42:16 -0500, a ecrit:
> > Got this on daily image (was a few days I did not tried):
> > vim depends on vim-common (= 2:8.2.2434-1); however:
> > Version of vim-common on system
Paul Dufresne, le ven. 26 févr. 2021 16:42:16 -0500, a ecrit:
> Got this on daily image (was a few days I did not tried):
> vim depends on vim-common (= 2:8.2.2434-1); however:
> Version of vim-common on system is 2:8.2.2434-2.
As long as not all vim bugs are fixed we'll have such issue on each vi
Got this on daily image (was a few days I did not tried):
vim depends on vim-common (= 2:8.2.2434-1); however:
Version of vim-common on system is 2:8.2.2434-2.
Vim depends on vim-runtime (= 2:8.2.2434-1); however:
Version of vim -runtime on system is 2:8.2.2434-2.
vim-tiny depends on vim-c
17 matches
Mail list logo
