[haiku-development] Re: weird segfault in malloc internals when trying to call fdopen()
- From: Alexander Botero-Lowry <alex.boterolowry@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx, Caitlin Shaw <rogueeve@xxxxxxxxxxxxx>
- Date: Fri, 16 Oct 2009 21:41:30 -0700
> > Unless you can reproduce that in a simple test, I'd consider it more likely
>
> > that something else corrupts the heap (e.g. by overwriting memory) and that
>
> > fdopen() is just an innocent bystander becoming the victim.
> >
> > CU, Ingo
> >
> >
> That is what I thought as well. The behavior you describe is what I
> would call "weird", and that sort of weird behavior smells like malloc
> bookkeeping corruption. I think a contributing factor is that this
> sounds like a large, partially ported application that you don't fully
> have a handle on yet. There's various well-documented things you could
That's an understatement. The degree to which emacs' build proceess is
``complicated'' is.. impressive. I'm learning things I didn't even know
were quite possible during the process of porting it (like unexec).
> do to sniff it out, for example you could wrap malloc and have it write
> guard bytes before and after every block, so free() can detect when the
> application was being naughty with one of the blocks given to it. The
> library I use for this is called smal and you can pull it out of the
> Sisong common directory, although it's nothing special and there are
> many other such tools on the net. It's one of the more frustrating types
> of bugs but certainly not impossible to track down.
>
The issues here are compounded by the fact that emacs includes its own malloc.
I will try to create a reproducable fdopen crash case, but I suspect that y'all
are correct that it is a malloc issue. That being said I'm not really sure how
to actually debug a malloc issue, and any help would be appreciated.
Thanks,
Alex
Other related posts:
