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 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.I did some more poking around by commenting out various bits of elisp code. If i comment out the define-charset call that causes this traceback, i get one define-charset call further. It seems in whatever combination I comment them out, I can do 6 define-charset/fdopen()s before the segfault. I also commented out that entire file from the bootstrap process, and got further, but ended up also getitng a segfault (though I _think_ it may be as result of missing symbols it expects from mule-conf.el). So my working theory is that haiku gets upset if you do > 6 fdopens() in quick succession.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
