Dmip crash in debug mode in Visual Studio 2008

[Oliver]

Hello,

I'm evaluating the DMIP library, on Vista x64.
I successfully build the main executable, dmip_example.exe, using the buildem64t.bat script.
Now I've build a solution and a vcproj in Visual Studio 2008 SP1.
The build is successfull in all modes (Release, Debug...). The Release executable works fine.

But the Debug executable crashes when deleting Nodes.

(ie delete srcNode; at line381 in the DMIP_modify_brightness function).

The Debug build sets the Runtime Library to be Multi-threaded Debug DLL (/MDd), setting it to (/MD) doesn't help.
If I run the Debug build without attaching the debugger, it also crashes.

I'm linking against the following libraries:
dmip.lib
ippcoreem64tl.lib
ippsemergedem64t.lib
ippsmergedem64t.lib
ippiemergedem64t.lib
ippimergedem64t.lib
ippcvemergedem64t.lib
ippcvmergedem64t.lib
ippccemergedem64t.lib
ippccmergedem64t.lib

If someone successfully built a .vcproj using DMIP, and is able to debug the program, I would be glad to hear about it. It would help me to get such .vcproj file :)

Thanks
Olivier

[Vladimir_Dudnik]

Hi Oliver,

I assume you use DMIP from IPP 6.0 release. There was an implementation issue in DMIP when we allocate memory in DLL but free it up from application. This may cause problem you face in case of different versions of CRT libs. We have fixed this issue in the next release which is just coming soon.

Could you please share with us your thoughts on that kind of parallel programming framework? We are interested in feedback on this to extend the performance, functionality and features.

Regards,
Vladimir

[Goran_N]

I ran into the same problem. However, if I set -example to anything than 0, it all works. It's only example 0 that crashes.


Quoting - Vladimir Dudnik (Intel)

Hi Oliver,

I assume you use DMIP from IPP 6.0 release. There was an implementation issue in DMIP when we allocate memory in DLL but free it up from application. This may cause problem you face in case of different versions of CRT libs. We have fixed this issue in the next release which is just coming soon.

Could you please share with us your thoughts on that kind of parallel programming framework? We are interested in feedback on this to extend the performance, functionality and features.

Regards,
Vladimir

[Oliver]

Hi Goran,
Thanks for your feedback.
I experiment various crashes after deleting nodes and/or graphes, in release and/or debug. In example 0 and example 3, it crashes in debug. Hope it will be fixed soon :)
Regards
Olivier

[Vladimir_Dudnik]

Hi Oliver,

please also make sure you use the latest IPP 6.0 update 2 release. And yes, these annoying issues will be fixed in the next IPP 6.1 release, which is just coming soon

Regards,
Vladimir

[Oliver]

Hi Vladimir,

Thanks for your answers. I'll be very happy with the next release, because all my tests do crash at some point, often very early. Do you have a release schedule ?

We're investigating different technologies regarding image processing, for a general purpose image compositing middleware. DMIP seems very interesting and promising.

Here are some general thoughts and questionsabout DMIP :

* As the source code of DMIP is not available, it seems impossible to build a node that would have 3 or 4 source images. The 2 sources limit isby design ? There are some cases where I would like to have three inputs: two images and a store, or more images.

* The store mechanism is very elegant, does DMIP provide nodes that operates only on stores (ie storeResult = f(store1,store2) ?How do I build a store containing serveral Dynamic stores (computed from the graph),as a node an only have a single input store ?

* As far as I understood, it is impossible now to change the size of an image in a node (ie a 'resize' node) within a graph. I must split my graph, and call in betweenlow level IPP functions (ie ippiResize_). Many nodes I intend to write will geometrically modify the image, with inputSize != outputSize. Cropping after the nodewould not bevery efficient :).

* I'd like to know how DMIP behaves when dealing with geometric transforms (ie an example source code of an efficient'rotate' node would be very interesting). How DMIP will split the source image to be efficient in term of cache ?

* Many of my nodes will use accumulation buffers: a source pixel will be "spread" on many destination pixels using various geometric techniques. Later, the accumulation buffer is normalized. How can DMIP handle such cases ? This is a tricky parallel problem, as two threads processing distinct source pixel tiles can be accumulated in the same destination pixels. Or accumulation buffers can be distinct (in stores ?), and be merged later (involving a lot of nodes , because of the 2 sources limit)

* I'd like to know how DMIP behaves when fed with large graphes (involving a large number of nodes (more than 1000) on megapixel images): does it includes a memory manager ? Is there a way to get control on the graph traversing order ? As some of our nodes will allocate some memory, can I control when the Node::Free() method is called ?

* Given a graph, does DMIP keeps track of already computed nodes ? For example, you can imagine a graph whereonly onesource image change (ie retrieved from a stream). Only a small part of the graph needs to be computed again. Do I have to manage "dirty flags" myself (ie compute and give to DMIP the small graph that has to be recomputed), or does DMIP handle "dirty flags" ?

* In a more general way, I feel that the DMIP source code should be available somehow, in a whole or at least part of it (nodes). It would greatly help 3rdparty node writers. Also, as we'd like to implement some graph traversingorder to adress memory issues in large graphes, the graph optimization or execution should be accesible (actually, the Graph::Execute() or Graph::Optimise() methods are not virtual).

Best regards
Olivier

[Vladimir_Dudnik]

Hi Oliver,

many thanks for sharing your thoughts and questions. We will take a time to discuss your feedback in the team and then come back to you.

Could you please share sample code where you met exceptions with DMIP, so we would analyse if everything was OK on calling side?

Regards,
Vladimir

[Oliver]

Vladimir,
All the exceptions I met were related to the issue you described: freeing a graph, or a node or an image after a graph computation.
ie in DMIP_modify_brightness() in dmip_example.cpp
Src = new Image ((Ipp8u*)input->DataPtr(), ipp8u, ippC3, roi, input->Step());
SrcNode *srcNode=new SrcNode();
srcNode->Init(Src);
... graph computation ...

delete srcNode; // goodbye :)
I made several experiments in other languages (Python, C#...) after the creation of bindings with SWIG. Using SWIG gives you less control on when the C++ objects are deleted.
So I *really* need a non crashing library to tease people here :)
Olivier

[Vladimir_Dudnik]

Hi Oliver,

to avoid this issue you need to define DMIP_DLL_IMPORT macro for your application build. Sorry, it was not mentioned in DMIP documentation.

Regards,
Vladimir