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
> > > 
> > > 
> > 
> > 
> 
>