headers
Boehm, Hans | 4 May 2008 03:24
Picon
Favicon

RE: Memory leak located (corrected error in Map)!

Thanks for the suggestion, and apologies for the confusion.  I updated gcinterface.html on the web site and
in the distribution to hopefully make this clearer.

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of Christophe Meessen
> Sent: Saturday, April 26, 2008 4:25 PM
> To: gc@...
> Subject: Re: [Gc] Memory leak located (corrected error in Map)!
>
> Sorry, I made an error with std::map.
>
> Christophe Meessen a écrit :
> > For the map, instead of
> >   std::map< KeyType, MyType >
> >
> > one has to write
>
> std::map< KeyType, MyType, std::less< KeyType >,
>        gc_allocator<std::pair< const KeyType, MyType> > >
>
> Note that this is only required when used for member
> variables of a class without finalizer.
>
> An example of these on the libgc web site would have saved me
> hours of work to locate the memory leak. It was not obvious
> from the current documentation.
> _______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Boehm, Hans | 4 May 2008 03:28
Picon
Favicon

gc-7.1

I finally decided to call the current tree GC7.1.  It can be downloaded from the usual place at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.1.tar.gz .

This fixes a significant number of bugs relative to 7.0.

Hans
Permalink | Reply | 2 comments |
headers
Christophe Meessen | 6 May 2008 13:00
Picon
Picon

Re: Memory leak located (corrected error in Map)!

Boehm, Hans a écrit :
> Thanks for the suggestion, and apologies for the confusion.  I updated gcinterface.html on the web site
and in the distribution to hopefully make this clearer.
>   
For strings I finally do something like this
typedef std::basic_string<char, char_traits<char>, gc_allocator<char> > 
gc_string;
Same for wchat_t to get a gc_wstring. This is really simple to use. It 
is just unfortunate that implicit conversion between string and 
gc_string are not implicit. The code now works perfectly on vc++ 2003 
and with g++ on linux. I still have to check with multithreading.

For the containers, I is also unfortunate that we can't define templated 
typedefs. We'll have to wait for the next C++ standard for this. It will 
then be possible to define things like gc_vector, gc_map.

Good news about the 7.1 release. Congratulations and thank you very much 
for this remarkable tool.

--

-- 
Bien cordialement,

Ch. Meessen
Permalink | Reply | 1 comment |
headers
Shiro Kawai | 6 May 2008 16:15
Favicon

DONT_ADD_BYTE_AT_END and GC_malloc(0) (gc-7.1)

(Note for the list adminstrator: I posted this from a different
address and it's being held for approval; please discard it.)

We found that gctest of gc-7.1 may abort or enter an infinite loop
if the gc code is compiled with -DDONT_ADD_BYTE_AT_END=1.
Specifically, it aborts on MacOSX Leopard and it randomly enters
infinite loop on Linux/x86 2.6.24 w/ gcc 4.1.2

We found that the problem occurs in a collection triggered
within this loop (tests/test.c line 1143):

        {
	   size_t i;
	   for (i = 0; i < 10000; ++i) {
	     GC_MALLOC(0);
	     GC_FREE(GC_MALLOC(0));
	     GC_MALLOC_ATOMIC(0);
	     GC_FREE(GC_MALLOC_ATOMIC(0));
	   }
	 }

Commenting out the two GC_FREE lines stops the abnormal behavior.

One possible explanation I came up is that, with DONT_ADD_BYTE_AT_END,
a pointer that points to just past an allocated object doesn't prevent
the object to be collected, and since the returned pointer of
GC_MALLOC(0) logically points to "just past" the imaginary zero-byte
object, so it may be reclaimed between GC_MALLOC(0)'s return and
the call of GC_FREE, causing already collected pointer to be passed
to GC_FREE, which eventually does harm to gc internals.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Boehm, Hans | 7 May 2008 00:03
Picon
Favicon

RE: mips support broken in gc-7.x

Looking at the code, you are clearly correct.  I  had largely forgotten about that problem.  We need at least
minimal atomic_ops support for mips.  If someone can adapt, for example, cris.h in the atomic_ops-1.2
part of the tree, that should be sufficient for at least basic functionality.  I might be able to try, but I'm
not sure I still have access to a machine on which I can test.

There is a bit of a complication here in that it's hard to do this really correctly, we need an accurate
description of the MIPS memory consistency model.  My understanding is that that's currently more
dependent on the individual chip vendor than some of us would like.  I have some idea what it should be for old
SGI machines, but I suspect that's no longer the primary concern here.  I haven't checked on this in a while,
so things may be better now.

Hans

-----Original Message-----
From: gc-bounces@...
[mailto:gc-bounces@...] On Behalf Of Christian Thalinger
Sent: Monday, May 05, 2008 12:38 AM
To: gc@...
Subject: [Gc] mips support broken in gc-7.x

Hi!

I want to update to gc-7.x because of some additional functions which are very handy in a JVM.  But it seems
that MIPS support is broken:

atomic_ops.c:74: error: parse error before "AO_locks"
atomic_ops.c:75: error: `AO_TS_CLEAR' undeclared here (not in a function)
atomic_ops.c:75: error: initializer element is not constant
atomic_ops.c:75: error: (near initialization for `AO_locks[0]')
(Continue reading)

Permalink | Reply | 14 comments |
headers
Christian Thalinger | 5 May 2008 09:37
Picon
Favicon

mips support broken in gc-7.x

Hi!

I want to update to gc-7.x because of some additional functions which
are very handy in a JVM.  But it seems that MIPS support is broken:

atomic_ops.c:74: error: parse error before "AO_locks"
atomic_ops.c:75: error: `AO_TS_CLEAR' undeclared here (not in a function)
atomic_ops.c:75: error: initializer element is not constant
atomic_ops.c:75: error: (near initialization for `AO_locks[0]')

Is MIPS not supported at all anymore or is this just a bug?

- twisti
Permalink | Reply | 15 comments |
headers
Friedrich Dominicus | 9 May 2008 15:36

Re: gc-7.1

2008/5/4 Boehm, Hans <hans.boehm@...>:
> I finally decided to call the current tree GC7.1.  It can be downloaded from the usual place at
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc-7.1.tar.gz .
>
> This fixes a significant number of bugs relative to 7.0.

Would you mind to tell us what the status of building a shared library
on Windows 64 bit
is? Can one expect that this will work or is this still unknown?

Regards
Friedrich
Permalink | Reply | 1 comment |
headers
Friedrich Dominicus | 9 May 2008 17:49

Re: gc-7.1

>
> Would you mind to tell us what the status of building a shared library
> on Windows 64 bit
> is? Can one expect that this will work or is this still unknown?
Ok I've checked with 7.1 and it seems that the crashes we encounterd
with earlier versions are not there any longer or not that obvioius.
So it seems something in the Thread handling and DLLMain has changed.
.....

Regards
Friedrich
Permalink | Reply | 0 comments |
headers
Florian Weimer | 9 May 2008 22:50
Picon

Re: Memory leak located (corrected error in Map)!

* Christophe Meessen:

> For the containers, I is also unfortunate that we can't define
> templated typedefs. We'll have to wait for the next C++ standard for
> this. It will then be possible to define things like gc_vector,
> gc_map.

Doesn't

  typename gc_vector<T>::type 

already work?  It's clumsy, but not too bad if T is not a dependent
template parameter and the typename is not part of the type expression.
Permalink | Reply | 0 comments |
headers
Boehm, Hans | 10 May 2008 02:41
Picon
Favicon

RE: DONT_ADD_BYTE_AT_END and GC_malloc(0) (gc-7.1)

Thanks.  This indeed looks like a bug to me.  I can reproduce the problem on Itanium Linux as well.

I'm still trying to track down the cause.

Probably the least painful workaround for now is not to define DONT_ADD_BYTE_AT_END.  As far as I can tell,
disabling thread-local allocation probably also works, but may lose more performance.

Hans

> -----Original Message-----
> From: gc-bounces@...
> [mailto:gc-bounces@...] On Behalf Of Shiro Kawai
> Sent: Tuesday, May 06, 2008 7:15 AM
> To: gc@...
> Cc: shiro@...
> Subject: [Gc] DONT_ADD_BYTE_AT_END and GC_malloc(0) (gc-7.1)
>
> (Note for the list adminstrator: I posted this from a
> different address and it's being held for approval; please
> discard it.)
>
> We found that gctest of gc-7.1 may abort or enter an infinite
> loop if the gc code is compiled with -DDONT_ADD_BYTE_AT_END=1.
> Specifically, it aborts on MacOSX Leopard and it randomly
> enters infinite loop on Linux/x86 2.6.24 w/ gcc 4.1.2
>
> We found that the problem occurs in a collection triggered
> within this loop (tests/test.c line 1143):
>
>         {
(Continue reading)

Permalink | Reply | 0 comments |

Gmane