Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16092.62778.903944.717787@gargle.gargle.HOWL> Date: Tue, 3 Jun 2003 14:21:30 -0500 From: Pete McCann To: cygwin AT cygwin DOT com Subject: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h53JLrK03443 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 AT q\210\v«\n\016\020\n\230« \004\r@\024)\rA\025ªä\f*r AT E\n!\031I\t\233\030É \035E\034\016\021«-\b«*\f¬'\r«$r\ r AT 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 AT 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 , bar g=8982592, hfun=0x473dd0 , 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 , barg=7006212, hfun=0x430da0 , 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 , 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' , "c:\\", '\0' , root_dir = "C:\\", '\0' , 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/