Memory allocation - memory not freed in DD?

[dkastl]

As reported by this user there seems to be a memory allocation problem in DD.
http://lists.osgeo.org/pipermail/pgrouting-users/2011-August/000771.html

[kweninger]

Changing the function drivedist.c solves the problem. The memory can be freed after copying data to postgres data structure, when query is finished.

Changes to drivedist.c (end of file)

#endif
DBG("Returning value");
free ((void *)path); // adding missing memory release
SRF_RETURN_DONE(funcctx);
}
}

[dkastl]

Thanks a lot for digging into this!

[christiangda]

Nice solution, see issue #46

[dkastl]

Hi Christian!
So you think this solves issue #46 ?

[kweninger]

Hi all!

Without having checked the code, there is certain probability that the issue
is the same in this library too.

Best Regards,

Kurt

-----Ursprüngliche Nachricht-----
Von: Daniel Kastl
[mailto:reply+i-1527518-9ddb48598fb65c4d151ed890a0f4cbb0891ff68c-1028419@rep
ly.github.com]
Gesendet: Mittwoch, 16. November 2011 02:55
An: kweninger
Betreff: Re: [pgrouting] Memory allocation - memory not freed in DD? (#42)

Hi Christian!
So you think this solves issue #46 ?

---

Reply to this email directly or view it on GitHub:
#42 (comment)

[christiangda]

Well, I hope it. If you read the documentation in the links, you can call
a "c" function into "c++" code. Now, how do you apply it?, well, just now
I don't know, but if you or somebody have more experience programing in
"c", maybe could implemented it.
Then we can used valgrind tool to check it!.

Christian

2011/11/15 Daniel Kastl <
reply@reply.github.com

Hi Christian!
So you think this solves issue #46 ?

---

Reply to this email directly or view it on GitHub:
#42 (comment)

Atentamente,
Christian Gonzalez

[christiangda]

Hi Daniel,

I found it on PostgreSQL documentation.

Link: http://developer.postgresql.org/pgdocs/postgres/xfunc-c.html
35.9.12. Using C++ for Extensibility

Although the PostgreSQL backend is written in C, it is possible to write
extensions in C++ if these guidelines are followed:

All functions accessed by the backend must present a C interface to the
backend; these C functions can then call C++ functions. For example, extern
C linkage is required for backend-accessed functions. This is also
necessary for any functions that are passed as pointers between the backend
and C++ code.

Free memory using the appropriate deallocation method. For example, most
backend memory is allocated using palloc(), so use pfree() to free it.
Using C++ delete in such cases will fail.

Prevent exceptions from propagating into the C code (use a catch-all
block at the top level of all extern C functions). This is necessary
even if the C++ code does not explicitly throw any exceptions, because
events like out-of-memory can still throw exceptions. Any exceptions must
be caught and appropriate errors passed back to the C interface. If
possible, compile C++ with -fno-exceptions to eliminate exceptions
entirely; in such cases, you must check for failures in your C++ code, e.g.
check for NULL returned by new().

If calling backend functions from C++ code, be sure that the C++ call
stack contains only plain old data structures (POD). This is necessary
because backend errors generate a distant longjmp() that does not
properly unroll a C++ call stack with non-POD objects.

In summary, it is best to place C++ code behind a wall of extern
Cfunctions that interface to the backend, and avoid exception, memory,
and
call stack leakage.

Christian

2011/11/16 Christian F. Gonzalez Di Antonio christiangda@gmail.com

Well, I hope it. If you read the documentation in the links, you can
call a "c" function into "c++" code. Now, how do you apply it?, well, just
now I don't know, but if you or somebody have more experience programing
in "c", maybe could implemented it.
Then we can used valgrind tool to check it!.

Christian

2011/11/15 Daniel Kastl <
reply@reply.github.com

Hi Christian!
So you think this solves issue #46 ?

---

Reply to this email directly or view it on GitHub:
#42 (comment)

Atentamente,
Christian Gonzalez

Atentamente,
Christian Gonzalez

[christiangda]

Hi againt Daniel,

If we analize these code line from link:
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html

[32.3] How can I include a non-system C header file in my C++ code?

If you are including a C header file that isn't provided by the system, you
may need to wrap the #include line in an extern "C" { /.../ } construct.
This tells the C++ compiler that the functions declared in the header file
are C functions.
// This is C++ code

extern "C" {
// Get declaration for f(int i, char c, float x)
#include "my-C-code.h"
}

int main()
{
f(7, 'x', 3.14); // Note: nothing unusual in the call
...
}

All we have to do to solve the problem is:

add to file boost_wrapper.cpp

extern "C" {
#include "utils/palloc.h"
}
...

*path = (path_element_t *) palloc(sizeof(path_element_t) *
(path_vect.size() + 1));

...

Let me know waht do you think.

Christian

2011/11/16 Christian F. Gonzalez Di Antonio christiangda@gmail.com

Hi Daniel,

I found it on PostgreSQL documentation.

Link: http://developer.postgresql.org/pgdocs/postgres/xfunc-c.html
35.9.12. Using C++ for Extensibility

Although the PostgreSQL backend is written in C, it is possible to write
extensions in C++ if these guidelines are followed:

All functions accessed by the backend must present a C interface to
the backend; these C functions can then call C++ functions. For example, extern
C linkage is required for backend-accessed functions. This is also
necessary for any functions that are passed as pointers between the backend
and C++ code.

Free memory using the appropriate deallocation method. For example,
most backend memory is allocated using palloc(), so use pfree() to
free it. Using C++ delete in such cases will fail.

Prevent exceptions from propagating into the C code (use a catch-all
block at the top level of all extern C functions). This is necessary
even if the C++ code does not explicitly throw any exceptions, because
events like out-of-memory can still throw exceptions. Any exceptions must
be caught and appropriate errors passed back to the C interface. If
possible, compile C++ with -fno-exceptions to eliminate exceptions
entirely; in such cases, you must check for failures in your C++ code, e.g.
check for NULL returned by new().

If calling backend functions from C++ code, be sure that the C++ call
stack contains only plain old data structures (POD). This is necessary
because backend errors generate a distant longjmp() that does not
properly unroll a C++ call stack with non-POD objects.

In summary, it is best to place C++ code behind a wall of extern Cfunctions that interface to the backend, and avoid exception, memory, and
call stack leakage.

Christian

2011/11/16 Christian F. Gonzalez Di Antonio christiangda@gmail.com

Well, I hope it. If you read the documentation in the links, you can

call a "c" function into "c++" code. Now, how do you apply it?, well, just
now I don't know, but if you or somebody have more experience programing
in "c", maybe could implemented it.
Then we can used valgrind tool to check it!.

Christian

2011/11/15 Daniel Kastl <
reply@reply.github.com

Hi Christian!
So you think this solves issue #46 ?

---

Reply to this email directly or view it on GitHub:
#42 (comment)

Atentamente,
Christian Gonzalez

Atentamente,
Christian Gonzalez

Atentamente,
Christian Gonzalez

[bjornharrtell]

Tried this and it seem to work but introduces crashes after 10> calls :(

For reference, trying to use palloc in C++ without extern "C" cases undefined symbol crashes in runtime.

[woodbri]

I merged Pull Request #67 into sew-devel-2_0, but I'll add a 1.x tag for this.

[woodbri]

Closing - Wont fix.