ZFS vs Samba Debugging Results ... Need Help.

Hi,

After updating my system to a fresh current (to ensure the recent -O1
sys.mk change is included) i decided to have a go at debugging the
problem of ZFS seemingly crashing samba when trying to access a share
that's stored on a ZFS filesystem.

My debugging efforts have brought me to what seems to be the source of
the problem, though i am having trouble trying to understand what
according to gdb appears to happen.

Initially i simply ran smbd -i inside a gdb session after recompiling
samba with the MAX_DEBUG port option and inspected the stacktrace up
to the frame which seemed to be responsible for the trouble, I then
started a new gdb session and set an actual breakpoint on the function
involved:

Which leads to the following backtrace:

#0  vfs_readdirname (conn=0x20a25030, p=0x20a0e000) at smbd/vfs.c:647
#1  0x0005c72a in ReadDirName (dirp=0x2096a5a0, poffset=0xbfbfad9c) at
smbd/dir.c:1156
#2  0x0005da2b in dptr_normal_ReadDirName (dptr=0x209b2ec0,
poffset=0xbfbfad9c, pst=0xbfbfb9b8) at smbd/dir.c:562
#3  0x0005da7b in dptr_ReadDirName (dptr=0x209b2ec0,
poffset=0xbfbfad9c, pst=0xbfbfb9b8) at smbd/dir.c:579
#4  0x000a1255 in get_lanman2_dir_entry (conn=0x20a25030, inbuf=0x0,
outbuf=0x20a4a000 "", path_mask=0xbfbfbb3c "*", dirtype=<error type>,
info_level=260, requires_resume_key=4,
    dont_descend=0, ppdata=0xbfbfbb38, base_data=0x20a71000 "`",
space_remaining=16448, out_of_space=0xbfbfbb2c,
got_exact_match=0xbfbfbac0, last_entry_off=0xbfbfbb34,
    name_list=0x0, ea_ctx=0x0) at smbd/trans2.c:1149
#5  0x000a4862 in call_trans2findfirst (conn=0x20a25030,
inbuf=0x20a29000 "", outbuf=0x20a4a000 "", bufsize=65535,
pparams=0x20a1a968, total_params=18, ppdata=0x20a1a970,
    total_data=0, max_data_bytes=<error type>) at smbd/trans2.c:1857
#6  0x000a5042 in handle_trans2 (conn=0x20a25030, state=0x20a1a830,
inbuf=0x20a29000 "", outbuf=0x20a4a000 "", size=90, bufsize=65535) at
smbd/trans2.c:6327
#7  0x000ab21d in reply_trans2 (conn=0x20a25030, inbuf=0x20a29000 "",
outbuf=0x20a4a000 "", size=90, bufsize=65535) at smbd/trans2.c:6597
#8  0x000c6538 in switch_message (type=547414036, inbuf=0x20a29000 "",
outbuf=0x20a4a000 "", size=90, bufsize=65535) at smbd/process.c:1003
#9  0x000c81a8 in smbd_process () at smbd/process.c:1030
#10 0x002ea030 in main (argc=3055664, argv=0xf1f1f1f1) at smbd/server.c:1120


I include the function implementation in question for convenience here:

char *vfs_readdirname(connection_struct *conn, void *p)
{
        SMB_STRUCT_DIRENT *ptr= NULL;
        char *dname;

        if (!p)
                return(NULL);

        ptr = SMB_VFS_READDIR(conn, (DIR *)p);
        if (!ptr)
                return(NULL);

        dname = ptr->d_name;

#ifdef NEXT2
        if (telldir(p) < 0)
                return(NULL);
#endif

#ifdef HAVE_BROKEN_READDIR_NAME
        /* using /usr/ucb/cc is BAD */
        dname = dname - 2;
#endif

        return(dname);
}


ptr->d_name properly contains a null-terminated string "." indicating
the current directory (which is actually something that a later
function actively tries to check for .. which is in turn responsible
for the SIGABORTs of smbd)


The part of the gdb output that i am not getting is the following:
(gdb) print ptr
$38 = (struct dirent *) 0x20a0e014

(gdb) print &ptr->d_name
$35 = (char (*)[256]) 0x20a0e01c

(gdb) print dname
$37 = 0x20a0e014 "\003"

Somehow when the function is returning the variable dname suddenly
seems to be pointing to "ptr" instead of "ptr->d_name".

If anybody has any clue what's possibly going on here ... please enlighten me.

With kind regards,
-- 
  Pascal Hofstee