Closed GoogleCodeExporter closed 9 years ago
The cbdata allocactor for COSS hasn't been setup properly it seems. I'll go and
see why.
Original comment by adrian.c...@gmail.com
on 1 Jul 2009 at 11:30
Thats curious. Line 292 is 'sio = cbdataAlloc(storeIOState);' and that cbdata
type
should absolutely exist..
Original comment by adrian.c...@gmail.com
on 1 Jul 2009 at 3:12
Actually, what is even more curious is how storeIOState is being created. It is
initialised in the _AUFS_ code?
CBDATA_INIT_TYPE_FREECB(storeIOState, storeAufsIOFreeEntry);
.. with an AUFS private free handler? What the hell?
Original comment by adrian.c...@gmail.com
on 1 Jul 2009 at 3:14
Ok. You've uncovered another crufty corner of the Squid codebase.
It turns out that there's a missing CBDATA_INIT_TYPE_FREECB() there, BUT the
free
callback in -theory- is meant to be for all instances of that type, rather than
per
allocation.
The UFS, AUFS and DISKD modules all call CBDATA_INIT_TYPE_FREECB() with their
own
entry free function. COSS, which came later, doesn't seem to have been given
one.
The problem here is that the init function only ever gets called -once- for a
cbdata
type. So if >1 FS type is configured - say UFS and AUFS, whichever first
allocates an
object will have the relevant "free" function setup which will be correct for
that FS
type but not for the other.
Now, how this is all leading to a COSS crash with the cbdata type being
"unknown" is
a mystery to me, but the fix - which should be calling CBDATA_INIT_TYPE or
CBDATA_INIT_TYPE_FREECB -before- any calls to cbdataAlloc() - isn't being done.
Gah, this may explain some of the random weird COSS crashes that people have
been
seeing. Generally people run caches with both COSS and AUFS configured.
Grr, Kris. Grr. How dare you find a juicy example of horrible code which is
demanding
to be tidied up? :)
Original comment by adrian.c...@gmail.com
on 1 Jul 2009 at 3:25
Original comment by adrian.c...@gmail.com
on 1 Jul 2009 at 3:26
I've begun work on this issue. Please update to LUSCA_HEAD revision 14208 and
re-test.
Original comment by adrian.c...@gmail.com
on 18 Jul 2009 at 12:05
I've fixed this. Among other things in r14208, I shuffled around the mempool
init
order so it gets properly setup.
There are other issues with adding a COSS directory at runtime - the storage and
rebuild code was never really designed for that - so please don't add new COSS
directories without restarting.
Original comment by adrian.c...@gmail.com
on 30 Jul 2009 at 3:01
Original issue reported on code.google.com by
Fraw...@gmail.com
on 22 Jun 2009 at 7:00