On 07/16/2012 12:17 AM, Amos Jeffries wrote:
> On 5/07/2012 10:00 a.m., Alex Rousskov wrote:
>> On 06/27/2012 03:12 AM, Amos Jeffries wrote:
>>> 3562 - StoreEntry::kickProducer Segmentation fault
>> I suspect Squid is corrupting its own memory somewhere so this specific
>> core dump cannot be trusted. This might even be the same problem as bug
>> 3551 above. This could be considered a blocker at least until we know
>> more, I guess.
I have a theory on what is going on there. This may be a side-effect of
Squid inability to lock StoreEntry correctly. While the fix is simple
(just lock the entry during the entire "sensitive" code execution), it
may have unpredictable side-effects: When the locked-once entry is
unlocked it will be destroyed, possibly causing problems for the
unsuspecting caller code. Properly fixing _that_ is difficult until all
code starts to lock store entries correctly (which probably requires
finishing the transition to a dedicated memory cache class API).
I asked for more info to confirm this theory.
HTH,
Alex.
Received on Mon Jul 16 2012 - 17:06:36 MDT
This archive was generated by hypermail 2.2.0 : Tue Jul 17 2012 - 12:00:03 MDT