[haiku-development] weird segfault in malloc internals when trying to call fdopen()

  • From: Alexander Botero-Lowry <alex.boterolowry@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 15 Oct 2009 22:04:10 -0700

Hi,

I've been working for the last two days or so to get GNU emacs 23.1.50
compiling on Haiku. Last night i finally got the bootstrap emacs, temacs
compiled, but couldn't get it to run because it was overriding a bunch of
stuff in crt0 rendering argv broken. :)

Tonight I figured that bit out, and I finally got temacs loading! I get
about 6 elisp files into the bootstrap when I hit one that deals with charsets
and loads the charset maps off disk. The emacs file open process is basically
a call to a wrapper around open() followed by fdopen() on the fd to get a FILE
stream. This works for about 6 of the charset files, and then after that the 
call
to fdopen renders a very scary traceback deep in the bowels of malloc:

(gdb) bt
#0  0x005892ca in _ZL12insert_chunkP10free_chunk () from 
/boot/system/lib/gcc4/libroot.so
#1  0x0058954f in BPrivate::hoardSbrk () from /boot/system/lib/gcc4/libroot.so
#2  0x0058d5f5 in BPrivate::superblock::makeSuperblock () from 
/boot/system/lib/gcc4/libroot.so
#3  0x0058dc5b in BPrivate::threadHeap::malloc () from 
/boot/system/lib/gcc4/libroot.so
#4  0x0058f101 in malloc () from /boot/system/lib/gcc4/libroot.so
#5  0x005ac5f8 in _IO_file_doallocate () from /boot/system/lib/gcc4/libroot.so
#6  0x005ae8e6 in _IO_doallocbuf () from /boot/system/lib/gcc4/libroot.so
#7  0x005acddc in _IO_new_file_seekoff () from /boot/system/lib/gcc4/libroot.so
#8  0x005accf7 in _IO_new_file_attach () from /boot/system/lib/gcc4/libroot.so
#9  0x005afb61 in fdopen () from /boot/system/lib/gcc4/libroot.so
#10 0x002732b8 in load_charset_map_from_file (charset=0x7ffedf28, 
mapfile=403507235, control_flag=0) at charset.c:524
#11 0x002736c5 in load_charset (charset=Variable "charset" is not available.) 
at charset.c:657
#12 0x00276f12 in Fdefine_charset_internal (nargs=17, args=0x7ffee114) at 
charset.c:1211
#13 0x0031d84d in Ffuncall (nargs=18, args=0x7ffee110) at eval.c:3038
#14 0x0031f006 in Fapply (nargs=3, args=0x7ffee1c0) at eval.c:2545
#15 0x0031f892 in Feval (form=403571893) at eval.c:2361
#16 0x0031fc04 in Fprogn (args=403571805) at eval.c:450
#17 0x003209ec in Flet (args=403574629) at eval.c:1103
#18 0x0031f8b5 in Feval (form=403521661) at eval.c:2335
#19 0x0031fc04 in Fprogn (args=403571797) at eval.c:450
#20 0x0031fef6 in funcall_lambda (fun=403571784, nargs=12, 
arg_vector=0x7ffee470) at eval.c:3237
#21 0x00320054 in apply_lambda (fun=403571789, args=403823469, eval_flag=1) at 
eval.c:3168
#22 0x0031f448 in Feval (form=403823477) at eval.c:2448
#23 0x0031fc04 in Fprogn (args=403821861) at eval.c:450
#24 0x0031f8b5 in Feval (form=403821869) at eval.c:2335
#25 0x0031f608 in Feval (form=403828045) at eval.c:2446
#26 0x0034218e in readevalloop (readcharfun=403066577, stream=0x18010048, 
sourcename=403228467, evalfun=0x31f210 <Feval>, printflag=0, unibyte=402868225, 
readfun=402868225, start=402868225, end=402868225) at lread.c:1792
#27 0x00343848 in Fload (file=403228627, noerror=402868225, 
nomessage=402868225, nosuffix=402868225, must_suffix=402868225) at lread.c:1269
#28 0x0031f6fc in Feval (form=402907109) at eval.c:2416
#29 0x0034218e in readevalloop (readcharfun=403066577, stream=0x180101f0, 
sourcename=403198627, evalfun=0x31f210 <Feval>, printflag=0, unibyte=402868225, 
readfun=402868225, start=402868225, end=402868225) at lread.c:1792
#30 0x00343848 in Fload (file=403198499, noerror=402868225, 
nomessage=402868225, nosuffix=402868225, must_suffix=402868225) at lread.c:1269
#31 0x0031f6fc in Feval (form=402903365) at eval.c:2416
#32 0x002b27f1 in top_level_2 () at keyboard.c:1366
#33 0x0031ca3f in internal_condition_case (bfun=0x2b27d0 <top_level_2>, 
handlers=402979889, hfun=0x2b61a0 <cmd_error>) at eval.c:1525
#34 0x002b5f05 in top_level_1 () at keyboard.c:1374
#35 0x0031cb21 in internal_catch (tag=402972913, func=0x2b5ea0 <top_level_1>, 
arg=402868225) at eval.c:1261
#36 0x002b5fb3 in command_loop () at keyboard.c:1329
#37 0x002b6367 in recursive_edit_1 () at keyboard.c:951
#38 0x002b64cd in Frecursive_edit () at keyboard.c:1013
#39 0x002aba1e in main (argc=5, argv=0x7ffef538) at emacs.c:1830

I've not had much luck locating the code where the segfault occurs specifically
but I was hoping someone who knew the code better could help..

I tried to file this as a bug, but Trac tells me i don't have TICKET_CREATE
privs even though i verified my email address. (because even if I'm doing
something wrong, I figure malloc should be more defensive against segfaults).

Thanks,
Alex

Other related posts: