On 2/18/2013 4:06 PM, Katsumi Yamaoka wrote:
> Program received signal SIGSEGV, Segmentation fault.
> mmap_alloc (var=0xf26d18, nbytes=15273) at buffer.c:4906
> 4906            r->next->prev = r;
> (gdb) bt
> #0  mmap_alloc (var=0xf26d18, nbytes=15273) at buffer.c:4906
> #1  0x004d07b9 in mmap_realloc (nbytes=15273, var=0xf26d18) at buffer.c:4945
> #2  enlarge_buffer_text (b=0xf26c00, delta=0) at buffer.c:5053
> #3  0x004d1e16 in init_buffer () at buffer.c:5301
> #4  0x004af6dd in main (argc=1, argv=0x22ac40) at emacs.c:1305
> (gdb) 
> 
> Is any other information required?  Thanks.

The problem is that mmap_regions, the head of a linked list of memory
allocations we've made for buffers, is non-NULL in the dumped Emacs, but
obviously points to garbage that was valid only before Emacs was dumped. The
call to mmap_set_vars in Fdump_emacs is supposed to zero these variables before
we dump Emacs, but mmap_regions becomes non-NULL inside Fdump_emacs:

gdb) where
#0  mmap_alloc (var=0x7ca918, nbytes=6389) at buffer.c:4909
#1  0x004b0039 in mmap_realloc (nbytes=6389, var=0x7ca918) at buffer.c:4945
#2  enlarge_buffer_text (b=0x7ca800, delta=0) at buffer.c:5053
#3  0x004b0148 in set_buffer_internal_1 (b=0x7ca800) at buffer.c:2104
#4  0x004b068b in set_buffer_internal (b=<optimized out>) at buffer.h:1090
#5  Fset_buffer (buffer_or_name=8169477) at buffer.c:2195
#6  0x0041e47c in message_dolog (m=0x287110 "Static heap usage: 11072128 of
13631488 bytes\rC", nbytes=45, nlflag=true,
    multibyte=false) at xdisp.c:9389
#7  0x00430d50 in message3 (m=17698433) at xdisp.c:9598
#8  0x0054da7e in report_sheap_usage (die_if_pure_storage_exceeded=1) at sheap.c:94
#9  0x0052ec2a in unexec (outfile=0x121f934 "/users/dancol/edev/cyg/src/emacs",
infile=0x121f968 "/users/dancol/edev/cyg/src/temacs")
    at unexcw.c:287
#10 0x0048de13 in Fdump_emacs (filename=17698561, symfile=17698449) at emacs.c:2056
#11 0x004fb913 in eval_sub (form=11000526) at eval.c:2043
#12 0x004fbc8e in Fprogn (args=11000262) at eval.c:359
#13 0x004fba80 in eval_sub (form=10618670) at eval.c:1988
#14 0x004fba80 in eval_sub (form=10273462) at eval.c:1988
#15 0x0051cbd6 in readevalloop (readcharfun=10344786, stream=0x7ca60c,
sourcename=10459185, printflag=false, unibyte=10283034,
    readfun=10283034, start=10283034, end=10283034) at lread.c:1855
#16 0x0051d8c4 in Fload (file=10400673, noerror=10283034, nomessage=10283034,
nosuffix=10283034, must_suffix=10283034) at lread.c:1326
#17 0x004fb8b9 in eval_sub (form=10268918) at eval.c:2054
#18 0x004fd8b2 in Feval (form=10268918, lexical=10283034) at eval.c:1902
#19 0x0049240c in top_level_2 () at keyboard.c:1182
#20 0x004faac4 in internal_condition_case (bfun=0x4923f0 <top_level_2>,
handlers=10325114, hfun=0x493c90 <cmd_error>) at eval.c:1193
#21 0x00492c30 in top_level_1 (ignore=10283034) at keyboard.c:1190
#22 0x004fa9ea in internal_catch (tag=10314994, func=0x492bd0 <top_level_1>,
arg=10283034) at eval.c:964
#23 0x004937a8 in command_loop () at keyboard.c:1151
#24 recursive_edit_1 () at keyboard.c:785
#25 0x00493ab1 in Frecursive_edit () at keyboard.c:849
#26 0x0048f662 in main (argc=<optimized out>, argv=0x28ac20) at emacs.c:1556

I don't know why we suddenly started seeing this behavior.