search

inevity / lusca-cache

Automatically exported from code.google.com/p/lusca-cache
0 stars 0 forks source link

COSS cbdata initialisation not "right" (was Crash when enabling COSS) #29

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. start LUSCA without a COSS partition
2. Enable a COSS partition in the config
3. run squid -k reconfigure to bring it up

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
 LUSCA_HEAD - Debian Unstable

Please provide any additional information below.

cache.log

2009/06/22 16:42:59| Ready to serve requests.
2009/06/22 16:42:59| assertion failed: cbdata.c:204: "type > 0 && type <
cbdata_types"

BackTrace

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7e3e6c0 (LWP 2554)]
0xb8039424 in __kernel_vsyscall ()
(gdb) bt
#0  0xb8039424 in __kernel_vsyscall ()
#1  0xb7e6b3b0 in raise () from /lib/i686/cmov/libc.so.6
#2  0xb7e6ea75 in abort () from /lib/i686/cmov/libc.so.6
#3  0x080d8990 in xassert (msg=0x811b784 "type > 0 && type < cbdata_types",
file=0x811b688 "cbdata.c", line=204) at debug.c:270
#4  0x080deaa2 in cbdataInternalAlloc (type=CBDATA_UNKNOWN) at cbdata.c:204
#5  0x080ce886 in storeCossCreate (SD=0x8368540, e=0xbd3cf20,
file_callback=0x80b8360 <storeSwapOutFileNotify>,
    callback=0x80b8f50 <storeSwapOutFileClosed>, callback_data=0xc2f0f80)
at coss/store_io_coss.c:292
#6  0x080b2b03 in storeCreate (e=0xbd3cf20, file_callback=0x80b8360
<storeSwapOutFileNotify>, close_callback=0x80b8f50 <storeSwapOutFileClosed>,
    callback_data=0xc2f0f80) at store_io.c:54
#7  0x080b8b4d in storeSwapOut (e=0xbd3cf20) at store_swapout.c:71
#8  0x080af319 in storeComplete (e=0xbd3cf20) at store.c:1450
#9  0x0807be20 in fwdComplete (fwdState=0xbee7ca8) at forward.c:1128
#10 0x08088f74 in httpAppendBody (httpState=0xb5d9c90,
    buf=0xc304449
"��\177��j\232\034�\224\232TB�&(�\034a\231ï�
�½\a>�\b��t-q�\237\017�\217u\bk}E���\03
1#
(#�\214�\227\207��+w\177���_���
�\236\\\205\033=\210#�b��i4\206��\v�5\215\226
�ojF�%�DuR�\225��ZvK�\v-J���E\
004�\r\225�\033\210��\034zt�w��\233O�KK�
�¿½]=�\215\213�\\\2271\222Hgf�<��Ma\213��ï
¿½K\001\035̱�w2��\034a[�\232p\215�c9�s�\
226�^Ҭ�\227P\235oa2/"...,
len=-1, buffer_filled=0) at http.c:974
#11 0x0808b576 in httpReadReply (fd=705, data=0xb5d9c90) at http.c:1237
#12 0x080e8ec2 in comm_select (msec=134) at comm_generic.c:264
#13 0x080942e4 in main (argc=2, argv=0xbf9df8f4) at main.c:934

Original issue reported on code.google.com by Fraw...@gmail.com on 22 Jun 2009 at 7:00

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago

Original comment by adrian.c...@gmail.com on 1 Jul 2009 at 3:26

GoogleCodeExporter commented 9 years ago 
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

GoogleCodeExporter commented 9 years ago 
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