Please note that as of October 24, 2014, we will be archiving some of the Nokia Developer discussion boards. The Nokia Asha and Nokia X sections will remain open for continued use. The "Windows Phone/Lumia" and "Other Platforms" sections will become read-only. For your Windows Phone development questions, we invite you to visit the Microsoft Developer Network (MSDN) discussion forums.

If this is your first visit, be sure to check out the FAQ. To start viewing messages, select the forum that you want to visit from the selection below.

Re: Creating CustomEffect in C++, NullReferenceException

I believe the memory cap isn't even checked if you attach the debugger (as long as the device doesn't run out of memory completely). So checking without debugger might resolve some of the unpredictability. Nontheless it seems as if the DelegatingEffect might have some issues in certain cases. Given that the crash occurs outside the custom effects themselves (e.g. no out of memory when the effect tries to create the Buffers (as that isn't even being called).

It would however be great if we could create a sample with that issue that we can actually share for debugging purposes and perhaps submit to the Imaging SDK team to look into if we can't figure it out.

Re: Creating CustomEffect in C++, NullReferenceException

I've been seeing the issue with my sample on both 1.0 and 1.1. (upgrading to the latest version was my first attempt to "fix" it). I hope I'll be able to correct everything in the sample until the weekend and will then reupload it. I'll also update it to include 1.1 (code-wise it makes no difference).

As for the underlying problem, I'm looking forward to lee's demo of the problem.

There are two pictures with identical dimension and same orientation, landscape. I apologize in advance for the subject matter in one of them. (it's a bloody finger) It worked and I didn't want to search for another one.
I made the rendering chain a little complicated, hoping to be a little bit more similar to what I have in my main app.

1. The first image on my Lumia 920 works with the DelegatingEffect (loading SB Dev's MultiplyEffect). However, if I hit back and then try to load it again, I get a null reference exception.

2. The second image doesn't work at all. Null reference exception every time.

3. The 3rd and 4th buttons open the same images, but without the DelegatingEffect. They work fine. However, if I open one of those first, then try to open the 1st image using the DelegatingEffect, I get a null reference exception.

*when running without the debugger, I just open the 2nd image without the DelegatingEffect about 4 times in a row... then I opened it with the DelegatingEffect and it WORKED!
This is completely frustrating!

Re: Creating CustomEffect in C++, NullReferenceException

I thinks i found the problem,
1- you share source between two element in the pipeline=> i thinks this could create concurrent access
2- Like you give customfilter directly to DelegateFiltering, you have unmanaged resources deallocation problem: Allocated buffer are deallocated only when the customfilter is free by garbadge collector. But for an unknow reason, garbage collector don't do it (maybe buffer use unmanaged memory)

I've add a virtual destructor to give possibility to Dispose it from C# and this avoid crash on 520 and 1020.

You can find the code here http://1drv.ms/1owutAW
* two first buttons use custom filter without dispose it
* two last buttons add a using on custom filter to dispose it (look DisplayPage2.xaml.cs)

C# customfilter haven't this problem because code use only managed memory.

Re: Creating CustomEffect in C++, NullReferenceException

Originally Posted by yan_

2- Like you give customfilter directly to DelegateFiltering, you have unmanaged resources deallocation problem: Allocated buffer are deallocated only when the customfilter is free by garbadge collector. But for an unknow reason, garbage collector don't do it (maybe buffer use unmanaged memory)

I changed the code in my app following your example... and so far it seems to work! Wow, thank you very much! I will report back when I have my actual custom filter up and running correctly (bugs are my fault).

Originally Posted by yan_

1- you share source between two element in the pipeline=> i thinks this could create concurrent access

Since it started working without this change, I haven't put it in yet. In my app, I'm using BufferSourceImage instead of StreamSourceImage. I'm not sure if this makes a difference with concurrency, but if it starts giving me problems later, I can make this change, too.

Merci beaucoup!

**edit: I've gotten my custom filter working properly and it's still not showing any sign of the error I used to get. The only change I made was to add the virtual destructor for disposal. I am still using one source in multiple places on the pipeline. Again, thank you!

Re: Creating CustomEffect in C++, NullReferenceException

Here's the snag I think you've hit (OP at least):

DelegatingEffect holds a weak reference to the passed ICustomEffect. Because ICustomEffect can be implemented by the class that also references the DelegatingEffect, had we made this reference strong it would have caused a reference cycle and therefore a memory leak.

So the non-obvious fact is that the user must somehow keep a strong reference to the ICustomEffect, otherwise the weak pointer in DelegatingEffect will decay to null - nearly immediately.
That's probably the source of the NullReferenceException seen.

CustomEffectBase in C# is the current standard implementation of this pattern, and should be interesting for you to study in a reflector/decompiler.

Since CustomEffectBase implements both IImageProvider and ICustomEffect, you have the necessary strong reference in the hands of anyone having a reference to the subclass.
CustomEffectBase also has a strong reference to an internal DelegatingEffect, and passes along all IImageProvider property get/set and method calls to it.

Finally, disposing DelegatingEffect/ICustomEffect should be no more complicated than disposing (or not disposing) any of the other objects in the SDK.

Re: Creating CustomEffect in C++, NullReferenceException

This explain a lit of thinks :/

Originally Posted by cadahl

DelegatingEffect holds a weak reference to the passed ICustomEffect. Because ICustomEffect can be implemented by the class that also references the DelegatingEffect, had we made this reference strong it would have caused a reference cycle and therefore a memory leak.

Why set the reference to null in destructor (called with dispose) not resolve reference cycle?

Personally, i thinks a weak reference is a bad solution here.

It should be really interesting if you could explain SDK memory management.

Re: Creating CustomEffect in C++, NullReferenceException

Originally Posted by yan_

Why set the reference to null in destructor (called with dispose) not resolve reference cycle?

Simply because we can't require the user to remember to Dispose, this would lead to many more developers having problems. That being said, the documentation of the SDK is fairly C# centered so far.. I'll bring up adding more native sample code.

We do recommend being vigilant about calling Dispose to ensure deterministic deallocation though, and because it's good practice.

About memory management within the SDK, there's not much interesting to say. Whether code is in C++/CX, WRL or "standard" style C++ (we use them all) we follow the usual reference counting patterns, which work realiably thanks to smart pointers. The few times that memory issues have arisen during testing, they have involved references crossing the ABI between native and managed domains.

Re: Creating CustomEffect in C++, NullReferenceException

Originally Posted by cadahl

Simply because we can't require the user to remember to Dispose, this would lead to many more developers having problems.

For me,

When the user allocate a class with IDsiposable, it should call dispose because garbage collector doesn't manage native memory. It's the role of Dispose function. It's the recommended practice and iIt's why we generally use using with native component. If user don't call dispose, deallocated of a lot of native memory will be delayed because garbadge collector doesn't use it in its algorithm. So, you can generate easily out of memory exception. And for me a weak reference is not logic because DelegatingXXX need a ICustomXXX to works. It's not a simple observator.

If you don't thinks user should dispose, you need to explain who and how memory is used with SDK.

Maybe i'm wrong, but it's what i've learn with my experience

Maybe it could be interesting to have a boolean in DelegatingXXX constructor to say him it should manage the ICustomXXXX or not.