Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <16095.39236.307680.938888@gargle.gargle.HOWL> Date: Thu, 5 Jun 2003 14:25:56 -0500 From: Pete McCann To: cygwin AT cygwin DOT com Subject: Re: SEGV in conv_path_list_buf_size with xemacs-21.5-b13 and cygwin-1.3.22-1 References: <16092 DOT 62778 DOT 903944 DOT 717787 AT gargle DOT gargle DOT HOWL> <16094 DOT 27841 DOT 192212 DOT 543929 AT gargle DOT gargle DOT HOWL> In-Reply-To: <20030604230131.GA30497@redhat.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h55JQWL06472 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' , "\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' , 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 ' , "\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' , "\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/