Ok, this seems like a reasonable explanation. If my code is  corrupting
information that malloc() uses that would explain why it can segfault in
readline too. Im aware of that there are huge differences between 64bit
risc and x86 (actually I did'nt expect it to compile at all).

The thing I found strange was that a libc function got weird, but now I
realize how it can happen.

Thanks!

/Andreas

On Wed, 17 May 2000, Peter Seebach wrote:

> In message <Pine.GSO.4.21.0005172310280.15360-100000@sigma1.sm.luth.se>, Andrea
> s Falck writes:
> >Yes, but it's not the writes or reads that segfaults, it's 
> >malloc() itself!
> 
> Yes.  Because malloc() is making decisions based on corrupted data.
> 
> >The shell works perfectly on FreeBSD/x86 where it was developed, the
> >problem is only on the Alpha!
> 
> No surprise; the rules are different, the way memory is laid out may vary.
> 
> Imagine this:
> 	p = malloc(16);
> What happens?
> 
> 1.  16 bytes are allocated.
> 2.  Something, somewhere, makes a note that that 16 byte area is allocated.
> 
> That latter data is *also* in dynamically allocated space.  It may be adjacent
> to the 16 bytes.  If you overwrite it, you are not doing anything that
> "should" segfault (you're still writing to memory owned by your process), but
> you are corrupting the data malloc() will use to make later decisions about
> memory layout.
> 
> Anyway, if it were an alignment thing, you'd either get no crashes, or a bus
> error.  Segfault is access to memory you don't own, which is consistent with
> trashed resources.
> 
> -s
>