Bug 4738 - smbd on FreeBSD 4.8 aborts (Signal 6) accessing msdosfs share
Summary: smbd on FreeBSD 4.8 aborts (Signal 6) accessing msdosfs share
Status: RESOLVED DUPLICATE of bug 4715
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.25a
Hardware: x86 FreeBSD
: P3 critical
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-23 16:02 UTC by Carl Mascott (dead mail address))
Modified: 2007-08-04 23:47 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carl Mascott (dead mail address)) 2007-06-23 16:02:15 UTC
smbd 3.0.25a on FreeBSD 4.8 aborts (Signal 6) accessing msdosfs share
(no problem accessing native Berkeley FFS shares)
(no problem w/ smbd 3.0.10 accessing msdosfs shares)

----------------------------------------------------

gdb backtrace:

GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
(no debugging symbols found)...
(gdb) run -i
Starting program: /usr/ports/net/samba3/work/samba-3.0.25a/source/smbd/../bin/smbd -i
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
smbd version 3.0.25a started.
Copyright Andrew Tridgell and the Samba Team 1992-2007
file_init: Information only: requested 10000 open files, 1004 are available.
centauri (192.168.1.100) connect to service dos_E initially as user cmascott (uid=1001, gid=1001) (pid 4295)
(no debugging symbols found)...
Program received signal SIGABRT, Aborted.
0x28484bac in kill () from /usr/lib/libc.so.4
(gdb) bt
#0  0x28484bac in kill () from /usr/lib/libc.so.4
#1  0x284c613a in abort () from /usr/lib/libc.so.4
#2  0x81ed1b9 in telldir ()
#3  0x81f750e in sys_telldir ()
#4  0x80f4ffa in vfswrap_telldir ()
#5  0x8098428 in ReadDirName ()
#6  0x8096ef3 in dptr_normal_ReadDirName ()
#7  0x80970c4 in dptr_ReadDirName ()
#8  0x80c3872 in get_lanman2_dir_entry ()
#9  0x80c5d3e in call_trans2findfirst ()
#10 0x80cf8f3 in handle_trans2 ()
#11 0x80d0206 in reply_trans2 ()
#12 0x80e94d9 in switch_message ()
#13 0x80e9574 in construct_reply ()
#14 0x80e978b in process_smb ()
#15 0x80ea4e4 in smbd_process ()
#16 0x8298cdb in main ()
#17 0x8081b0e in _start ()
(gdb) k
Kill the program being debugged? (y or n) y
(gdb) q

------------------------------------------

Here is the function in which the abort() happens (lib/replace/repdir_getdirentries.c:telldir())

#ifdef TELLDIR_TAKES_CONST_DIR
long telldir(const DIR *dir)
#else
long telldir(DIR *dir)
#endif
{
	struct dir_buf *d = (struct dir_buf *)dir;
	if (d->ofs >= d->nbytes) {
		d->seekpos = lseek(d->fd, 0, SEEK_CUR);
		d->ofs = 0;
		d->nbytes = 0;
	}
	/* this relies on seekpos always being a multiple of
	   DIR_BUF_SIZE. Is that always true on BSD systems? */
	if (d->seekpos & (DIR_BUF_SIZE-1)) {
		abort();
	}
	return d->seekpos + d->ofs;
}

-------------------------------------------

The answer to the question in the source code "Is that always true on BSD systems?" is NO.  The author of the code apparently made the false assumption that the type of operating system that smbd is running on determines the type of file system that the share resides on.  It does not.  I have several VFAT shares on a Windows partition that I mount under FreeBSD using FreeBSD's msdosfs.  I could access these shares using smbd 3.0.10, but I can't access them using smbd 3.0.25a.

IMPORTANT:

The same abort check appears in telldir() in three files, so whatever fix is made must be made to telldir() in all three files:

lib/repdir.c
lib/replace/repdir_getdents.c
lib/replace/repdir_getdirentries.c

(On my system the third file is the one that is used.)
Comment 1 Jeremy Allison 2007-08-04 23:47:25 UTC

*** This bug has been marked as a duplicate of 4715 ***