talloc & threads in rlm_eap

[Arran Cudbard-Bell]

On 21 Jun 2014, at 16:30, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:

> 
> On 21 Jun 2014, at 17:23, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
> 
>> 
>> On 21 Jun 2014, at 17:20, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
>> 
>>> 
>>> On 21 Jun 2014, at 12:13, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
>>> 
>>>> Something's still not quite right; I can still trigger a crash with my local config, though it's much much harder. Symptoms look similar i.e. heap corruption, though I've only triggered a few so far.
>>>> 
>>>> :o(
>>>> 
>>>> Can't seem to trigger one with a default config, so maybe it's a module I'm using, or maybe the combo of "real" options just makes it more likely and I didn't wait long enough.
>>>> 
>>>> Will keep poking to see if I can make it more readily reproducible.
>>> 
>>> Double frees aren't always due to heap corruption, sometimes it's not reparenting attributes correctly into other contexts, so they get freed when their original parent does.
>>> 
>>> If you can get the circular buffer debug stuff working, then you'll be able to see where the double freed VALUE_PAIR was allocated from originally, which will be a big clue.
>>> 
>>> As a first diagnostic step i'd try getting rid of calls to rlm_cache and see if that helps. It's the module most likely to experience those kind of reparenting issues.
>> 
>> Ug, its rbtree was parented off its instance data too... just fixed that.
> 
> Arg and the handler and session trees :(

Any better with latest v3.0.x HEAD? Just fixed all the connection pool handle allocation.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140623/fb440333/attachment.pgp>