On Tue, Dec 2, 2014 at 1:47 AM, Ernst-Georg Schmid <
ernst-georg.sch...@bayer.com> wrote:
> Hello,
>
> I'm using the following code to convert molfiles to PNG with
> Openbabel-2.3.2 on Ubuntu 14.04 LTS:
>
> typedef struct
> {
> size_t datasz;
> char data[1];
> } _PNG;
>
> extern "C" _PNG *
> ob_molfile_to_png (char *molfile, int w, int h)
> {
> OBMol mol;
> OBConversion conv;
> string tmpStr (molfile);
> string outstr;
> istringstream molstream (tmpStr);
> ostringstream PNGstream,_w,_h;
> _PNG *tmpPNG;
> size_t PNG_size;
>
> _w << w;
> _h << h;
>
> conv.SetInAndOutFormats ("MDL", "_png2");
> conv.AddOption ("d", OBConversion::OUTOPTIONS);
> conv.AddOption ("gen2D", OBConversion::OUTOPTIONS);
> conv.AddOption ("w", OBConversion::OUTOPTIONS,_w.str().c_str());
> conv.AddOption ("h", OBConversion::OUTOPTIONS,_h.str().c_str());
>
> conv.Read (&mol, &molstream);
>
> if (mol.Empty ())
> return NULL;
>
> conv.Write (&mol, &PNGstream);
>
> outstr = PNGstream.str();
>
> PNG_size = outstr.length();
>
> tmpPNG = (_PNG*) malloc (sizeof(_PNG)+PNG_size);
>
> tmpPNG->datasz = PNG_size;
>
> memcpy(tmpPNG->data,outstr.c_str(),PNG_size);
>
> return (tmpPNG);
> }
>
> This works, but for 500x500 images, it takes about 1MB of RAM per image.
> The amount of memory used is bound to the requested size of the image.
>
> Since this is running in a database context, the memory is held for all
> images converted until I close the connection, which could make the Linux
> server run out of memory.
>
> I am freeing the malloc'ed memory returned from this function properly, so
> I suspect that something in Openbabel or Cairo is holding memory references
> longer than needed.
>
> Please could somebody clarify on that? Is it expected behavior, a bug, or
> am I plainly doing something wrong?
>
The first thing I'd suggest is to take the same code and write a simple
wrapper outside of the database context, a test program that you can run
against a few hundred molecules, and verify that it's growing. If it seems
to be leaking, use valgrind(1) to track down the problem. Valgrind is
amazing.
Some databases (Postgres, I don't know about MySQL or Alice) strongly
recommend that you use their built-in allocator rather than using malloc.
It makes it difficult to link in code like OpenBabel. Postgres is written
in C, and OpenBabel in C++. I've had so many problems trying to get
OpenBabel to behave inside of a Postgres executable that I gave up and now
use OpenBabel in a Fast-CGI wrapper to provide a scalable, parallelizable
remote-procedure-call mechanism that I can access from Perl, PHP, C or C++.
As much as I like OpenBabel, it's not reliable enough to trust inside the
executable of a database. It's a good way to corrupt your entire database
and lose everything. If your database has a public web site, you're giving
the public a loaded gun.
Cheers,
Craig
>
> Best regards,
>
> Ernst-Georg
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> OpenBabel-Devel mailing list
> OpenBabel-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbabel-devel
>
--
---------------------------------
Craig A. James
Chief Technology Officer
eMolecules, Inc.
---------------------------------
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
OpenBabel-Devel mailing list
OpenBabel-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openbabel-devel
