Hi all,
attached is a tentative fix for bug 4438.
I can't reproduce the bug, unfortunately; judging from the traces it
seems to me to be a case of mismatched alloc/free calls (alloc through
memallocate, free through mempools).
If that's the case, there's a few angles to take on this problem, and
here is one: ensuring that mempools are initialized before MemBlob is
used. I chose this approach as it's the least invasive, and it's made
possible by libmem not depending on libsbuf; another could be to have
MemBlob not rely on old_api (basically refactoring some old_api into
MemBlob itself), and yet another could be to make mempools handle more
gracefully the case of having to free a memory region they did not
allocate.
please let me know your thoughts; I also kindly ask Yuri if he can try
the fix and see if it fixes the issue he's seeing.
--
Francesco
=== modified file 'src/mem/old_api.cc'
--- src/mem/old_api.cc 2016-01-01 00:12:18 +0000
+++ src/mem/old_api.cc 2016-03-05 11:10:40 +0000
@@ -396,7 +396,8 @@
void
Mem::Init(void)
{
- int i;
+ if (MemIsInitialized)
+ return;
/** \par
* NOTE: Mem::Init() is called before the config file is parsed
@@ -439,7 +440,7 @@
MemPools[MEM_MD5_DIGEST]->setChunkSize(512 * 1024);
/** Lastly init the string pools. */
- for (i = 0; i < mem_str_pool_count; ++i) {
+ for (int i = 0; i < mem_str_pool_count; ++i) {
StrPools[i].pool = memPoolCreate(StrPoolsAttrs[i].name, StrPoolsAttrs[i].obj_size);
StrPools[i].pool->zeroBlocks(false);
=== modified file 'src/sbuf/MemBlob.cc'
--- src/sbuf/MemBlob.cc 2016-03-01 10:25:13 +0000
+++ src/sbuf/MemBlob.cc 2016-03-05 11:13:27 +0000
@@ -14,6 +14,16 @@
#include <iostream>
+namespace {
+class MemInitializer {
+public:
+ MemInitializer() {
+ Mem::Init();
+ }
+};
+auto mi = MemInitializer();
+} /* anon namespace */
+
MemBlobStats MemBlob::Stats;
InstanceIdDefinitions(MemBlob, "blob");
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev
