Confirmed, it's the same error seen in comment #2 of bug #1711

But the original stack trace for bug #1711 is different, so this "segfault on config error" error may be different.

I have changed the summary line since the bug is present for many (all?) configuration errors.

Hi,
 Looks that it is the same error of comment #2 of bug #1711. It happens in all errors, because the fd_table initialized in comm_init function which called after parseConfigFile function.
I propose    to make a fdAllocMemory() function which initializes the fd_table in early stages.
 The following small patch solves the problem for me:

Index: main.cc
===================================================================
RCS file: /cvsroot/squid/squid3/src/main.cc,v
retrieving revision 1.51.2.7
diff -u -r1.51.2.7 main.cc
--- main.cc	29 Jan 2007 20:00:27 -0000	1.51.2.7
+++ main.cc	1 Mar 2007 17:33:34 -0000
@@ -1115,6 +1115,8 @@
 #endif
 #endif /* HAVE_MALLOPT */
 
+    void fdAllocMemory(void);
+    fdAllocMemory();
     /*
      * The plan here is to set the umask to 007 (deny others for
      * read,write,execute), but only if the umask is not already
Index: comm.cc
===================================================================
RCS file: /cvsroot/squid/squid3/src/comm.cc,v
retrieving revision 1.53.2.5
diff -u -r1.53.2.5 comm.cc
--- comm.cc	19 Oct 2006 06:12:56 -0000	1.53.2.5
+++ comm.cc	1 Mar 2007 17:33:40 -0000
@@ -1801,7 +1801,7 @@
 
 void
 comm_init(void) {
-    fd_table =(fde *) xcalloc(Squid_MaxFD, sizeof(fde));
+//    fd_table =(fde *) xcalloc(Squid_MaxFD, sizeof(fde));
     fdd_table = (fd_debug_t *)xcalloc(Squid_MaxFD, sizeof(fd_debug_t));
     fdc_table = new fdc_t[Squid_MaxFD];
     commfd_table = (comm_fd_t *) xcalloc(Squid_MaxFD, sizeof(comm_fd_t));
Index: fd.cc
===================================================================
RCS file: /cvsroot/squid/squid3/src/fd.cc,v
retrieving revision 1.10.8.3
diff -u -r1.10.8.3 fd.cc
--- fd.cc	14 Dec 2006 06:12:16 -0000	1.10.8.3
+++ fd.cc	1 Mar 2007 17:33:40 -0000
@@ -248,6 +248,12 @@
 }
 
 void
+fdAllocMemory(void)
+{
+    fd_table =(fde *) xcalloc(Squid_MaxFD, sizeof(fde));
+}
+
+void
 fdFreeMemory(void)
 {
     safe_free(fd_table);

Created attachment 1315 [details]
Revised patch

Just moved the fdAllocMemory() declaration to protos.h

This patch seems to fix the problem.

*** Bug 1711 has been marked as a duplicate of this bug. ***

It seems wrong that we are just allocating memory for some internal comm_ structure without doing the rest of the stuff that comm_init does (or will do). How long before we hit another bug because some other comm_ state (e.g., conn_close_pool) was not initialized properly when some comm_ routine (commSetCloseOnExec in this case) is called before comm_init?

Can we call comm_init earlier instead? Do MemPools need something from squid.conf?

Hi Alex,

(In reply to comment #6)
> It seems wrong that we are just allocating memory for some internal comm_
> structure without doing the rest of the stuff that comm_init does (or will do).
> How long before we hit another bug because some other comm_ state (e.g.,
> conn_close_pool) was not initialized properly when some comm_ routine
> (commSetCloseOnExec in this case) is called before comm_init?
> 
> Can we call comm_init earlier instead? Do MemPools need something from
> squid.conf?
> 
I agree with you.
We can move comm_init() just after Mem::Init().

Regards

Guido

Created attachment 1354 [details]
Proposed patch for Squid 3.0

comm_init calls memPoolCreate. Squid.conf has options related to memory pools. Is it really OK to move comm_init before Mem::Init and before parseConfigFile, as patch #1354 does?

Last time I looked the memory pools are operational before main() is called.

Hi Alex,

(In reply to comment #9)
> comm_init calls memPoolCreate. Squid.conf has options related to memory pools.
> Is it really OK to move comm_init before Mem::Init and before parseConfigFile,
> as patch #1354 does?

But I have placed comm_init() just after Mem::Init .... :-)

Guido
 

Committed to Squid3 HEAD.

Thank you.

Note: The patch still applies to squid 3.1.23.

It was reverted in http://www.squid-cache.org/Versions/v3/3.0/changesets/10689.patch