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

[Pete McCann <mccap at lucent dot com>]

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/