On Tue, Jul 21, 2009 at 08:22:46AM +0200, Stefan (metze) Metzmacher wrote: > Hi Jeremy, > > > Move the initialization of smbd_server_conn from smbd/process, > > after the accept and fork, to smbd_init_globals(), so it's > > done immediately on server startup. This is needed as some > > messages are sent to all active smbd processes (including > > the master listening daemon). If it gets a message that > > forces it to scan it's current connections (ie. conn_find()) > > then it discovers that sconn->smb1.tcons.Connections dereferences > > null (as sconn == NULL in the parent) and crashes. Yes, > > I could fix all cases where sconn is used and explicitly > > check for NULL but this fix is easier. It means that > > the smbd_event_context() is initialized in the master > > daemon and then re-initialized after fork, but that > > should be being done correctly in every fork call anyway. > > Without this change the previous fix > > 6a9e0039100b57f9626e87defec6720c476b9789 > > still panics in the reproducible test case for bug > > 6564, as this is one case where such a message > > (MSG_SMB_CONF_UPDATED) is sent to the parent. Metze > > please check. This change passes valgrind. > > Jeremy. > > I think it is thte wrong approach, smbd_server_connection represents > the state of a connected client/a smbd child process. > I added it so that we strictly separate code that runs in the parent > from code that runs in the child. > > I'd really like to understand what the problem is. > From reading the code I can't find where we hit any panic.
Oh, I thought the above description was good enough, sorry :-). > Can you send me the backtrace please? Sure, I'll reproduce and send it. I'm glad you're looking at it, it's an ugly fix but I couldn't see an elegant way of fixing it without filling the code with "if (!sconn) return" statements everywhere. Jeremy.