squid-1867

Version:

2.6.STABLE5

Bug link:

http://bugs.squid-cache.org/show_bug.cgi?id=1867 

How it is diagnosed (reproduced or source analysis)?

We reproduced the failure.

How to reproduce?

1. In order to compile the buggy code on my system (Linux Federa core), I first commented out all the ‘#if LEAK_CHECK_MODE’. Then:

2 .Start the squid server.

3. shut down the server: squid -k shutdown

And we can observe the symptom: the squid.pid file still in the logs directory

Symptom:

Shutting down squid with ‘squid -k shutdown’ didn’t remove the squid.pid file, which results in failure for some rc script.

Root cause:

Squid freed the pointer holding the file name before removing (unlink) the file! So at the point where Squid is ready to unlink the file it couldn’t find the file name.

The fix is to first unlink the file, then free the pointer holding the file name.

Details:

SquidShutdown () {

   /* In configFreeMemory (shown below), the Config.pidFilename pointer is freed, but the file is not unlinked. */

   configFreeMemory();

    ...

   /* Now squid wants to unlink the file, pidFilename, but cannot anymore since pidFilename == NULL! */

   if (Config.pidFilename && strcmp(Config.pidFilename, "none") != 0) {

        enter_suid();

        safeunlink(Config.pidFilename, 0); // This is where pid file is supposed to be removed!

        leave_suid();

   }

   exit(0);

}

void configFreeMemory (void) {

   free_all ();

}

static void free_all(void) {

      ...

        free_string(&Config.pidFilename);

      ...

}

The fix: first unlink file:

SquidShutdown () {

+   if (Config.pidFilename && strcmp(Config.pidFilename, "none") != 0) {

+        enter_suid();

+        safeunlink(Config.pidFilename, 0);

+        leave_suid();

+  }

   configFreeMemory();

    ...

-   if (Config.pidFilename && strcmp(Config.pidFilename, "none") != 0) {

-        enter_suid();

-        safeunlink(Config.pidFilename, 0);

-        leave_suid();

-  }

   exit();

}

Is there Error Message?

No.

Can developers/Errlog anticipate the failure:

Yes. We could print a log message before the ‘exit’ -- falling into the pattern: log before exit.