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

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

[Pete McCann]

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/

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

[Christopher Faylor]

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/

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

[Pete McCann]

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/

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

[Christopher Faylor]

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/

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

[Pete McCann]

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/

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

[Christopher Faylor]

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/

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

[Pete McCann]

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/

Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1

[Pete McCann]

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/

Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1

[Corinna Vinschen]

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/

Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1

[Pete McCann]

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/

Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1

[Pete McCann]

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

Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-snapshot-20030904-1

[Corinna Vinschen]

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/