Frank Hövermann | 5 May 21:07
Picon
Picon

Error after calling quantlib-c++-dll via swig-c#-interface

Hi there,
I think this is a matter of unproper garbage collection or something similar
but I need some guru advice: A properly coded function (in C++, some double*
serve as input, and a .txt or .csv file is the output but the function call
is like "void func_name(double *input, char *path)" so nothing is actually
returned) which does some calculations using some QuantLib objects somehow
changes its behaviour under /clr compiler option. This I need to be able to
use it via SWIG under C#. Calculations are done as supposed to, but upon C#
program termination an "unknown software exception" (0xc0020001) at
0x7c81eb33 pops up. I googled a bit and indications point to a too quick
(unmanaged) object disposal where the program terminates before the C++
object does. Does this sound familiar to one of you? Are there any hints to
prevent this?

Thanks in advance for any hints and best regards

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
Luigi Ballabio | 16 May 17:30
Picon

Re: Error after calling quantlib-c++-dll via swig-c#-interface

On Mon, 2008-05-05 at 21:09 +0200, Frank Hövermann wrote:
> I think this is a matter of unproper garbage collection or something similar
> but I need some guru advice: A properly coded function (in C++, some double*
> serve as input, and a .txt or .csv file is the output but the function call
> is like "void func_name(double *input, char *path)" so nothing is actually
> returned) which does some calculations using some QuantLib objects somehow
> changes its behaviour under /clr compiler option. This I need to be able to
> use it via SWIG under C#. Calculations are done as supposed to, but upon C#
> program termination an "unknown software exception" (0xc0020001) at
> 0x7c81eb33 pops up. I googled a bit and indications point to a too quick
> (unmanaged) object disposal where the program terminates before the C++
> object does. Does this sound familiar to one of you? Are there any hints to
> prevent this?

Hi Frank,
	unfortunately, I'm not an expert at all in managed C++/C#---my only
exposure to C# has been to compile the SWIG wrappers before release to
check that they work...  Did you try asking on the SWIG mailing list? It
doesn't seem a SWIG problem (since all you're exporting is a function
taking some basic types---no class instances are passing through the
wrapping layer) but there might be people there with more expertise.

Luigi

--

-- 

Dealing with failure is easy: work hard to improve. Success is also 
easy to handle: you've solved the wrong problem. Work hard to improve. 
-- Alan Perlis 

(Continue reading)

Frank Hövermann | 25 May 12:55
Picon
Picon

Re: Error after calling quantlib-c++-dll viaswig-c#-interface

Hi Luigi,
the solution was quite easy, since the c++-dlls are native ones, and the
call into any one such is by DllImport within the SWIG wrapper, you do not
have to include them as a reference in a c#-project, which I did. The only
one thing one has to do is to place the dll where the c# code is able to
find it. Then it works properly, fast, and without any load/unload errors as
described below.

Regards
Frank

> -----Ursprüngliche Nachricht-----
> Von: Luigi Ballabio [mailto:luigi.ballabio <at> gmail.com] 
> Gesendet: Freitag, 16. Mai 2008 17:30
> An: fhoevermann <at> gmx.de
> Cc: quantlib-dev <at> lists.sourceforge.net
> Betreff: Re: [Quantlib-dev] Error after calling 
> quantlib-c++-dll viaswig-c#-interface
> 
> 
> On Mon, 2008-05-05 at 21:09 +0200, Frank Hövermann wrote:
> > I think this is a matter of unproper garbage collection or 
> something 
> > similar but I need some guru advice: A properly coded function (in 
> > C++, some double* serve as input, and a .txt or .csv file is the 
> > output but the function call is like "void func_name(double *input, 
> > char *path)" so nothing is actually
> > returned) which does some calculations using some QuantLib 
> objects somehow
> > changes its behaviour under /clr compiler option. This I 
(Continue reading)


Gmane