* SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 @ 2003-06-03 19:21 Pete McCann 2003-06-03 22:00 ` Christopher Faylor 0 siblings, 1 reply; 12+ messages in thread From: Pete McCann @ 2003-06-03 19:21 UTC (permalink / raw) To: cygwin Hi, I am experiencing occasional SEGVs with xemacs-21.5-b13 while running the VM mail reader. It happens after some unpredictable interval (couple of hours) whether or not I am actively browsing mail (often happens when I am away from my desk for lunch) I downloaded and compiled the cygwin-1.3.22-1 sources. Here is a stacktrace: (gdb) where #0 strlen () at ../../../../../../cygwin-1.3.22-1/newlib/libc/machine/i386/strl en.S:27 #1 0x61058e2a in conv_path_list_buf_size(char const*, bool) (path_list=0x16be76 0 "c:/cygwin/home/mccap", to_posix=false) at ../../../../cygwin-1.3.22-1/winsup/ cygwin/path.h:146 #2 0x61058f09 in cygwin_posix_to_win32_path_list_buf_size (path_list=0x16be760 "c:/cygwin/home/mccap") at ../../../../cygwin-1.3.22-1/winsup/cygwin/path.cc:354 5 #3 0x005da72f in readlink_and_correct_case (name=0x16be760 "c:/cygwin/home/mcca p", buf=0x16be3c0 "", size=258) at realpath.c:86 #4 0x005da0f7 in qxe_realpath (path=0x16be60c "C:\\cygwin\\home\\mccap\\Mail\\I DRM", resolved_path=0x16be760 "c:/cygwin/home/mccap") at realpath.c:298 #5 0x004d7e95 in Ffile_truename (filename=284683204, default_=7006212) at filei o.c:1368 #6 0x00411d46 in Fget_file_buffer (filename=284683204) at buffer.c:508 #7 0x0046b5a3 in Ffuncall (nargs=2, args=0x16be9d0) at eval.c:3843 #8 0x0041eb96 in execute_optimized_program (program=0x1028f810 "Æ\016\016!ÇE\01 6\016!!\032\211\036\017rfÉ E\034\035\f¬\e\r«\030\212\r@q\210\v«\n\016\020\n\230« \004\r@\024)\rA\025ªä\f*r@E\n!\031I\t\233\030É \035E\034\016\021«-\b«*\f¬'\r«$r\ r@q\210\v«\026\016\022\bk«\020I\v!«\vE\v!\tk«\004\r@\024)\rA\025ªO\f,*\207", sta ck_depth=5, constants_data=0x83c410) at bytecode.c:609 #9 0x00474221 in funcall_compiled_function (fun=8681144, nargs=1, args=0x16beb5 4) at opaque.h:36 #10 0x0046b4c6 in Ffuncall (nargs=2, args=0x16beb50) at eval.c:3881 #11 0x0041eb96 in execute_optimized_program (program=0x102dbc90 "A\b!r\025AA!«\b AA\b!!r\tAÄ!-\004Ä\b!\207", stack_depth=3, constants_data=0x102bd250) at bytecod e.c:609 #12 0x00474221 in funcall_compiled_function (fun=271396316, nargs=1, args=0x16be cc8) at opaque.h:36 #13 0x0046b4c6 in Ffuncall (nargs=2, args=0x16becc4) at eval.c:3881 #14 0x0041eb96 in execute_optimized_program (program=0x105af610 "\0161?\205!\001 Æ Ç\0162\211E\211\211\211\211\211\211\211\211\032\030\0365\035\036.\036/\034\e\0 366\0367\0368\0361\031Ép!¬\036\0162«\vEEIIp!\"!¬\020IIIp!\"\210DÑ!\210E\202U", s tack_depth=14, constants_data=0x10319810) at bytecode.c:609 #15 0x00474221 in funcall_compiled_function (fun=271701644, nargs=1, args=0x16be e64) at opaque.h:36 #16 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bee60) at eval.c:3881 #17 0x0041eb96 in execute_optimized_program (program=0x105aa650 "\t«\005AÄ!\210\ bÅ=«\bÆ\nÇ\211E$\207É\n!\207", stack_depth=5, constants_data=0x1030b790) at byte code.c:609 #18 0x00474221 in funcall_compiled_function (fun=271701600, nargs=1, args=0x16be fe4) at opaque.h:36 #19 0x0046b4c6 in Ffuncall (nargs=2, args=0x16befe0) at eval.c:3881 #20 0x0041eb96 in execute_optimized_program (program=0x10273110 "Æ\026\030\v"«\0 27\f«\rÇ\fEÉ \v\"\v#\210ª\026E\n\v\"\210ª\017\f«\aE\f!\210ª\006E\nÆ\"\210I Æ\031 \035I ¬O\r«L\212I\r@!«?\r@q\210\016\031I=«5D\211\021«0\016\032¬,\016\e¬(\016\034 ¬$Ñ ¬\v\b«\bOO \b\"¬\026OÆ!«\021\016\035¬\nO «\006Ö \210ª\004x \210)\rA\025ª_\t? -\021\r?-\r\f«\006E\f!ª\005E\nÆ\"*\207ï_-_l±+\020ï_-_", stack_depth=5, constants _data=0x10319e10) at bytecode.c:609 #21 0x00474221 in funcall_compiled_function (fun=271700500, nargs=0, args=0x16bf 164) at opaque.h:36 #22 0x0046b4c6 in Ffuncall (nargs=1, args=0x16bf160) at eval.c:3881 #23 0x0041eb96 in execute_optimized_program (program=0x16bf1d4 "Æ \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\2070D\206", stack_depth=5, constants_data=0x888690) at bytecode.c:609 #24 0x00420795 in Fbyte_code (instructions=8827156, constants=8947328, stack_dep th=11) at lisp.h:2588 #25 0x0046ac30 in Feval (form=8982592) at eval.c:3602 #26 0x00467c41 in condition_case_1 (handlers=8829184, bfun=0x469da0 <Feval>, bar g=8982592, hfun=0x473dd0 <run_condition_case_handlers>, harg=8922580) at eval.c: 1917 #27 0x00467f62 in condition_case_3 (bodyform=8982592, var=8922580, handlers=8829 184) at eval.c:1999 #28 0x0041fb9d in execute_rare_opcode (stack_ptr=0x16bf5a8, program_ptr=0x101819 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 #29 0x0041e97f in execute_optimized_program (program=0x10181910 "Æ\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=0x883b10) at bytecode.c:515 #30 0x00474221 in funcall_compiled_function (fun=8924768, nargs=1, args=0x16bf73 4) at opaque.h:36 #31 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bf730) at eval.c:3881 #32 0x0041eb96 in execute_optimized_program (program=0x1019ba90 "\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=0x888410) at bytecode.c:609 #33 0x00474221 in funcall_compiled_function (fun=9035780, nargs=1, args=0x16bf8b c) at opaque.h:36 #34 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bf8b8) at eval.c:3881 #35 0x0046c680 in call1 (fn=8922796, arg0=7006212) at eval.c:4487 #36 0x00483ac0 in execute_internal_event (event=8370620) at events.h:880 #37 0x00485583 in Fdispatch_event (event=8370620) at event-stream.c:4565 #38 0x00430517 in Fcommand_loop_1 () at cmdloop.c:569 #39 0x00467c41 in condition_case_1 (handlers=7006308, bfun=0x430d40 <command_loo p_1>, barg=7006212, hfun=0x430da0 <cmd_error>, harg=7006212) at eval.c:1917 #40 0x00430ffa in command_loop_2 (dummy=7006212) at cmdloop.c:251 #41 0x00467aa9 in internal_catch (tag=7086612, func=0x430fa0 <command_loop_2>, a rg=7006212, threw=0x0, thrown_tag=0x0) at eval.c:1527 #42 0x0043095b in initial_command_loop (load_me=7006212) at cmdloop.c:300 #43 0x00462916 in xemacs_21_5_b13_i686_pc_cygwin (argc=1, argv=0x10027dc0, envp= 0x10025000, restart=0) at emacs.c:2403 #44 0x00463bc4 in main (argc=1, argv=0x10027dc0, envp=0x10025000) at emacs.c:289 5 #45 0x61007678 in dll_crt0_1() () at ../../../../cygwin-1.3.22-1/winsup/cygwin/d crt0.cc:781 #46 0x6100795d in _dll_crt0 () at ../../../../cygwin-1.3.22-1/winsup/cygwin/dcrt 0.cc:911 #47 0x00694fe2 in cygwin_crt0 () #48 0x0040103c in mainCRTStartup () #49 0x77ea847c in ProcessIdToSessionId () from /cygdrive/c/WINNT/system32/KERNEL 32.DLL So, the string being passed in looks fine: "c:/cygwin/home/mccap" and it is null terminated. However, here is the contents of the class path_conv pc variable: (gdb) print pc $23 = {fileattr = 16, fs = { name = "NTFS\000âk\001§\031\005a n\ra\\åk\001\000\000\000\000d\000\000\000På k\001 ßk\001C:\\", '\0' <repeats 125 times>, "c:\\", '\0' <repeats 92 times>, root_dir = "C:\\", '\0' <repeats 256 times>, flags = 459007, serial = 2080954035, sym_opt = 64, is_remote_drive = 0, drive_type = 3}, path_flags = 2214592522, known_suffix = 0x0, error = 0, devn = 16, unit = 0, case_clash = 0, normalized_path = 0x0, path = "C:\\cygwin\\home\\mccap\\Mail\000\000\000\000\000\000\000\000\000\000: \006àk\001\006àk\001,ßk\001n9\005a\214ßk\001\006àk\001:\000\000\000/cygpék\001P\ 022\233\000\000\000\000\000Oßk\001\027àk\001\020ák\001\230ak\001U_]\000Aßk\001"U k\001\001\000\000\000`\217\005apèk\001¬Uk\001\001\000\000\000'ùm\000\200A}\000\2 00¿\027\020\200AH\020\\\000c\000pék\001P\022\233\000\000\000\000\000ÿÿÿÿ1\000\00 0\000\000\000\000\000\\\000h\000$àk\001Xàk\001Aak\001xàk\001\t²d\000$àk\001"...} I don't understand why "path" is filled with junk. Also, note that normalized_path is NULL, which I think is the culprit with respect to strlen. Perhaps it is this code: /* 100: slop */en = (to_posix size = strlen (path_list)unt_table->mount[i].posix_pathlen + (num_elms * max_mount_path_len)>mount[i].native_pathlen); + (nrel * strlen (to_posix ? pc.get_win32 () : pc.normalized_path)) + 100; return size; which is causing the problem. If I understand correctly, this should be accessing pc.normalized_path (to_posix = false). I posted this question to the xemacs list (with less debugging info) and didn't get much help, other than a suggestion that xemacs might be using too much alloca'd memory which is corrupting the stack. Perhaps the path_conv structure is too big and I am running out of stack space? Or could there be some other bug at work here? I tried looking at the path_conv constructor but got lost in the huge check() function there. Any suggestions on what to try next? -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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 2003-06-03 19:21 SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 Pete McCann @ 2003-06-03 22:00 ` Christopher Faylor 2003-06-04 22:03 ` Pete McCann 0 siblings, 1 reply; 12+ messages in thread From: Christopher Faylor @ 2003-06-03 22:00 UTC (permalink / raw) To: cygwin On Tue, Jun 03, 2003 at 02:21:30PM -0500, Pete McCann wrote: >I don't understand why "path" is filled with junk. Also, note that >normalized_path is NULL, which I think is the culprit with respect to >strlen. Perhaps it is this code: > > > /* 100: slop */en = (to_posix > size = strlen (path_list)unt_table->mount[i].posix_pathlen > + (num_elms * max_mount_path_len)>mount[i].native_pathlen); > + (nrel * strlen (to_posix ? pc.get_win32 () : pc.normalized_path)) > + 100; > return size; > >which is causing the problem. If I understand correctly, this >should be accessing pc.normalized_path (to_posix = false). Very nice analysis. Much appreciated. I don't have much time to look into this right now, but it sure seems like a test in conv_path_list_buf_size is reversed. If so, it's incredible that this ever worked. Does the following fix the problem? cgf Index: path.cc =================================================================== RCS file: /cvs/src/src/winsup/cygwin/path.cc,v retrieving revision 1.254 diff -u -p -r1.254 path.cc --- path.cc 30 May 2003 23:43:24 -0000 1.254 +++ path.cc 3 Jun 2003 21:59:02 -0000 @@ -3551,7 +3551,7 @@ conv_path_list_buf_size (const char *pat /* 100: slop */ size = strlen (path_list) + (num_elms * max_mount_path_len) - + (nrel * strlen (to_posix ? pc.get_win32 () : pc.normalized_path)) + + (nrel * strlen (to_posix ? pc.normalized_path : pc.get_win32 ())) + 100; return size; } -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 2003-06-03 22:00 ` Christopher Faylor @ 2003-06-04 22:03 ` Pete McCann 2003-06-04 23:01 ` Christopher Faylor 0 siblings, 1 reply; 12+ messages in thread From: Pete McCann @ 2003-06-04 22:03 UTC (permalink / raw) To: cygwin Hi, Christopher, Thanks for the response - see below. Christopher Faylor writes: > Does the following fix the problem? > > cgf > > Index: path.cc > =================================================================== > RCS file: /cvs/src/src/winsup/cygwin/path.cc,v > retrieving revision 1.254 > diff -u -p -r1.254 path.cc > --- path.cc 30 May 2003 23:43:24 -0000 1.254 > +++ path.cc 3 Jun 2003 21:59:02 -0000 > @@ -3551,7 +3551,7 @@ conv_path_list_buf_size (const char *pat > /* 100: slop */ > size = strlen (path_list) > + (num_elms * max_mount_path_len) > - + (nrel * strlen (to_posix ? pc.get_win32 () : pc.normalized_path)) > + + (nrel * strlen (to_posix ? pc.normalized_path : pc.get_win32 ())) > + 100; > return size; > } It seems to fix the immediate problem, but now I have another SEGV somewhere else. This also seems to happen intermittently. Here is the stacktrace: (gdb) where #0 hash_path_name(unsigned long, char const*) (hash=0, name=0x0) at ../../../.. /cygwin-1.3.22-1/winsup/cygwin/path.cc:3191 #1 0x610840ab in stat_worker(char const*, __stat64*, int, path_conv*) (name=0x1 6beb54 "/home/mccap/Mail/INBOX", buf=0x16bead0, nofollow=23849768, pc=0x0) at .. /../../../cygwin-1.3.22-1/winsup/cygwin/fhandler.h:294 #2 0x61084191 in stat64 (name=0x16beb54 "/home/mccap/Mail/INBOX", buf=0x16bead0 ) at ../../../../cygwin-1.3.22-1/winsup/cygwin/syscalls.cc:1121 #3 0x6108429e in stat (name=0x16beb54 "/home/mccap/Mail/INBOX", buf=0x16bebb0) at ../../../../cygwin-1.3.22-1/winsup/cygwin/syscalls.cc:1128 #4 0x0064db79 in qxe_stat (path=0x103b4368 "/home/mccap/Mail/INBOX", buf=0x16be bb0) at sysdep.c:3124 #5 0x004e2f18 in Fverify_visited_file_modtime (buffer=270010880) at lisp.h:2267 #6 0x0046b5a3 in Ffuncall (nargs=2, args=0x16becc0) at eval.c:3843 #7 0x0041eb96 in execute_optimized_program (program=0x1070fc10 "\0161?\205!\001 Æ Ç\0162\211E\211\211\211\211\211\211\211\211\032\030\0365\035\036.\036/\034\e\0 366\0367\0368\0361\031Ép!¬\036\0162«\vEEIIp!\"!¬\020IIIp!\"\210DÑ!\210E\202U", s tack_depth=14, constants_data=0x1032d810) at bytecode.c:609 #8 0x00474221 in funcall_compiled_function (fun=271785612, nargs=1, args=0x16be e64) at opaque.h:36 #9 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bee60) at eval.c:3881 #10 0x0041eb96 in execute_optimized_program (program=0x107179d0 "\t«\005AÄ!\210\ bÅ=«\bÆ\nÇ\211E$\207É\n!\207", stack_depth=5, constants_data=0x10261350) at byte code.c:609 #11 0x00474221 in funcall_compiled_function (fun=271785568, nargs=1, args=0x16be fe4) at opaque.h:36 #12 0x0046b4c6 in Ffuncall (nargs=2, args=0x16befe0) at eval.c:3881 #13 0x0041eb96 in execute_optimized_program (program=0x101e9310 "Æ\026\030\v"«\0 27\f«\rÇ\fEÉ \v\"\v#\210ª\026E\n\v\"\210ª\017\f«\aE\f!\210ª\006E\nÆ\"\210I Æ\031 \035I ¬O\r«L\212I\r@!«?\r@q\210\016\031I=«5D\211\021«0\016\032¬,\016\e¬(\016\034 ¬$Ñ ¬\v\b«\bOO \b\"¬\026OÆ!«\021\016\035¬\nO «\006Ö \210ª\004x \210)\rA\025ª_\t? -\021\r?-\r\f«\006E\f!ª\005E\nÆ\"*\207ï_-_", stack_depth=5, constants_data=0x102 8c110) at bytecode.c:609 #14 0x00474221 in funcall_compiled_function (fun=271784468, nargs=0, args=0x16bf 164) at opaque.h:36 #15 0x0046b4c6 in Ffuncall (nargs=1, args=0x16bf160) at eval.c:3881 #16 0x0041eb96 in execute_optimized_program (program=0x16bf1d4 "Æ \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\2070D\206", stack_depth=5, constants_data=0x888690) at bytecode.c:609 #17 0x00420795 in Fbyte_code (instructions=8827156, constants=8947328, stack_dep th=11) at lisp.h:2588 #18 0x0046ac30 in Feval (form=8982592) at eval.c:3602 #19 0x00467c41 in condition_case_1 (handlers=8829184, bfun=0x469da0 <Feval>, bar g=8982592, hfun=0x473dd0 <run_condition_case_handlers>, harg=8922580) at eval.c: 1917 #20 0x00467f62 in condition_case_3 (bodyform=8982592, var=8922580, handlers=8829 184) at eval.c:1999 #21 0x0041fb9d in execute_rare_opcode (stack_ptr=0x16bf5a8, 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 #22 0x0041e97f 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=0x883b10) at bytecode.c:515 #23 0x00474221 in funcall_compiled_function (fun=8924768, nargs=1, args=0x16bf73 4) at opaque.h:36 #24 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bf730) at eval.c:3881 #25 0x0041eb96 in execute_optimized_program (program=0x10182b10 "\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=0x888410) at bytecode.c:609 #26 0x00474221 in funcall_compiled_function (fun=9035780, nargs=1, args=0x16bf8b c) at opaque.h:36 #27 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bf8b8) at eval.c:3881 #28 0x0046c680 in call1 (fn=8922796, arg0=7006212) at eval.c:4487 #29 0x00483ac0 in execute_internal_event (event=8178284) at events.h:880 #30 0x00485583 in Fdispatch_event (event=8178284) at event-stream.c:4565 #31 0x00430517 in Fcommand_loop_1 () at cmdloop.c:569 #32 0x00467c41 in condition_case_1 (handlers=7006308, bfun=0x430d40 <command_loo p_1>, barg=7006212, hfun=0x430da0 <cmd_error>, harg=7006212) at eval.c:1917 #33 0x00430ffa in command_loop_2 (dummy=7006212) at cmdloop.c:251 #34 0x00467aa9 in internal_catch (tag=7086612, func=0x430fa0 <command_loop_2>, a rg=7006212, threw=0x0, thrown_tag=0x0) at eval.c:1527 #35 0x0043095b in initial_command_loop (load_me=7006212) at cmdloop.c:300 #36 0x00462916 in xemacs_21_5_b13_i686_pc_cygwin (argc=1, argv=0x10028dc0, envp= 0x10025000, restart=0) at emacs.c:2403 #37 0x00463bc4 in main (argc=1, argv=0x10028dc0, envp=0x10025000) at emacs.c:289 5 #38 0x61007678 in dll_crt0_1() () at ../../../../cygwin-1.3.22-1/winsup/cygwin/d crt0.cc:781 #39 0x6100795d in _dll_crt0 () at ../../../../cygwin-1.3.22-1/winsup/cygwin/dcrt 0.cc:911 #40 0x00694fe2 in cygwin_crt0 () #41 0x0040103c in mainCRTStartup () #42 0x77ea847c in ProcessIdToSessionId () from /cygdrive/c/WINNT/system32/KERNEL 32.DLL (gdb) The code in question is: unsigned long __stdcall hash_path_name (unsigned long hash, const char *name) { if (!*name) return hash; ... Note that name = 0x0. Did this code mean to say "if (!name)"? Or maybe, "if (!name || !*name)"? Also, there is code in syscall.cc (stat_worker()) that looks similar to what we saw before (it accesses fh->get_win32_name()): if (!res && fh->get_device () != FH_SOCKET) { if (!buf->st_ino) buf->st_ino = hash_path_name (0, fh->get_win32_name ()); if (!buf->st_dev) buf->st_dev = (fh->get_device () << 16) | fh->get_unit (); if (!buf->st_rdev) buf->st_rdev = buf->st_dev; } Is this another case where we should be using fh->normalized_path? I'll make the !name change and report back if I see any more crashes... -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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 2003-06-04 22:03 ` Pete McCann @ 2003-06-04 23:01 ` Christopher Faylor 2003-06-05 19:26 ` Pete McCann 0 siblings, 1 reply; 12+ messages in thread From: Christopher Faylor @ 2003-06-04 23:01 UTC (permalink / raw) To: cygwin On Wed, Jun 04, 2003 at 05:03:45PM -0500, Pete McCann wrote: >Thanks for the response - see below. >Christopher Faylor writes: >> Does the following fix the problem? >> >> cgf >> >> Index: path.cc >> =================================================================== >> RCS file: /cvs/src/src/winsup/cygwin/path.cc,v >> retrieving revision 1.254 >> diff -u -p -r1.254 path.cc >> --- path.cc 30 May 2003 23:43:24 -0000 1.254 >> +++ path.cc 3 Jun 2003 21:59:02 -0000 >> @@ -3551,7 +3551,7 @@ conv_path_list_buf_size (const char *pat >> /* 100: slop */ >> size = strlen (path_list) >> + (num_elms * max_mount_path_len) >> - + (nrel * strlen (to_posix ? pc.get_win32 () : pc.normalized_path)) >> + + (nrel * strlen (to_posix ? pc.normalized_path : pc.get_win32 ())) >> + 100; >> return size; >> } > >It seems to fix the immediate problem, but now I have another SEGV >somewhere else. This also seems to happen intermittently. Here is >the stacktrace: > >(gdb) where >#0 hash_path_name(unsigned long, char const*) (hash=0, name=0x0) at ../../../.. >/cygwin-1.3.22-1/winsup/cygwin/path.cc:3191 >#1 0x610840ab in stat_worker(char const*, __stat64*, int, path_conv*) (name=0x1 >6beb54 "/home/mccap/Mail/INBOX", buf=0x16bead0, nofollow=23849768, pc=0x0) at .. >/../../../cygwin-1.3.22-1/winsup/cygwin/fhandler.h:294 >#2 0x61084191 in stat64 (name=0x16beb54 "/home/mccap/Mail/INBOX", buf=0x16bead0 >) at ../../../../cygwin-1.3.22-1/winsup/cygwin/syscalls.cc:1121 >#3 0x6108429e in stat (name=0x16beb54 "/home/mccap/Mail/INBOX", buf=0x16bebb0) >at ../../../../cygwin-1.3.22-1/winsup/cygwin/syscalls.cc:1128 >#4 0x0064db79 in qxe_stat (path=0x103b4368 "/home/mccap/Mail/INBOX", buf=0x16be >bb0) at sysdep.c:3124 >#5 0x004e2f18 in Fverify_visited_file_modtime (buffer=270010880) at lisp.h:2267 > >#6 0x0046b5a3 in Ffuncall (nargs=2, args=0x16becc0) at eval.c:3843 >#7 0x0041eb96 in execute_optimized_program (program=0x1070fc10 "\0161?\205!\001 >? ?\0162\211E\211\211\211\211\211\211\211\211\032\030\0365\035\036.\036/\034\e\0 >366\0367\0368\0361\031?p!?\036\0162?\vEEIIp!\"!?\020IIIp!\"\210D?!\210E\202U", s >tack_depth=14, constants_data=0x1032d810) at bytecode.c:609 >#8 0x00474221 in funcall_compiled_function (fun=271785612, nargs=1, args=0x16be >e64) at opaque.h:36 >#9 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bee60) at eval.c:3881 >#10 0x0041eb96 in execute_optimized_program (program=0x107179d0 "\t?\005A?!\210\ >b?=?\b?\n?\211E$\207?\n!\207", stack_depth=5, constants_data=0x10261350) at byte >code.c:609 >#11 0x00474221 in funcall_compiled_function (fun=271785568, nargs=1, args=0x16be >fe4) at opaque.h:36 >#12 0x0046b4c6 in Ffuncall (nargs=2, args=0x16befe0) at eval.c:3881 >#13 0x0041eb96 in execute_optimized_program (program=0x101e9310 "?\026\030\v"?\0 >27\f?\r?\fE? \v\"\v#\210?\026E\n\v\"\210?\017\f?\aE\f!\210?\006E\n?\"\210I ?\031 >\035I ?O\r?L\212I\r@!??\r@q\210\016\031I=?5D\211\021?0\016\032?,\016\e?(\016\034 >?$? ?\v\b?\bOO \b\"?\026O?!?\021\016\035?\nO ?\006? \210?\004x \210)\rA\025?_\t? >-\021\r?-\r\f?\006E\f!?\005E\n?\"*\207?_-_", stack_depth=5, constants_data=0x102 >8c110) at bytecode.c:609 >#14 0x00474221 in funcall_compiled_function (fun=271784468, nargs=0, args=0x16bf >164) at opaque.h:36 >#15 0x0046b4c6 in Ffuncall (nargs=1, args=0x16bf160) at eval.c:3881 >#16 0x0041eb96 in execute_optimized_program (program=0x16bf1d4 "? \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\2070D\206", stack_depth=5, constants_data=0x888690) at > bytecode.c:609 >#17 0x00420795 in Fbyte_code (instructions=8827156, constants=8947328, stack_dep >th=11) at lisp.h:2588 >#18 0x0046ac30 in Feval (form=8982592) at eval.c:3602 >#19 0x00467c41 in condition_case_1 (handlers=8829184, bfun=0x469da0 <Feval>, bar >g=8982592, hfun=0x473dd0 <run_condition_case_handlers>, harg=8922580) at eval.c: >1917 >#20 0x00467f62 in condition_case_3 (bodyform=8982592, var=8922580, handlers=8829 >184) at eval.c:1999 >#21 0x0041fb9d in execute_rare_opcode (stack_ptr=0x16bf5a8, 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 >#22 0x0041e97f 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=0x883b10) at bytecode.c:515 >#23 0x00474221 in funcall_compiled_function (fun=8924768, nargs=1, args=0x16bf73 >4) at opaque.h:36 >#24 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bf730) at eval.c:3881 >#25 0x0041eb96 in execute_optimized_program (program=0x10182b10 "\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=0x888410) at bytecode.c:609 >#26 0x00474221 in funcall_compiled_function (fun=9035780, nargs=1, args=0x16bf8b >c) at opaque.h:36 >#27 0x0046b4c6 in Ffuncall (nargs=2, args=0x16bf8b8) at eval.c:3881 >#28 0x0046c680 in call1 (fn=8922796, arg0=7006212) at eval.c:4487 >#29 0x00483ac0 in execute_internal_event (event=8178284) at events.h:880 >#30 0x00485583 in Fdispatch_event (event=8178284) at event-stream.c:4565 >#31 0x00430517 in Fcommand_loop_1 () at cmdloop.c:569 >#32 0x00467c41 in condition_case_1 (handlers=7006308, bfun=0x430d40 <command_loo >p_1>, barg=7006212, hfun=0x430da0 <cmd_error>, harg=7006212) at eval.c:1917 >#33 0x00430ffa in command_loop_2 (dummy=7006212) at cmdloop.c:251 >#34 0x00467aa9 in internal_catch (tag=7086612, func=0x430fa0 <command_loop_2>, a >rg=7006212, threw=0x0, thrown_tag=0x0) at eval.c:1527 >#35 0x0043095b in initial_command_loop (load_me=7006212) at cmdloop.c:300 >#36 0x00462916 in xemacs_21_5_b13_i686_pc_cygwin (argc=1, argv=0x10028dc0, envp= >0x10025000, restart=0) at emacs.c:2403 >#37 0x00463bc4 in main (argc=1, argv=0x10028dc0, envp=0x10025000) at emacs.c:289 >5 >#38 0x61007678 in dll_crt0_1() () at ../../../../cygwin-1.3.22-1/winsup/cygwin/d >crt0.cc:781 >#39 0x6100795d in _dll_crt0 () at ../../../../cygwin-1.3.22-1/winsup/cygwin/dcrt >0.cc:911 >#40 0x00694fe2 in cygwin_crt0 () >#41 0x0040103c in mainCRTStartup () >#42 0x77ea847c in ProcessIdToSessionId () from /cygdrive/c/WINNT/system32/KERNEL >32.DLL >(gdb) > > >The code in question is: > > unsigned long __stdcall > hash_path_name (unsigned long hash, const char *name) > { > if (!*name) > return hash; >... > >Note that name = 0x0. Did this code mean to say "if (!name)"? Or >maybe, "if (!name || !*name)"? No. This should never be null but it can be empty. >Also, there is code in syscall.cc (stat_worker()) that looks similar >to what we saw before (it accesses fh->get_win32_name()): > > if (!res && fh->get_device () != FH_SOCKET) > { > if (!buf->st_ino) > buf->st_ino = hash_path_name (0, fh->get_win32_name ()); > if (!buf->st_dev) > buf->st_dev = (fh->get_device () << 16) | fh->get_unit (); > if (!buf->st_rdev) > buf->st_rdev = buf->st_dev; > } > >Is this another case where we should be using fh->normalized_path? No. get_win32_name is correct. >I'll make the !name change and report back if I see any more crashes... If that works it is not a fix. It just masks some other problem. cgf -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 2003-06-04 23:01 ` Christopher Faylor @ 2003-06-05 19:26 ` Pete McCann 2003-06-05 19:42 ` Christopher Faylor 0 siblings, 1 reply; 12+ messages in thread From: Pete McCann @ 2003-06-05 19:26 UTC (permalink / raw) To: cygwin cgf writes: > >Note that name = 0x0. Did this code mean to say "if (!name)"? Or > >maybe, "if (!name || !*name)"? > > No. This should never be null but it can be empty. Ok. > >Also, there is code in syscall.cc (stat_worker()) that looks similar > >to what we saw before (it accesses fh->get_win32_name()): > > > > if (!res && fh->get_device () != FH_SOCKET) > > { > > if (!buf->st_ino) > > buf->st_ino = hash_path_name (0, fh->get_win32_name ()); > > if (!buf->st_dev) > > buf->st_dev = (fh->get_device () << 16) | fh->get_unit (); > > if (!buf->st_rdev) > > buf->st_rdev = buf->st_dev; > > } > > > >Is this another case where we should be using fh->normalized_path? > > No. get_win32_name is correct. Ok. > >I'll make the !name change and report back if I see any more crashes... > > If that works it is not a fix. It just masks some other problem. Ok, well I left things as-is. Here is a dump of what I think are the important variables after another crash (happens in same place): (gdb) up #1 0x610840ab in stat_worker(char const*, __stat64*, int, path_conv*) (name=0x1 6beb54 "/home/mccap/Mail/INBOX", buf=0x16bead0, nofollow=23849768, pc=0x0) at .. /../../../cygwin-1.3.22-1/winsup/cygwin/fhandler.h:294 294 const char *get_win32_name () { return win32_path_name; } (gdb) print pc $1 = (path_conv *) 0x16be730 (gdb) print *pc $2 = {fileattr = 544, fs = { name = "NTFS\000\000\000\000Eæk\001\001\001\001\001èçk\001ôdûw\210\026owÿÿÿÿ oçk\001\035\226üw\000\000l\001`\000\000@,)n\001\000\000\000\000E\225üw4\000\000A ", '\0' <repeats 16 times>, "\001\000\000\000Oèk\001\0371K\000O\216w\000\001\000 \000\000èèk\001\0371K\000O\216w\000üçk\001\000\000\000\000L\210éwOçk\001\200åk\0 01\000\000\000\000\000ìy\177\002\000\000\000\000\000l\001\000ìy\177\000\000\n\00 0O\020owB\000\000\000\001\000\000\000pík\001E\225üwôçk\0014\000\000A2»úw4\000\00 0Atèk\001\034\202èw\002\000\000\000E\225"..., root_dir = "C:\\", '\0' <repeats 256 times>, flags = 459007, serial = 2080954035, sym_opt = 64, is_remote_drive = 0, drive_type = 3}, path_flags = 2214592522, known_suffix = 0x0, error = 0, devn = 16, unit = 0, case_clash = 0, normalized_path = 0x0, path = "C:\\cygwin\\home\\mccap\\Mail\\INBOX\000YOG\000d$\207\020\000\000\000\ 000\000\000\000\000\000\001\000\000\001\001\000\000\001\000\000\000D\004\231\000 /\000\000\000¼uc\000/\000\000\000Oék\0011_F\000d$\207\020º\205U\020I\205U\020/\0 00\000\000/\000\000\000\001\000\000\000\bêk\001\210YF\000/\000\000\000\005", '\0 ' <repeats 11 times>, "\020ík\001\024êk\001\001\000\000\000\000\000\000\000/\000 \000\0001\205U\020xêk\001ßO`\000/\000\000\000\004èj\000\000\000\000\000,\205U\02 0\026", '\0' <repeats 11 times>, "\026\000\000\000O\216w\000\000\000"...} (gdb) print fh $3 = (class fhandler_base *) 0x61600bb8 (gdb) print *fh warning: can't find linker symbol for virtual table for `fhandler_base' value $4 = {_vptr$fhandler_base = 0x610d6100, status = 3221225488, access = 0, io_handle = 0x0, namehash = 0, openflags = 0, rabuf = 0x0, ralen = 0, raixget = 0, raixput = 0, rabuflen = 0, unix_path_name = 0x0, win32_path_name = 0x0, open_status = 0, read_state = 0x0} (gdb) print nofollow $5 = 23849768 (gdb) print name $6 = 0x16beb54 "/home/mccap/Mail/INBOX" (gdb) print buf $7 = (__stat64 *) 0x16bead0 (gdb) print *buf $8 = {st_dev = 2080954035, st_ino = 0, st_mode = 32768, st_nlink = 1, st_uid = 4294967295, st_gid = 4294967295, st_rdev = 0, st_size = 1484364, st_atim = {tv_sec = 1054834524, tv_nsec = 169038400}, st_mtim = { tv_sec = 1054834524, tv_nsec = 169038400}, st_ctim = {tv_sec = 1054834523, tv_nsec = 898649600}, st_blksize = 1024, st_blocks = 1450, st_spare4 = {0, 0}} (gdb) print nofollow $9 = 23849768 (gdb) Not sure what the warning about "can't find linker symbol for virtual table..." means; is my compile messed up somehow? Anyway, note that the class fhandler_base definitely has win32_path_name set to NULL. This is what is being accessed by fh->get_win32_name() code above and passed in to hash_path_name. All the arguments coming in to stat_worker look ok except this variable "nofollow" which looks suspicious: 23849768. Was this intended for use as a boolean flag? The caller seemed to pass in 0. I note that all calls to stat_worker have 3 arguments whereas the prototype has 4 formal arguments with the last one defaulted: from winsup.h: int __stdcall stat_worker (const char *name, struct __stat64 *buf, int nofollow, path_conv *pc = NULL) __attribute__ ((regparm (3))); So, nofollow and pc should have both been 0 coming in (although I see pc getting reset to &real_path). Is this a case of stack corruption somewhere? Some bad interaction with the regparm() attribute? Could the debugger be getting confused? -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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 2003-06-05 19:26 ` Pete McCann @ 2003-06-05 19:42 ` Christopher Faylor 2003-09-04 16:14 ` Pete McCann 0 siblings, 1 reply; 12+ messages in thread From: Christopher Faylor @ 2003-06-05 19:42 UTC (permalink / raw) To: cygwin On Thu, Jun 05, 2003 at 02:25:56PM -0500, Pete McCann wrote: >int __stdcall stat_worker (const char *name, struct __stat64 *buf, int nofollow, > path_conv *pc = NULL) __attribute__ ((regparm (3))); > >So, nofollow and pc should have both been 0 coming in (although I see >pc getting reset to &real_path). Is this a case of stack corruption >somewhere? Maybe. Do you see the same thing with non-failing cases, though. >Some bad interaction with the regparm() attribute? Unlikely. >Could the debugger be getting confused? Very likely. Are you building cygwin with just '-g' and not with '-O2 -g'? Adding optimization can certainly cause confusion. cgf -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 2003-06-05 19:42 ` Christopher Faylor @ 2003-09-04 16:14 ` Pete McCann 2003-09-09 20:33 ` SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 Pete McCann 0 siblings, 1 reply; 12+ messages in thread From: Pete McCann @ 2003-09-04 16:14 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 2003-09-04 16:14 ` Pete McCann @ 2003-09-09 20:33 ` Pete McCann 2003-09-10 8:58 ` Corinna Vinschen 2003-09-12 19:42 ` Pete McCann 0 siblings, 2 replies; 12+ messages in thread From: Pete McCann @ 2003-09-09 20:33 UTC (permalink / raw) To: cygwin Hi, After some more hunting, I now understand there is a difference between the cygwin heap and the user heap. My problem is that I'm running out of cygwin heap: (gdb) where #0 _csbrk(int) (sbs=40) at ../../../../cygwin-snapshot-20030904-1/winsup/cygwin /cygheap.cc:190 #1 0x61002354 in _cmalloc(unsigned) (size=28) at ../../../../cygwin-snapshot-20 030904-1/winsup/cygwin/cygheap.cc:235 #2 0x610024dd in cmalloc (x=HEAP_STR, n=20) at ../../../../cygwin-snapshot-2003 0904-1/winsup/cygwin/cygheap.cc:309 #3 0x61002839 in cstrdup (s=0x149d6d0 "/home/mccap/cygbugs") at ../../../../cyg win-snapshot-20030904-1/winsup/cygwin/cygheap.cc:365 #4 0x61057d12 in path_conv::check(char const*, unsigned, suffix_info const*) (t his=0x149d860, src=0x6105957c ".", opt=176, suffixes=0x0) at ../../../../cygwin- snapshot-20030904-1/winsup/cygwin/path.cc:764 #5 0x610dec0d in path_conv::path_conv(char const*, unsigned, suffix_info const* ) (this=0x149d860, src=0x6105957c ".", opt=144, suffixes=0x0) at ../../../../cyg win-snapshot-20030904-1/winsup/cygwin/path.h:141 #6 0x6105fa70 in conv_path_list_buf_size(char const*, bool) (path_list=0x149e2e 0 "c:/cygwin/home/mccap", to_posix=false) at ../../../../cygwin-snapshot-2003090 4-1/winsup/cygwin/path.cc:3627 #7 0x6105fce9 in cygwin_posix_to_win32_path_list_buf_size (path_list=0x149e2e0 "c:/cygwin/home/mccap") at ../../../../cygwin-snapshot-20030904-1/winsup/cygwin/ path.cc:3668 #8 0x005707d6 in readlink_and_correct_case (name=0x149e2e0 "c:/cygwin/home/mcca p", buf=0x149dfb0 "", size=258) at realpath.c:86 #9 0x00571663 in qxe_realpath (path=0x149e0e4 "\\Mail\\MWIF", resolved_path=0x1 49e2e0 "c:/cygwin/home/mccap") at realpath.c:298 #10 0x0049c509 in Ffile_truename (filename=270244004, default_=6408196) at filei o.c:1368 ... (gdb) print prebrk $3 = (void *) 0x6189dfe4 (gdb) print sbs $4 = 40 (gdb) print prebrka $5 = (void *) 0x6189d000 (gdb) print cygheap_max $6 = (void *) 0x6189dfe4 Note the #define in cygheap.h: #define CYGHEAPSIZE (sizeof (init_cygheap) + (20000 * sizeof (fhandler_union)) + (5 * 65536)) (gdb) print sizeof (init_cygheap) + 20000 * sizeof(fhandler_union) + 5 * 65536 $10 = 2742052 (gdb) print (void*) 2742052 $11 = (void *) 0x29d724 ... (gdb) print (void*) 0x61600000 + 0x29d724 $13 = (void *) 0x6189d724 So, I reached the end of the cygheap. Maybe it's because xemacs with VM opens/closes so many files, or maybe it is leaving some files hanging open? Is there any way to get a list of the open files? Maybe the memory is just getting fragmented, or there is a memory leak somewhere. Is there a way to inspect the file table or the internal state of the cygheap? Should I start stepping through the buckets structure? Here is a dump of the cygheap data structure: (gdb) print *cygheap $2 = {chain = 0x6189dfbc, buckets = {0x0, 0x0, 0x0, 0x0, 0x6160420c "", 0x0, 0x61604224 "\\E`a\fB`a\001", 0x6160448c "ôB`a\004D`a", 0x0, 0x6162c8dc "4Eba'Eba\003", 0x0 <repeats 22 times>}, root = {m = 0x0}, user = {pname = 0x61603a3c "mccap", plogsrv = 0x0, pdomain = 0x0, homedrive = 0x61603dfc "C:", homepath = 0x61603e14 "\\", pwinname = 0x0, puserprof = 0x0, psid = 0x61603db4, orig_psid = 0x61603e2c, orig_uid = 1004, orig_gid = 513, real_uid = 1004, real_gid = 513, groups = {pgsid = {<cygpsid> = {psid = 0x616000c0}, sbuf = "\001\005\000\000\000\000\000\005\025\000\000\000\230\024î}\216\" #\025_M\206#\001\002", '\0' <repeats 13 times>}, sgsids = {maxcount = 0, count = 0, sids = 0x0, type = cygsidlist_empty}, ischanged = 0}, external_token = 0xffffffff, internal_token = 0xffffffff, current_token = 0xffffffff}, user_heap = {base = 0x10020000, ptr = 0x10ae8000, top = 0x10ae8000, max = 0x30020000, chunk = 536870912}, umask = 0, shared_h = 0xc4, console_h = 0x0, cygwin_regname = 0x0, cwd = { posix = 0x61604524 "/home/mccap/cygbugs", win32 = 0x61603a54 "C:\\cygwin\\home\\mccap\\cygbugs", hash = 2812255647, cwd_lock = 0x610e8a90}, fdtab = {fds = 0x61603cac, fds_on_hold = 0x0, first_fd_for_open = 0, cnt_need_fixup_before = 0, size = 32}, debug = { starth = {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, next = 0x61600170}, endh = 0x616003bc, freeh = {{h = 0xc4, name = 0x6107cbf9 "cygheap->shared_h", func = 0x6107cbe6 "void memory_init()", ln = 209, inherited = true, pid = 2356, next = 0x6160018c}, {h = 0xd4, ---Type <return> to continue, or q <return> to quit--- name = 0x6107cc33 "cygwin_mount_h", func = 0x6107cbe6 "void memory_init()", ln = 217, inherited = true, pid = 2356, next = 0x616001a8}, {h = 0x80, name = 0x61004d14 "hMainProc", func = 0x61004caf "void dll_crt0_1()", ln = 630, inherited = false, pid = 2356, next = 0x616001c4}, { h = 0x7c, name = 0x61004d1e "hMainThread", func = 0x61004caf "void dll_crt0_1()", ln = 631, inherited = false, pid = 2356, next = 0x616001e0}, {h = 0xe8, name = 0x61014080 "title_mutex", func = 0x6101406d "void events_init()", ln = 1133, inherited = false, pid = 2356, next = 0x616001fc}, {h = 0x100, name = 0x610610ee "pinfo_shared_handle", func = 0x61061070 "void pinfo::init(int, long unsigned int, void*)", ln = 180, inherited = false, pid = 2356, next = 0x61600234}, { h = 0x2b8, name = 0x61080dc1 "events[0]", func = 0x61080da8 "void subproc_init()", ln = 829, inherited = false, pid = 2356, next = 0x616002f8}, {h = 0x22c, name = 0x61080364 "signal_arrived", func = 0x6108033e "void sigproc_init()", ln = 608, inherited = false, pid = 2356, next = 0x61600250}, {h = 0xfc, name = 0x610819d6 "sigcatch_nosync", func = 0x61081993 "DWORD wait_sig(void*)", ln = 1107, inherited = false, pid = 2356, next = 0x6160026c}, {h = 0x104, name = 0x610819e6 "sigcatch_nonmain", ---Type <return> to continue, or q <return> to quit--- func = 0x61081993 "DWORD wait_sig(void*)", ln = 1108, inherited = false, pid = 2356, next = 0x61600288}, {h = 0x108, name = 0x610819f7 "sigcatch_main", func = 0x61081993 "DWORD wait_sig(void*)", ln = 1109, inherited = false, pid = 2356, next = 0x616002a4}, {h = 0x10c, name = 0x61081a05 "sigcomplete_nonmain", func = 0x61081993 "DWORD wait_sig(void*)", ln = 1110, inherited = false, pid = 2356, next = 0x616002c0}, {h = 0x110, name = 0x610805a8 "sigcomplete_main", func = 0x61081993 "DWORD wait_sig(void*)", ln = 1111, inherited = false, pid = 2356, next = 0x61600218}, {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, next = 0x0}, {h = 0x2c8, name = 0x6107eecf "wval->ev", func = 0x6107ec50 "int proc_subproc(long unsigned int, long unsigned int )", ln = 409, inherited = false, pid = 2356, next = 0x616003d8}, {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, next = 0x0}, {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, next = 0x0}, {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, next = 0x0}, {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, next = 0x0}, {h = 0x2d0, name = 0x61040b3b "fork_stupidity", func = 0x61040b20 "void slow_pid_reuse(void*)", ln = 339, inherited = false, pid = 2356, next = 0x616003bc}, {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, ---Type <return> to continue, or q <return> to quit--- next = 0x0}, {h = 0x2e4, name = 0x61040b3b "fork_stupidity", func = 0x61040b20 "void slow_pid_reuse(void*)", ln = 339, inherited = false, pid = 2356, next = 0x0}, {h = 0x31c, name = 0x61040b3b "fork_stupidity", func = 0x61040b20 "void slow_pid_reuse(void*)", ln = 339, inherited = false, pid = 2356, next = 0x616003f4}, {h = 0x30c, name = 0x61040b3b "fork_stupidity", func = 0x61040b20 "void slow_pid_reuse(void*)", ln = 339, inherited = false, pid = 2356, next = 0x61600384}, {h = 0x0, name = 0x0, func = 0x0, ln = 0, inherited = false, pid = 0, next = 0x0} <repeats 476 times>}}, sigs = 0x61603834} Anything look obviously wrong to anyone in the above? -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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 2003-09-09 20:33 ` SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 Pete McCann @ 2003-09-10 8:58 ` Corinna Vinschen 2003-09-12 19:42 ` Pete McCann 1 sibling, 0 replies; 12+ messages in thread From: Corinna Vinschen @ 2003-09-10 8:58 UTC (permalink / raw) To: cygwin On Tue, Sep 09, 2003 at 03:33:42PM -0500, Pete McCann wrote: > > Hi, > > After some more hunting, I now understand there is a difference > between the cygwin heap and the user heap. My problem is that I'm > running out of cygwin heap: Can you check how often the function cygwin_posix_to_win32_path_list_buf_size() is called? Does that happen fairly often? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin@cygwin.com Red Hat, Inc. -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 2003-09-09 20:33 ` SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 Pete McCann 2003-09-10 8:58 ` Corinna Vinschen @ 2003-09-12 19:42 ` Pete McCann 2003-09-12 21:23 ` Pete McCann 1 sibling, 1 reply; 12+ messages in thread From: Pete McCann @ 2003-09-12 19:42 UTC (permalink / raw) To: cygwin Corinna Vinschen writes: > On Tue, Sep 09, 2003 at 03:33:42PM -0500, Pete McCann wrote: > > > > Hi, > > > > After some more hunting, I now understand there is a difference > > between the cygwin heap and the user heap. My problem is that I'm > > running out of cygwin heap: > > Can you check how often the function cygwin_posix_to_win32_path_list_buf_size() > is called? Does that happen fairly often? > > Corinna That function is called about 600 - 700 times (sometimes as many as 2000-3000) when I do a simple operation like checking for new mail in the spool file. cygheap_max grows steadily with each call. -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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 2003-09-12 19:42 ` Pete McCann @ 2003-09-12 21:23 ` Pete McCann 2003-09-13 8:44 ` Corinna Vinschen 0 siblings, 1 reply; 12+ messages in thread From: Pete McCann @ 2003-09-12 21:23 UTC (permalink / raw) To: cygwin (responding to my own post) Pete McCann writes: > > Corinna Vinschen writes: > > > On Tue, Sep 09, 2003 at 03:33:42PM -0500, Pete McCann wrote: > > > > > > Hi, > > > > > > After some more hunting, I now understand there is a difference > > > between the cygwin heap and the user heap. My problem is that I'm > > > running out of cygwin heap: > > > > Can you check how often the function cygwin_posix_to_win32_path_list_buf_size() > > is called? Does that happen fairly often? > > > > Corinna > > That function is called about 600 - 700 times (sometimes as many as > 2000-3000) when I do a simple operation like checking for new mail in > the spool file. cygheap_max grows steadily with each call. And, I don't see a destructor for path_conv that would free normalized_path. Perhaps this is the source of the memory leak? Note that a path_conv is created on the stack inside conv_path_list_buf_size at path.cc, line 3627. -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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 2003-09-12 21:23 ` Pete McCann @ 2003-09-13 8:44 ` Corinna Vinschen 0 siblings, 0 replies; 12+ messages in thread From: Corinna Vinschen @ 2003-09-13 8:44 UTC (permalink / raw) To: cygwin On Fri, Sep 12, 2003 at 04:23:11PM -0500, Pete McCann wrote: > Pete McCann writes: > > Corinna Vinschen writes: > > > Can you check how often the function cygwin_posix_to_win32_path_list_buf_size() > > > is called? Does that happen fairly often? > > > > > > Corinna > > > > That function is called about 600 - 700 times (sometimes as many as > > 2000-3000) when I do a simple operation like checking for new mail in > > the spool file. cygheap_max grows steadily with each call. > > And, I don't see a destructor for path_conv that would free > normalized_path. Perhaps this is the source of the memory leak? > Note that a path_conv is created on the stack inside > conv_path_list_buf_size at path.cc, line 3627. The problem should be solved in CVS. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developer mailto:cygwin@cygwin.com Red Hat, Inc. -- 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/ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-09-13 8:44 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-06-03 19:21 SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 Pete McCann 2003-06-03 22:00 ` Christopher Faylor 2003-06-04 22:03 ` Pete McCann 2003-06-04 23:01 ` Christopher Faylor 2003-06-05 19:26 ` Pete McCann 2003-06-05 19:42 ` Christopher Faylor 2003-09-04 16:14 ` Pete McCann 2003-09-09 20:33 ` SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1 Pete McCann 2003-09-10 8:58 ` Corinna Vinschen 2003-09-12 19:42 ` Pete McCann 2003-09-12 21:23 ` Pete McCann 2003-09-13 8:44 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).