This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]