Date: Sun, 15 Jan 2006 01:44:17 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Jason Evans <jasone@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib malloc.c Message-ID: <20060114234417.GA65773@flame.pc> In-Reply-To: <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@FreeBSD.org> References: <200601121809.k0CI9QGV028693@repoman.freebsd.org> <AD9B1A12-47F1-4EA1-B270-CC83D3149543@freebsd.org> <20060112182804.GA1047@flame.pc> <20060113012900.GA16082@flame.pc> <554CC8A8-35FB-424A-B883-505C26ECBBE8@FreeBSD.org> <20060114213238.GA15253@flame.pc> <6FD0F2BA-88E3-4E82-A5F8-D89051AEEECA@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2006-01-14 14:13, Jason Evans <jasone@FreeBSD.org> wrote:
> >Apparently it does seem related to posix_memalign() changes.
> >When I bootstrap Emacs without posix_memalign(), by manually
> >tweaking src/config.h after configure runs, and #undef
> >POSIX_MEMALIGN, then it passes the bootstrap stage normally.
>
> Hmm, that's interesting. I'll mess around with emacs later on today
> (though I only have i386 hardware at the moment). Right now, I'm
> still building xorg on my machine in order to try to reproduce the gtk
> problems that Pascal Hofstee reported.
I'll try to rebuild CURRENT on my i386 workstation too, but that takes a
couple of hours so I think it will be Sunday morning that I will have
results of bootstrapping Emacs on i386.
> >>If updating to either before or after the broken
> >>posix_memalign() revision, and need help figuring out the
> >>issue, please let me know.
> >
> >More issues come up after updating to today's CURRENT version of
> >malloc. In particular:
> >
> > irssi started core dumping with symptoms similar to those of
> > Emacs bootstrap, i.e. access to memory regions that are
> > <inaccessible> in gdb
>
> malloc's ability to output allocation logs when run via ktrace, in
> combination with a core dump, should be able to show precisely what
> is happening. If you're interested in tracking this down, I can help
> you. Otherwise, can you give me a bit more information on the
> conditions that cause the crash?
As a test of the new malloc, I rebuilt all my ports today with today's
current (i.e. after malloc.c,v 1.93). This is when irssi started
crashing. I'm half-way through a buildworld now, with DEBUG_FLAGS='-g'
and CFLAGS='-g' for autoconf-based ports.
The crash of irssi happens when I hit <space>, and irssi tries to split
a string in 'words'. It may be a stupid bug in irssi, because it uses:
/* Return whole word at specified position in string */
char *get_word_at(const char *str, int pos, char **startpos)
{
...
}
but there's no function argument that holds the allocated size of `str',
so I guess the fact that `pos' may point outside of the allocated area
of `str' is checked elsewhere.
Is option 'U' and running irssi under ktrace all it takes to enable the
extra trace checks?
> The amd64 computer I have on order won't be here for at least another
> week, so if this is amd64-specific, I won't be able to reproduce it
> right away.
I'll try to prepare a snapshot that is easy to 'restore' from CD-ROM, so
that I can continue to use my laptop for my $REALJOB, but also with the
latest malloc for debugging.
> >Apart from looking at the source code, do we have some sort of
> >'design' docs for the new malloc(), to see if I can help debug these
> >problems a bit more when I restore my laptop's ports & packages from
> >the backup later tonight?
>
> I have a draft of a paper that I submitted to BSDcan, but I don't
> think I should make it generally available yet, as a courtesy to
> BSDcan. I don't see a problem with providing it to individuals upon
> request, though.
No that's ok. I can hopefully read the source :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060114234417.GA65773>