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]

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


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/


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