Hi, I first reported this problem with xemacs crashing in conv_path_list_buf_size back in June. It's taken me a while to get back to tracking down the problem, but I think I've made more progress. I have since upgraded to cygwin-1.5.0-1, and the same problem keeps recurring.
The issue seems to be that normalized_path is set to NULL during construction of the path_conv pc, because of a failed call to VirtualAlloc deep in the cstrdup() function. Here is a stack trace, after reaching a breakpoint at cygheap.cc line 189: (gdb) where #0 _csbrk(int) (sbs=40) at ../../../../cygwin-1.5.0-1/winsup/cygwin/cygheap.cc: 189 #1 0x61002161 in _cmalloc(unsigned) (size=28) at ../../../../cygwin-1.5.0-1/win sup/cygwin/cygheap.cc:232 #2 0x610022fd in cmalloc (x=HEAP_STR, n=20) at ../../../../cygwin-1.5.0-1/winsu p/cygwin/cygheap.cc:306 #3 0x61002605 in cstrdup (s=0x149df30 "/home/mccap/cygbugs") at ../../../../cyg win-1.5.0-1/winsup/cygwin/cygheap.cc:362 #4 0x61054d3c in path_conv::check(char const*, unsigned, suffix_info const*) (t his=0x149e0d0, src=0x610565e4 ".", opt=176, suffixes=0x0) at ../../../../cygwin- 1.5.0-1/winsup/cygwin/path.cc:764 #5 0x610d75cd in path_conv::path_conv(char const*, unsigned, suffix_info const* ) (this=0x149e0d0, src=0x610565e4 ".", opt=144, suffixes=0x0) at ../../../../cyg win-1.5.0-1/winsup/cygwin/path.h:141 #6 0x6105c448 in conv_path_list_buf_size(char const*, bool) (path_list=0x149e46 c "/home/mccap/Mail/3GPP2TSGP", to_posix=false) at ../../../../cygwin-1.5.0-1/wi nsup/cygwin/path.cc:3621 #7 0x6105c6eb in cygwin_posix_to_win32_path_list_buf_size (path_list=0x149e46c "/home/mccap/Mail/3GPP2TSGP") at ../../../../cygwin-1.5.0-1/winsup/cygwin/path.c c:3662 #8 0x0049c429 in Ffile_truename (filename=281806500, default_=6408196) at filei o.c:1361 #9 0x00456a49 in Ffuncall (nargs=2, args=0x149e6e8) at eval.c:3842 #10 0x004164c3 in execute_optimized_program (program=0x102edb10 "A\b!r\025AA!«\b AA\b!!r\tAÄ!-\004Ä\b!\207", stack_depth=3, constants_data=0x101de0d0) at bytecod e.c:609 #11 0x0045cef4 in funcall_compiled_function (fun=271445468, nargs=1, args=0x149e 93c) at eval.c:3449 #12 0x00456de3 in Ffuncall (nargs=2, args=0x149e938) at eval.c:3881 #13 0x004164c3 in execute_optimized_program (program=0x10fdb310 "\016\030?\205¢" , stack_depth=12, constants_data=0x10b29910) at bytecode.c:609 #14 0x0045cef4 in funcall_compiled_function (fun=280159796, nargs=2, args=0x149e bb8) at eval.c:3449 #15 0x00456de3 in Ffuncall (nargs=3, args=0x149ebb4) at eval.c:3881 #16 0x004164c3 in execute_optimized_program (program=0x10fdb410 "Æ\026\030\v"«\0 27\f«\rÇ\fEÉ \v\"\v#\210ª\026E\n\v\"\210ª\017\f«\aE\f!\210ª\006E\nÆ\"\210I Æ\211 \031\030\035I ¬>\r«;[EMAIL PROTECTED]@q\210\016\031I=«$D\211\020«\037\016\032¬\e\016 \027\021ÑÆD\"\026\027\t\016\027=¬\fOO \016\e\"\210OO!\210)\rA\025ªAÖ \210\b?-\02 1\r?-\r\f«\006E\f!ª\005E\nÆ\"+\207", stack_depth=5, constants_data=0x1017c010) a t bytecode.c:609 #17 0x0045cef4 in funcall_compiled_function (fun=280158696, nargs=0, args=0x149e e18) at eval.c:3449 #18 0x00456de3 in Ffuncall (nargs=1, args=0x149ee14) at eval.c:3881 #19 0x004164c3 in execute_optimized_program (program=0x149ef54 "Æ \eÇ\216\f\035E \211\032\031E\211\030\036\rE\211\036\016\034E\211\036\017\036\020É\r!«\fEE\r!I\r !\"\210ª\006E\r! \210.\vE\207¬\003U\020\034\003d", stack_depth=5, constants_data =0x800690) at bytecode.c:609 #20 0x0041b6d7 in Fbyte_code (instructions=8270116, constants=8390272, stack_dep th=11) at bytecode.c:2255 #21 0x00455da2 in Feval (form=8378432) at eval.c:3599 #22 0x00452bcc in condition_case_1 (handlers=8179968, bfun=0x45557c <Feval>, bar g=8378432, hfun=0x452cf6 <run_condition_case_handlers>, harg=8420508) at eval.c: 1917 #23 0x004530e4 in condition_case_3 (bodyform=8378432, var=8420508, handlers=8179 968) at eval.c:1999 #24 0x00417b71 in execute_rare_opcode (stack_ptr=0x149f364, program_ptr=0x101e97 c5 "\210)[EMAIL PROTECTED] 36\037«\fÜ\016\037!«\006\212Y \210))\f.\a\207", opcode=Bcondition_case) at bytec ode.c:1134 #25 0x004161de in execute_optimized_program (program=0x101e9710 "Æ\016\036!ÇEÇ\2 11\211É\036 \030\032\031\034\035\eE\024EE!«\021\016\v:«\f\016\v\022II \n\"\021ª EI!«\027\016\016:[EMAIL PROTECTED] \n\"[EMAIL PROTECTED] 025Ñ\r!«\aO\r!\020ª\rO\rIO\r!\016!Z]\"\210Ñ\r!«\020I\b\n\"IV¬\017\tO\r!Wª\006O\r !IV«%Ñ\r!«\030\tO\r!W«\n\fO\r!\tZ^ª\r\fO\r!^ª\006\fO\r!^\024ª\024Ñ\r!«\aO\rI \"\ 210Ö\216xOU\217\210)[EMAIL PROTECTED]"..., stack_dept h=8, constants_data=0x808b10) at bytecode.c:515 #26 0x0045cef4 in funcall_compiled_function (fun=8427104, nargs=1, args=0x149f5d 8) at eval.c:3449 #27 0x00456de3 in Ffuncall (nargs=2, args=0x149f5d4) at eval.c:3881 #28 0x004164c3 in execute_optimized_program (program=0x10185a90 "\v?-&Æ\211\036\ 017\eÇ \034E\f\n\"\031É\035\f\022E\t!\025E\b!\210\r\026\020I\rIÉI$\211\020-\207" , stack_depth=6, constants_data=0x800410) at bytecode.c:609 #29 0x0045cef4 in funcall_compiled_function (fun=8443908, nargs=1, args=0x149f83 c) at eval.c:3449 #30 0x00456de3 in Ffuncall (nargs=2, args=0x149f838) at eval.c:3881 #31 0x0045820f in call1 (fn=8420724, arg0=6408196) at eval.c:4487 #32 0x0046cc59 in execute_internal_event (event=286251056) at event-stream.c:317 9 #33 0x0046f748 in Fdispatch_event (event=286251056) at event-stream.c:4565 #34 0x00423e6b in Fcommand_loop_1 () at cmdloop.c:569 #35 0x00423c50 in command_loop_1 (dummy=6408196) at cmdloop.c:488 #36 0x00452bcc in condition_case_1 (handlers=6408292, bfun=0x423c1e <command_loo p_1>, barg=6408196, hfun=0x4237b4 <cmd_error>, harg=6408196) at eval.c:1917 #37 0x00423938 in command_loop_3 () at cmdloop.c:251 #38 0x0042395b in command_loop_2 (dummy=6408196) at cmdloop.c:262 #39 0x0045260e in internal_catch (tag=6488596, func=0x423950 <command_loop_2>, a rg=6408196, threw=0x0, thrown_tag=0x0) at eval.c:1527 #40 0x00423a70 in initial_command_loop (load_me=6408196) at cmdloop.c:300 #41 0x0044bcc5 in xemacs_21_5_b14_i686_pc_cygwin (argc=1, argv=0x10028dc0, envp= 0x10025000, restart=0) at emacs.c:2403 #42 0x0044d30f in main (argc=1, argv=0x10028dc0, envp=0x10025000) at emacs.c:289 5 #43 0x610050c1 in dll_crt0_1() () at ../../../../cygwin-1.5.0-1/winsup/cygwin/dc rt0.cc:783 #44 0x61005688 in _dll_crt0 () at ../../../../cygwin-1.5.0-1/winsup/cygwin/dcrt0 .cc:913 #45 0x610056c8 in *_dll_crt0 (uptr=0x0) at ../../../../cygwin-1.5.0-1/winsup/cyg win/dcrt0.cc:926 #46 0x006038c2 in cygwin_crt0 () #47 0x0040103c in mainCRTStartup () #48 0x77ea847c in ProcessIdToSessionId () from /cygdrive/c/WINNT/system32/KERNEL 32.DLL (gdb) Here are the relevant lines from _csbrk: 184 else if (!VirtualAlloc (prebrk, (DWORD) sbs, MEM_COMMIT, PAGE_READWRIT E)) 185 { 186 malloc_printf ("couldn't commit memory for cygwin heap, %E"); 187 __seterrno (); 188 (char *) cygheap_max -= sbs; 189 return NULL; 190 } 191 192 return prebrk; 193 } I read about increasing the cygwin heap size, but I don't think that would help: the occurrence of the problem seems to be unrelated to the size of the executable as reported by the Windows Task Manager. In this case the executable is listed as 22,668K, but it often grows as big as 50,000K before crashing. I also read that sometimes a DLL can install itself in an inconvenient place in memory, causing VirtualAlloc to fail. If one of those issues is causing this, why would it always fail in exactly the same place? I would think other memory allocations would sometimes run into problems. In any case, some checking of the return value from cstrdup() at path.cc line 764 would be appreciated. What's the best way to track this down? -Pete -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/