SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1
Pete McCann
mccap@lucent.com
Thu Sep 4 16:14:00 GMT 2003
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«;\212I\r@!«.\r@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)\vA\211\023¬\217\016\036\211\023«\016\fO\v@!^\024\vA\211\023¬ôUU!\211\0
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:«\022\016\016@\016\016AIE\022II \n\"\021ª\005D\022I\021\v«s\v@\
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)\vA\211\023¬\217\016\036\211\023«\016\fO\v@!"..., 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/
More information about the Cygwin
mailing list