cvs commit: src/lib/libc/stdlib malloc.c

[Giorgos Keramidas]

On 2006-01-14 14:13, Jason Evans <jasone at 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 :)