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

[Christopher Faylor <cgf at redhat dot com>]

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/