VFS programming / PANIC when opening new files

[Esh, Andrew]

That function is defined in the stock code as:

static BOOL skel_fchmod_acl(struct files_struct *fsp, int fd, mode_t mode)
{
	return default_vfs_ops.fchmod_acl(fsp, fd, mode);
}

Which tells me that the only way a SIGSEGV can occur inside that function is
if there is a bad function pointer stored in default_vfs_ops. Since the
address at the bottom of the stack is "0x00000000", I'm guessing
default_vfs_ops never had that function pointer set to point at a function.
That can happen this way:

source/smbd/vfs.c:
	/* POSIX ACL operations. */
#if defined(HAVE_NO_ACLS)
	NULL,
	NULL,
#else
	vfswrap_chmod_acl,
	vfswrap_fchmod_acl,
#endif

So my suggestion is to check your source/include/config.h and see if you
have HAVE_NO_ACLS set like this:

source/include/config.h:
#define HAVE_NO_ACLS 1

Maybe configure detected that you don't have the ACL library installed.

-----Original Message-----
From: Joachim [mailto:JOFT at gmx.de]
Sent: Tuesday, April 29, 2003 1:29 PM
To: samba-technical at lists.samba.org
Subject: Re: VFS programming / PANIC when opening new files


Hi!

> Can you send me a gdb backtrace?

Sure. The backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x40244069 in skel_fchmod_acl () from 
/usr/local/src/samba-SAMBA_3_0/examples/VFS/skel.so
#2  0x080b7dbe in open_file_shared1 (conn=0x831d4d8, fname=0xbffff2c0 
"home/tester2/asd.sdf", psbuf=0xbffff240, desired_access=3, share_mode=127,
    ofun=18, mode=422, oplock_request=0, Access=0x0, action=0x0) at 
smbd/open.c:1153
#3  0x080b7151 in open_file_shared (conn=0x831d4d8, fname=0xbffff2c0 
"home/tester2/asd.sdf", psbuf=0xbffff240, share_mode=127, ofun=18, 
mode=422,
    oplock_request=0, Access=0x0, action=0x0) at smbd/open.c:784
#4  0x0809b43a in reply_mknew (conn=0x831d4d8, inbuf=0x401ff008 "", 
outbuf=0x40220008 "", dum_size=68, dum_buffsize=65535) at smbd/reply.c:1071
#5  0x080c7730 in switch_message (type=3, inbuf=0x401ff008 "", 
outbuf=0x40220008 "", size=68, bufsize=65535) at smbd/process.c:758
#6  0x080c77e7 in construct_reply (inbuf=0x401ff008 "", outbuf=0x40220008 
"", size=68, bufsize=65535) at smbd/process.c:788
#7  0x080c7b4f in process_smb (inbuf=0x401ff008 "", outbuf=0x40220008 "") at

smbd/process.c:889
#8  0x080c8828 in smbd_process () at smbd/process.c:1308
#9  0x08214e8a in main (argc=4, argv=0xbffff954) at smbd/server.c:877
#10 0x40093bb4 in __libc_start_main () from /lib/libc.so.6


So the error/bug seems to be somewhere in the default function for 
fchmod_acl, because this is the only function called by skel_fchmod_acl ... 
???

I remember, that when I used my own VFS module (with logging), there was a 
call to open, ftruncate, lock and sometimes there was a last call to fchmod 
(!!) before the corresponding smbd died ...
So this last (logged) call seems to be followed by a call to 
skel_fchmod_acl. But there I never put any logging lines.


Now I replaced the line

return default_vfs_ops.fchmod_acl(fsp, fd, mode);

in the function skel_fchmod_acl (in skel.c) with

return 1;

RESULT: It works :-)! No SegFaults!

BTW: I assume 1 = TRUE and 0 = FALSE, because of the return type of 
skel_fchmod_acl (BOOL). Are there any constants for true/false? "TRUE" (and 
"FALSE") doesn't work (compile time: "ERROR_XX_DONT_USE_TRUE").
 
>> A saw that the VFS API changed a bit (init_module, ...). What's about a
>> corresponding function for the old vfs_done in alpha23 ?
> There will be some kind of a smb_register_exit_event() function to
> register your clean up function.

"There will be"?? => So there is heavy activity on VFS issues/code at the 
moment?

 Joachim