Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: 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 <mccap AT lucent DOT com>
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


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 <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/