headers
SourceForge.net | 3 Feb 07:57
Picon

[ swig-Bugs-3447426 ] memory leak in vector.__getitem__

Bugs item #3447426, was opened at 2011-12-01 12:57
Message generated for change (Comment added) made by wsfulton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3447426&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: szager (szager)
Assigned to: szager (szager)
Summary: memory leak in vector.__getitem__

Initial Comment:
>From the swig-user mailing list:

On Thu, Dec 1, 2011 at 3:38 AM, Andrew Ward <andrew.derek.ward <at> gmail.com> wrote:

> In the process I have found a bug in the Python std::vector implementation.
> The __getitem__ method has two versions, one takes an index, the other takes
> a slice object. The version that takes a slice object returns a new std::vector
> but does not use SWIG_POINTER_OWN and therefore leaks memory.

----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 9 Feb 13:00
Picon

[ swig-Patches-3486202 ] Allow use of malloc() in C++ mode

Patches item #3486202, was opened at 2012-02-09 04:00
Message generated for change (Tracker Item Submitted) made by kwwette
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3486202&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Karl Wette (kwwette)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow use of malloc() in C++ mode

Initial Comment:
I would like to be able to make SWIG use malloc() for memory allocation in typemaps (using %new_instance,
et. al), even when compiling in C++ mode. The reason is basically that malloc() is easier to replace with a
custom allocation function than new(). For example, if I have a custom string type that needs to be
allocated using a custom allocation function, I can do something like:

#define malloc MyStringMalloc
%fragment("SWIG_FromMyStringPtrAndSize" ...
%typemaps_string(...)
#undef malloc

and still re-use SWIG's typemaps for strings using MyStringMalloc() instead of malloc().
(Continue reading)

Permalink | Reply | 1 comment |
headers
SourceForge.net | 9 Feb 13:00
Picon

[ swig-Patches-3486202 ] Allow use of malloc() in C++ mode

Patches item #3486202, was opened at 2012-02-09 04:00
Message generated for change (Settings changed) made by kwwette
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3486202&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Karl Wette (kwwette)
>Assigned to: William Fulton (wsfulton)
Summary: Allow use of malloc() in C++ mode

Initial Comment:
I would like to be able to make SWIG use malloc() for memory allocation in typemaps (using %new_instance,
et. al), even when compiling in C++ mode. The reason is basically that malloc() is easier to replace with a
custom allocation function than new(). For example, if I have a custom string type that needs to be
allocated using a custom allocation function, I can do something like:

#define malloc MyStringMalloc
%fragment("SWIG_FromMyStringPtrAndSize" ...
%typemaps_string(...)
#undef malloc

and still re-use SWIG's typemaps for strings using MyStringMalloc() instead of malloc().
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 10 Feb 20:49
Picon

[ swig-Bugs-3486623 ] intmax_t incorrectly interprited on 64bit linux

Bugs item #3486623, was opened at 2012-02-10 11:49
Message generated for change (Tracker Item Submitted) made by sutasu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3486623&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stanislav Tereshchenko (sutasu)
Assigned to: Nobody/Anonymous (nobody)
Summary: intmax_t incorrectly interprited on 64bit linux

Initial Comment:
Attached is a simple test which demonstrates a problem. It fails to compile swig generated c++ file. When in
interface file macro definition for SWIGWORDSIZE64 is uncommented the problem disappears. I believe
the issue is that this macro is not internally defined in swig for 64bit linux so /usr/include/stdint.h
and stdint.i are not compatible.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3486623&group_id=1645

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 11 Feb 03:00
Picon

[ swig-Patches-3486688 ] Java director connector not thread safe

Patches item #3486688, was opened at 2012-02-10 18:00
Message generated for change (Tracker Item Submitted) made by coleb2
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3486688&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Cole (coleb2)
Assigned to: Nobody/Anonymous (nobody)
Summary: Java director connector not thread safe

Initial Comment:
The 'swig_connect_director' generated method is not thread safe due to the use of two function local
static variables. The following patch fixes the problem (we are resorting to post-processing the swig
output to fix the problem). 

Index: Source/Modules/java.cxx
===================================================================
--- Source/Modules/java.cxx	(revision 12905)
+++ Source/Modules/java.cxx	(working copy)
@@ -4272,11 +4272,11 @@
     else
       internal_classname = NewStringf("%s", classname);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Beare | 13 Feb 01:33
Picon

Improving R bindings to SimpleITK

Hello,
I'm working on the R bindings to SimpleITK, a large c++ imaging
library. SimpleITK uses a lot of stl::vectors to represent quantities
like coordinates, image sizes, sizes of filtering kernels and so on,
and one suggestion was that the package would be a lot nicer if these
were translated to R vectors by the swig layers. I've done this by
adding traits_asptr and traits_from_ptr routines derived from the
python equivalents. I can now do something like

im <- ReadImage('cthead1.png')
sp <- im$GetSpacing()

# sp is an R vector

sp <- sp + 1

im$SetSpacing(im, sp)

and everything works nicely.

However I've noticed an unfortunate side effect of this change that
I'd like to eliminate. Many classes in SimpleITK include convenience
methods that allow vector quantities to be set to the same value. For
example, a filtering class might have two SetRadius methods, one
taking a single integer argument and the other taking a vector. When
the vector was represented as an external reference in R with a
special class it was possible for swig to generate appropriate
dispatching functions. After replacing the external references to stl
vectors with R vectors the dispatching is no longer possible because
in R the class for a vector or a single number is the same (integer or
(Continue reading)

Permalink | Reply | 4 comments |
headers
daspostloch | 13 Feb 12:27

Re: Python and new release

William S Fulton <wsf <at> fultondesigns.co.uk> writes:

>
> I'm thinking of releasing 2.0.5 as it has been sometime since our last
> release. I've been fixing recent regressions highlighted by the
> test-suite and the main issues left are in Python. Stefan, could you
> look at r12843 and r12844 again as they break the primitive_types and
> li_cmalloc tests. The other broken one is li_boost_shared_ptr which I
> need looking at from a regression I introduced in r12776/77.
>
> Anyone looking for a challenge, can try and solve this:
>
> checking testcase threads_exception (with run test) under python
> Traceback (most recent call last):
>    File "./threads_exception_runme.py", line 29, in <module>
>      raise RuntimeError
> RuntimeError
> make[1]: *** [threads_exception.cpptest] Error 1
>
> which is not very repeatable.
>
> Thanks
> William
>

Hi,

not sure if this is the correct place or way to report, but since it
is mentioned above as hard to reproduce: I do get the aforementioned
(Continue reading)

Permalink | Reply | 1 comment |
headers
SourceForge.net | 13 Feb 14:57
Picon

[ swig-Bugs-3486623 ] intmax_t incorrectly interprited on 64bit linux

Bugs item #3486623, was opened at 2012-02-10 11:49
Message generated for change (Comment added) made by kwwette
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3486623&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stanislav Tereshchenko (sutasu)
Assigned to: Nobody/Anonymous (nobody)
Summary: intmax_t incorrectly interprited on 64bit linux

Initial Comment:
Attached is a simple test which demonstrates a problem. It fails to compile swig generated c++ file. When in
interface file macro definition for SWIGWORDSIZE64 is uncommented the problem disappears. I believe
the issue is that this macro is not internally defined in swig for 64bit linux so /usr/include/stdint.h
and stdint.i are not compatible.

----------------------------------------------------------------------

Comment By: Karl Wette (kwwette)
Date: 2012-02-13 05:57

Message:
(Continue reading)

Permalink | Reply | 1 comment |
headers
SourceForge.net | 13 Feb 17:09
Picon

[ swig-Bugs-3486623 ] intmax_t incorrectly interprited on 64bit linux

Bugs item #3486623, was opened at 2012-02-10 11:49
Message generated for change (Comment added) made by sutasu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101645&aid=3486623&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: python
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stanislav Tereshchenko (sutasu)
Assigned to: Nobody/Anonymous (nobody)
Summary: intmax_t incorrectly interprited on 64bit linux

Initial Comment:
Attached is a simple test which demonstrates a problem. It fails to compile swig generated c++ file. When in
interface file macro definition for SWIGWORDSIZE64 is uncommented the problem disappears. I believe
the issue is that this macro is not internally defined in swig for 64bit linux so /usr/include/stdint.h
and stdint.i are not compatible.

----------------------------------------------------------------------

>Comment By: Stanislav Tereshchenko (sutasu)
Date: 2012-02-13 08:09

Message:
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 15 Feb 01:57
Picon

[ swig-Patches-3487706 ] ptrdiff_t

Patches item #3487706, was opened at 2012-02-14 16:57
Message generated for change (Tracker Item Submitted) made by btrotter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3487706&group_id=1645

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brett Trotter (btrotter)
Assigned to: Nobody/Anonymous (nobody)
Summary: ptrdiff_t

Initial Comment:
With gcc 4.6, we start to see problems in areas of swig where things are not wrapped in namespace std, but use
ptrdiff_t without the std:: namespace prefix. Attached is a patch that seems to fix the issues I was seeing.

note the patch is against the fedora 15 SRPM, after the other two patches.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=301645&aid=3487706&group_id=1645

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane