Hi Roman,

Is there still a leak in the latest master trunk even after the fix for 
NH-3579? If yes, please create a new Jira issue and GitHub pull request.

On Friday, January 24, 2014 2:30:38 PM UTC+1, Roman Kvasov wrote:
>
> Hi Alexander,
>
> I think you forgot big chunk of leak, NhLinqExpression leak reference to 
> constants that used in linq expression.
> If linq query reference for object it end up in cache and object not 
> released.
> I wrote simple task case for demostration 
> https://github.com/radiy/nhibernate-core/blob/master/src/NHibernate.Test/Linq/ExpressionSessionLeakTest.cs#L23
> .
> I made over version of fix 
> https://github.com/radiy/nhibernate-core/commit/82706daafcbfe4ec32aca94a51bbbb16369fe83e
> .
> Please review.
>
>
> 2014/1/21 Alexander I. Zaytsev <[email protected] <javascript:>>
>
>> Hi all,
>>
>> I've made a pull request with a fix.
>>
>> https://github.com/nhibernate/nhibernate-core/pull/248
>>
>> Please review.
>>
>> Best Regards, 
>> Alexander
>>
>>
>> 2014/1/21 Oskar Berggren <[email protected] <javascript:>>
>>
>>>
>>> 2014/1/20 Lauri Kotilainen <[email protected] <javascript:>>
>>>
>>>>
>>>>
>>>> On Saturday, January 18, 2014 11:44:53 PM UTC+2, Oskar Berggren wrote:
>>>>>
>>>>>  
>>>>> Unfortunately, even with that patch applied, the unit test in my other 
>>>>>> post fails -- even though a heap inspection with WinDBG confirms that 
>>>>>> the 
>>>>>> session is no longer rooted and is eligible for collection.
>>>>>>  
>>>>>
>>>>> My attempts with dubious knowledge of Windbg seems to confirm that the 
>>>>> test itself did indeed maintain a reference to the SessionImpl instance, 
>>>>> as 
>>>>> a local variable in the stack fram of IsGarbageCollected<TObject>(ref 
>>>>> TObject @object, Action<TObject> useObject). I don't know how to explain 
>>>>> that, given that the test code attempted to nullify the reference.
>>>>>
>>>>
>>>> The second GC.Collect() pass fixed that for me, like Gunnar suggested. 
>>>> I'll take another look at it soon-ish to see if your modified test still 
>>>> behaves the way I think it should.
>>>>
>>>
>>> I added a bunch more, plus some other GC.xxx() methods, didn't help.
>>>  
>>>
>>>  
>>>> My first attempt at a fix actually was to discard the _expression 
>>>> reference. However, that didn't work -- IIRC because the results of the 
>>>> translation maintained another reference to the expression. Changing that 
>>>> would have had a considerably bigger change footprint, one that I wasn't 
>>>> comfortable with.
>>>>
>>>
>>> I later tried that too and discovered that Translate() is actually 
>>> called twice and apparently produces different output on the second go. I 
>>> haven't yet figured out what input data (or how) is modified to achieve 
>>> this effect.
>>>  
>>>
>>> /Oskar
>>>
>>>  -- 
>>>  
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "nhibernate-development" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected]<javascript:>
>>> .
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  -- 
>>  
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "nhibernate-development" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected]<javascript:>
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"nhibernate-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to