Subject: Re: The _weirdest_ segfault...
To: Andreas Falck <faland-7@sm.luth.se>
From: David Brownlee <abs@netbsd.org>
List: port-alpha
Date: 05/17/2000 21:33:39
OK - my money is with everyone else's on "the something else is
corrupting malloc()'s memory" bet :)
Random options include adding an extra 1K to every malloc length
call to see if that fixes it (if it does you have a good idea of
the problem)
David/absolute
-- www.netbsd.org: No hype required --
On Wed, 17 May 2000, Andreas Falck wrote:
>
> Oh yeah, it could help too :)
>
> 'i' is the size of the token:
>
> amish>pushd /usr
> [5]
> [4]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x160541330 in malloc ()
>
> i=5 chrashes too, even though it worked above. But this works:
>
> amish>pushd /usrrr
> [5]
> [6]
> amish>
>
> i=8 works, but the next segfault comes from within the readline lib!
>
> #0 0x160541330 in malloc ()
> #1 0x160235c3c in xmalloc ()
> #2 0x1602210a8 in maybe_save_line ()
> ... (libreadline functions)
>
> Still strange...
>
> /Andreas
>
>
> On Wed, 17 May 2000, David Brownlee wrote:
>
> > What is i at that point (can you add a printf() directly before
> > the malloc())
> >
> > It could be general memory corruption, but its much easier to
> > verify the args passed first :)
> >
> >
> > David/absolute
> > -- www.netbsd.org: No hype required --
> >
> > On Wed, 17 May 2000, Andreas Falck wrote:
> >
> > > > Out of curiosity, what value are you passing to malloc()?
> > > >
> > > Of course, I forgot:
> > >
> > > temp = malloc((i + 1) * (sizeof(char)));
> > >
> > > It allocates memory for a token out of a whitespace-separated string.
> > >
> > > /Andreas
> > >
> > >
> >
> >
>
>