gmane.comp.programming.garbage-collection.boehmgc

Using GC in C++ via multiple inheritance

Shriramana Sharma — 2013-04-13T05:12:27

Hello. I've been refactoring parts of Asymptote (asymptote.sf.net)
code for inclusion into my own project and was hence introduced to GC.
I understand that by subclassing a new class I create say MyClass from
class gc, instances of MyClass will be garbage collected since
operator new for it is now overloaded to use GC_MALLOC. However, I'd
like to clarify one thing:

If I have to create MyClass as a subclass of a LibraryClass which
doesn't use gc, is it sufficient for me to multiply inherit from gc
and do:

class MyClass : public LibraryClass, public gc {
...
} ;

so that new-ed instances of MyClass will be garbage collected
including the LibraryClass sub-objects within them? I hope so, but I
didn't want to assume, so am asking for this clarification here.

Note that I am not an expert programmer, only an intermediate one, so
I may require more explanations than others. Thank you for your time
and patience.

--
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Silently fails to allocate memory?

The Devils Jester — 2013-04-12T21:51:53

It is difficult to describe the issue I am having with libgc.

I have a for loop that allocates thousands of (small) objects. Each
iteration of the loop only allocates a few new objects, but when the loop
is sufficiently large (usually around 3500 iterations), then for some
reason it just...well gives up. It does not hang or segfault, or give any
indication that something is wrong, but it (and this is difficult to
determine) seems to silently stop allowing the objects to be created.

If I disable libgc (or manually call delete, which is not a working long
term solution), the loop executes correctly. This is on Ubuntu Linux using
GCC 4.7 .

On Mac OS X, I cannot tell if its working (which it appears to be) or if
the limit to "give up" is might higher.

Is there some trick to this? Am I using it wrong? How I am using libgc is
by simply including "gc_cpp.h" calling "GC_INIT" and having my class(es)
inherit from gc.
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

[win32] Isn't this a race condition?

Dave Korn — 2013-04-11T00:58:56

    Hi list,

  In the (admittedly somewhat old) version of boehm-gc in the GCC source tree,
I see the following failure from thread_leak_test about 50% of the time (out
of 200 testruns):


  It's coming from GC_suspend in win32_threads.c, relevant snippets shown below:

/* Suspend the given thread, if it's still active.      */
STATIC void GC_suspend(GC_thread t)
{
    [ ... snip ... ]
    DWORD exitCode;
    [ ... snip ... ]
    if (GetExitCodeThread(t -> handle, &exitCode) &&
        exitCode != STILL_ACTIVE) {
#     ifdef GC_PTHREADS
        t -> stack_base = 0; /* prevent stack from being pushed */
#     else
        /* this breaks pthread_join on Cygwin, which is guaranteed to  */
        /* only see user pthreads                                      */
        GC_ASSERT(GC_win32_dll_threads);
        GC_delete_gc_thread_no_free(t);
#     endif
      return;
    }
    [ ... snip ... ]
# else /* !MSWINCE */
    if (SuspendThread(t -> handle) == (DWORD)-1)
      ABORT("SuspendThread failed");
# endif /* !MSWINCE */
  t -> suspended = (unsigned char)TRUE;
    [ ... snip ... ]
}

  Judging by reading the code, it seemed likely to me that there was a race
condition where a thread could still be active at the time GetExitCodeThread
was called, but then have exited by the time SuspendThread was called,
resulting in that call failing.  I modified that clause to read:

if (SuspendThread(thread_table[i].handle) == (DWORD)-1) {
  if (GetExitCodeThread(thread_table[i].handle,&exitCode) &&
            exitCode != STILL_ACTIVE) {
    ABORT("Race condition");
  }
  ABORT("SuspendThread failed");
}

i.e., it now checks again if the thread has exited when SuspendThread fails,
and now I occasionally see the "Race condition" message - although not often
(about 5% of tests); most often it still just shows the "SuspendThread failed"
message.  I suspect (but cannot prove) that during the thread shutdown code in
the windows kernel, there is a stage at which it stops being suspendable
before the final exit code is stored.

  In the HEAD version of bdwgc, analogous code still exists in
win32_threads.c/GC_suspend(), but I don't see it fail (in 200 tests).

  Does anyone know why it's no longer a problem?  I note that an awful lot has
changed in the rest of the test infrastructure, perhaps there's some more
locking somewhere (parallel marking?) that prevents the problem from arising.

    cheers,
      DaveK

opposite of GC_exclude_static_roots

Basile Starynkevitch — 2013-04-02T12:46:19

Hello All

My understanding is that when mmap-ing (on GNU/Linux/Debian/Sid/x86-64) some textual 
(e.g. JSON or XML) file segment, it is better to inform the GC using 
GC_exclude_static_roots to avoid scanning it.

However, I don't understand what should I do when I am munmap-ing that file segment
because I have finish dealing with that file and that segment.
Or maybe it does not matter (e.g. because the GC is internally using /proc/self/maps)?

Or does GC_exclude_static_roots should only be used for some huge global or static 
pointer-less array?

Regards.

Mark with offset

Niklas Therning — 2013-03-31T12:48:49

Hi,

In RoboVM we're representing Java Object arrays of length n like this:

{
  Class* arrayClass;
  Monitor lock;
  int32_t length;
  Object* values[n];
}

We would like the GC to scan structures like this precisely which means
that only the values should be scanned. Is there anyway we can tell the GC
to skip the first 3 fields? There doesn't seem to be a way to express this
using the descriptors in gc_mark.h?

We've tried to use a custom mark proc but quickly ran into mark stack
overflows for large arrays. Maybe there's a better way than to just
call GC_MARK_AND_PUSH() for each value in the array from the custom mark
proc? Maybe GC_push_all() can be used somehow?

/Niklas
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

Minor autoconf problem (FYI)

2013-03-30T08:07:23

Hi Ivan,

I'm trying to use the experimental version of the collector. I have followed
the steps indicated on the web page. That is:

   cd D
   git clone git://github.com/ivmai/libatomic_ops.git
   git clone git://github.com/ivmai/bdwgc.git
   ln -s  D/libatomic_ops D/bdwgc/libatomic_ops
   cd bdwgc
   autoreconf -vif
   automake --add-missing
   ./configure
   make

It fails on my machine (an ArchLinux using autoconf 2.69-1), with the 
following error message:

   moab:.../GC/bdwgc> autoreconf -vif
   autoreconf: Entering directory `.'
   autoreconf: configure.ac: not using Gettext
   autoreconf: running: aclocal --force -I m4
   configure.ac:24: error: 'AM_CONFIG_HEADER': this macro is obsolete.
       You should use the 'AC_CONFIG_HEADERS' macro instead.
   /usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expanded from...
   configure.ac:24: the top level
   autom4te: /usr/bin/m4 failed with exit status: 1
   aclocal: error: echo failed with exit status: 1
   autoreconf: aclocal failed with exit status: 1

Replacing AM_CONFIG_HEADER with AC_CONFIG_HEADERS as adviced by the error
makes it. 

I hope this will help.

Cheers,

Defining USE_LIBC_PRIVATES on all glibc systems

Ludovic Courtès — 2013-03-28T22:31:38

Hello,

Currently ‘USE_LIBC_PRIVATES’ is disabled by default, and only checked
on GNU/Linux.  The default on GNU/Linux is to get info from /proc.

What about using it unconditionally on glibc systems?

On GNU/Linux, that would work even in situations where /proc is
unavailable (such as during early boot), and would be more efficient.

It would also simplify things for GNU/kFreeBSD and GNU/Hurd, and allow
(for instance) calls to ‘GC_INIT’ from a secondary thread (as in
tests/initsecondarythread.c) on these platforms.

Here’s a tentative patch:


Thanks,
Ludo’.
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

32-bit on 64-bit machine

Margaret Fleck — 2013-03-18T23:28:13

If I'm compiling on a 64-bit (linux) machine, what do I need to do to
force the gc to compile in 32-bit mode?    (I need to link it to an old
32-bit application that will take some thought to move over to 64-bit.

Thanks,

Margaret Fleck
Spam detection software, running on the system "madara.hpl.hp.com", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
<Postmaster-sDzT885Ts8HQT0dZR+AlfA< at >public.gmane.org> for details.

Content preview:  If I'm compiling on a 64-bit (linux) machine, what do I need
   to do to force the gc to compile in 32-bit mode? (I need to link it to an
   old 32-bit application that will take some thought to move over to 64-bit.
   [...] 

Content analysis details:   (-1.1 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.8 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
-1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                            [score: 0.0000]
 0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay lines


_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

Collection from unknown thread with iOS simulator

Joa Ebert — 2013-03-12T20:03:20

Hi,

I am running into some issues with the iPhone simulator when using the GC
7.2 and 7.2d. Basically the issue is that I get a "Collecting from unknown
thread" error.

First of all the GC is configured with

CFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
CPPFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
LDFLAGS="-arch i386 -isysroot $SDK_LIB -Wl,-syslibroot $SDK_LIB"

./configure --disable-dependency-tracking --host=arm-apple-darwin
--enable-cplusplus --enable-static --disable-shared
--enable-thread-local-alloc --enable-parallel-mark
--enable-threads=pthreads --prefix=/Users/joa/Development/libgc

I am also running into the issue when I specify --enable-threads=posix.
This is how I include the header files:

#define GC_THREADS
#define GC_NOT_DLL
#define GC_OPERATOR_NEW_ARRAY

#include <gc/gc.h>
#include <gc/gc_cpp.h>

When the program starts I do call GC_INIT(). So from this perspective
everything should be fine. But unfortunately the simulator spawns a thread
that is not tracked by the GC causing this error.

I have tried several solutions like GC_use_threads_discovery before GC_INIT
without success. This ends in SIGABRT with "Darwin task-threads-based stop
and push unsupported".

The operating system is Mac OS X 10.6 and the simulator uses SDK version
4.3 in case that matters for you.

This is the trace of the offending thread as it seems:

#0  0x90aa20ee in __semwait_signal_nocancel ()
#1  0x90aa1fd2 in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x90b1cfb2 in usleep$NOCANCEL$UNIX2003 ()
#3  0x90b3e6f0 in abort ()
#4  0x00268f64 in GC_abort ()
#5  0x0026f9ee in GC_push_all_stacks ()
#6  0x0026a78b in GC_default_push_other_roots ()
#7  0x002678c9 in GC_push_roots ()
#8  0x00263d32 in GC_mark_some ()
#9  0x0025990a in GC_stopped_mark ()
#10 0x00259726 in GC_try_to_collect_inner ()
#11 0x0025ac48 in GC_collect_or_expand ()
#12 0x00261351 in GC_alloc_large ()
#13 0x00261896 in GC_generic_malloc ()
#14 0x00261e2e in GC_malloc_uncollectable ()
[...]
#25 0x90a62259 in _pthread_start ()
#26 0x90a620de in thread_start ()

I remember that I already had the collector working on an actual device a
while ago so I am a little bit confused about what is going on here.
Any help is greatly appreciated!


Best,

Joa
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

typed GC with marking routine...

Basile Starynkevitch — 2013-03-12T18:47:14

Hello All,

I'm interested in using Boehm's GC in a multi-threaded program 
(which I did not start coding yet) which will be a boostrapped compiler for some 
experimental eager language.

(BTW, I am a bit familiar with GC technology, I designed MELT http://gcc-melt.org/ 
which is a domain specific language to extend GCC, and MELT has a mostly copying precise GC 
and is a bootstrapped Lisp-like language translated to C)

FWIW, My debian/sid/x86-64 has libgc-dev version 1:7.1-9.1 but I also compiled the very latest git.

I would like to provide a "precise" marking routine (what exactly is its API) for every value in my language.
So I want to use Boehm's GC semi-precisely: conservatively for stacks, but precisely for GC-allocated heap values.

It seems that gc/gc_typed.h gives only the ability to have descriptors which are bit masks giving the pointers.

Is there a way (in the public GC API) to give a marking routine and to allocate values with it? 

[[IIRC, some slides by Hans Boehm mentioned this possibility]]

Cheers.

Collection from unknown thread with iOS simulator

Joa Ebert — 2013-03-12T17:10:46

Hi,

I am running into some issues with the iPhone simulator when using the GC
7.2 and 7.2d. Basically the issue is that I get a "Collecting from unknown
thread" error.

First of all the GC is configured with

CFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
CPPFLAGS="-DNO_DYLD_BIND_FULLY_IMAGE -arch i386 -isysroot $SDK_LIB"
LDFLAGS="-arch i386 -isysroot $SDK_LIB -Wl,-syslibroot $SDK_LIB"

./configure --disable-dependency-tracking --host=arm-apple-darwin
--enable-cplusplus --enable-static --disable-shared
--enable-thread-local-alloc --enable-parallel-mark
--enable-threads=pthreads --prefix=/Users/joa/Development/libgc

I am also running into the issue when I specify --enable-threads=posix.
This is how I include the header files:

#define GC_THREADS
#define GC_NOT_DLL
#define GC_OPERATOR_NEW_ARRAY

#include <gc/gc.h>
#include <gc/gc_cpp.h>

When the program starts I do call GC_INIT(). So from this perspective
everything should be fine. But unfortunately the simulator spawns a thread
that is not tracked by the GC causing this error.

I have tried several solutions like GC_use_threads_discovery before GC_INIT
without success. This ends in SIGABRT with "Darwin task-threads-based stop
and push unsupported".

The operating system is Mac OS X 10.6 and the simulator uses SDK version
4.3 in case that matters for you.

This is the trace of the offending thread as it seems:

#0  0x90aa20ee in __semwait_signal_nocancel ()
#1  0x90aa1fd2 in nanosleep$NOCANCEL$UNIX2003 ()
#2  0x90b1cfb2 in usleep$NOCANCEL$UNIX2003 ()
#3  0x90b3e6f0 in abort ()
#4  0x00268f64 in GC_abort ()
#5  0x0026f9ee in GC_push_all_stacks ()
#6  0x0026a78b in GC_default_push_other_roots ()
#7  0x002678c9 in GC_push_roots ()
#8  0x00263d32 in GC_mark_some ()
#9  0x0025990a in GC_stopped_mark ()
#10 0x00259726 in GC_try_to_collect_inner ()
#11 0x0025ac48 in GC_collect_or_expand ()
#12 0x00261351 in GC_alloc_large ()
#13 0x00261896 in GC_generic_malloc ()
#14 0x00261e2e in GC_malloc_uncollectable ()
[...]
#25 0x90a62259 in _pthread_start ()
#26 0x90a620de in thread_start ()

I remember that I already had the collector working on an actual device a
while ago so I am a little bit confused about what is going on here.
Any help is greatly appreciated!


Best,

Joa
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

bogus installed gc_config_macros.h

Andy Wingo — 2013-03-09T19:56:32

Hi,

I just cross-compiled libgc for mingw32, from a GNU/Linux system.  I
compiled it --enable-threads=pthreads, to rely on pthreads-win32.
However if in Guile I simply #define GC_THREADS and include <gc/gc.h>,
it defaults to auto-detecting the kind of threads based on the current
compiler and other heuristics, instead of using the thread support that
I explicitly selected at compile-time.  In this case it chooses wrong,
choosing win32 threads and not win32 pthreads.

The solution is probable to generate the #define GC_FOO_THREADS.  The
easiest way is probably to just move gc_config_macros.h to
gc_config_macros.h.in, and have AC_OUTPUT_FILES substitute in the
correct choices.

Regards,

Andy

Exported symbols in 7.1 missing from 7.2

Christoph Egger — 2013-03-02T20:35:32

Hi all!

  I noticed libgc 7.2 kept the SONAME at .1 but didn't keep the binary
interface (there are several public/exported symbols missing in 7.2):

+#MISSING: 7.2d# GC_acquire_mark_lock< at >Base 7.1
+#MISSING: 7.2d# GC_add_leaked< at >Base 7.1
+#MISSING: 7.2d# GC_block_count< at >Base 7.1
+#MISSING: 7.2d# GC_bytes_allocd_at_reset< at >Base 7.1
+#MISSING: 7.2d# GC_debug_free_inner< at >Base 7.1
+#MISSING: 7.2d# GC_disable_signals< at >Base 7.1
+#MISSING: 7.2d# GC_do_nothing< at >Base 7.1
+#MISSING: 7.2d# GC_enable_signals< at >Base 7.1
+#MISSING: 7.2d# GC_enclosing_mapping< at >Base 7.1
+#MISSING: 7.2d# GC_err_write< at >Base 7.1
+#MISSING: 7.2d# GC_finalization_failures< at >Base 7.1
+#MISSING: 7.2d# GC_fl_builder_count< at >Base 7.1
+#MISSING: 7.2d# GC_freehblk_ptr< at >Base 7.1
+#MISSING: 7.2d# GC_hdr_cache_hits< at >Base 7.1
+#MISSING: 7.2d# GC_hdr_cache_misses< at >Base 7.1
+#MISSING: 7.2d# GC_high_water< at >Base 7.1
+#MISSING: 7.2d# GC_init_inner< at >Base 7.1
+#MISSING: 7.2d# GC_is_static_root< at >Base 7.1
+#MISSING: 7.2d# GC_linux_stack_base< at >Base 7.1
+#MISSING: 7.2d# GC_min_sp< at >Base 7.1
+#MISSING: 7.2d# GC_notify_all_builder< at >Base 7.1
+#MISSING: 7.2d# GC_notify_full_gc< at >Base 7.1
+#MISSING: 7.2d# GC_on_stack< at >Base 7.1
+#MISSING: 7.2d# GC_page_was_ever_dirty< at >Base 7.1
+#MISSING: 7.2d# GC_print_source_ptr< at >Base 7.1
+#MISSING: 7.2d# GC_project2< at >Base 7.1
+#MISSING: 7.2d# GC_push_regs< at >Base 7.1
+#MISSING: 7.2d# GC_release_mark_lock< at >Base 7.1
+#MISSING: 7.2d# GC_spin_count< at >Base 7.1
+#MISSING: 7.2d# GC_stack_last_cleared< at >Base 7.1
+#MISSING: 7.2d# GC_stopping_pid< at >Base 7.1
+#MISSING: 7.2d# GC_stopping_thread< at >Base 7.1
+#MISSING: 7.2d# GC_unlocked_count< at >Base 7.1
+#MISSING: 7.2d# GC_wait_builder< at >Base 7.1
+#MISSING: 7.2d# GC_wait_for_reclaim< at >Base 7.1
+#MISSING: 7.2d# free_list_index_of< at >Base 7.1

  Where did these symbols go? If they were removed on purpose why was
the SONAME not incremented?

Regards

    Christoph

Possible bug: GC_realloc

Bryan Ischo — 2013-02-15T17:59:13

Hi there.  I believe there is a bug in libgc surrounding GC_realloc.  I
have attached a simple program which demonstrates this problem.  At
first I thought the problem was with GC_realloc mixed with
GC_register_finalizer, but when I added in code to turn off use of
GC_register_finalizer, I still get the bug.  So I now think that
GC_register_finalizer is a red herring and has nothing to do with the
problem.

As far as I can tell, the error occurs when an attempt is made to call
GC_realloc on memory that was already GC_realloc'd; i.e.

void *a = GC_malloc(...);
void *b = GC_realloc(a, ...);
void *c = GC_realloc(b, ...);

It is only when the third GC_realloc is done that the error occurs. When
GC_DEBUG is enabled, the error printed is this:

Attempt to reallocate invalid pointer 0x7f9ca0

When GC_DEBUG is not enabled, the result is a segmentation fault.

Note that this does not occur on every such realloc sequence (a trivial
program doing just the three lines above does not experience the
problem), it does seem to require some nontrivial sequence of allocs and
reallocs to occur.

For my operating system (Linux 3.6.4, x86_64) and version of libgc
(7.2), the test program fails after the 290th iteration; I will attach
my sample output as well.

(I a running with NO_FINALIZER set because I don't believe that
finalizers actually have any bearing on the problem after all)

Here is how I compile the program:

g++ -o gcbug gcbug.cpp -lgc

Here is how I run the program:

NO_FINALIZER=1 gcbug

Thanks!
Bryan



________________________________

This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement.
Created: 0x2334c20 (884)
Created: 0x2335e20 (416)
Removed: 0x2334c20
Created: 0x2336aa0 (1150)
Realloced: 0x2336aa0 -> 0x2336560 (1191)
Removed: 0x2336560
Removed: 0x2335e20
Created: 0x2335c20 (427)
Removed: 0x2335c20
Created: 0x2335a20 (369)
Created: 0x2334820 (783)
Realloced: 0x2334820 -> 0x2337f70 (68)
Removed: 0x2337f70
Created: 0x2338d40 (523)
Realloced: 0x2338d40 -> 0x2339820 (1394)
Removed: 0x2339820
Removed: 0x2335a20
Created: 0x2334420 (874)
Realloced: 0x2334420 -> 0x233afc0 (38)
Realloced: 0x233afc0 -> 0x2334020 (816)
Created: 0x2335820 (414)
Removed: 0x2334020
Realloced: 0x2335820 -> 0x2335620 (363)
Realloced: 0x2335620 -> 0x233bc20 (782)
Created: 0x2339020 (1426)
Created: 0x233b820 (837)
Removed: 0x233bc20
Removed: 0x233b820
Created: 0x233c820 (1396)
Created: 0x233de80 (315)
Realloced: 0x233de80 -> 0x2338aa0 (544)
Realloced: 0x233c820 -> 0x233c020 (1309)
Created: 0x2336020 (1179)
Created: 0x233b420 (904)
Realloced: 0x233b420 -> 0x2335420 (433)
Created: 0x233ef00 (177)
Removed: 0x2335420
Removed: 0x2338aa0
Created: 0x2338800 (540)
Removed: 0x2338800
Removed: 0x233ef00
Created: 0x233faa0 (1098)
Created: 0x2338560 (493)
Realloced: 0x233c020 -> 0x233f560 (1281)
Realloced: 0x2336020 -> 0x2340820 (1366)
Realloced: 0x2340820 -> 0x2341f20 (120)
Removed: 0x2341f20
Created: 0x233f020 (1118)
Realloced: 0x233faa0 -> 0x2342aa0 (1176)
Created: 0x2335220 (428)
Removed: 0x2335220
Created: 0x2342560 (1087)
Removed: 0x2342560
Realloced: 0x2342aa0 -> 0x233af70 (29)
Created: 0x2342020 (1233)
Created: 0x2343aa0 (1020)
Created: 0x2345f20 (209)
Removed: 0x2342020
Created: 0x2343560 (1224)
Removed: 0x2345f20
Created: 0x2335020 (422)
Realloced: 0x2339020 -> 0x233b020 (765)
Realloced: 0x233f560 -> 0x2346e20 (351)
Removed: 0x2343560
Realloced: 0x233af70 -> 0x23382c0 (625)
Removed: 0x2335020
Realloced: 0x233b020 -> 0x2340020 (1492)
Realloced: 0x233f020 -> 0x2347820 (1360)
Removed: 0x2340020
Realloced: 0x2346e20 -> 0x2343020 (1229)
Realloced: 0x23382c0 -> 0x2338020 (475)
Removed: 0x2343020
Removed: 0x2343aa0
Removed: 0x2338560
Removed: 0x2347820
Realloced: 0x2338020 -> 0x2348aa0 (1012)
Created: 0x2348560 (1030)
Removed: 0x2348560
Removed: 0x2348aa0
Created: 0x233af20 (39)
Removed: 0x233af20
Created: 0x2347020 (1319)
Created: 0x2346c20 (370)
Realloced: 0x2347020 -> 0x2349c20 (825)
Created: 0x234a820 (1471)
Realloced: 0x234a820 -> 0x2349820 (773)
Realloced: 0x2349c20 -> 0x234bf50 (91)
Realloced: 0x234bf50 -> 0x234a020 (1455)
Removed: 0x2346c20
Realloced: 0x2349820 -> 0x2346a20 (465)
Removed: 0x2346a20
Created: 0x234cde0 (305)
Realloced: 0x234a020 -> 0x2349420 (829)
Realloced: 0x2349420 -> 0x2348020 (1247)
Realloced: 0x234cde0 -> 0x2349020 (923)
Realloced: 0x2348020 -> 0x2341e80 (106)
Removed: 0x2341e80
Created: 0x234d820 (1379)
Created: 0x234eec0 (237)
Created: 0x234fd40 (523)
Realloced: 0x2349020 -> 0x2350e90 (283)
Realloced: 0x234d820 -> 0x2351aa0 (1138)
Created: 0x2351560 (1125)
Created: 0x2346820 (453)
Created: 0x234faa0 (551)
Realloced: 0x2351aa0 -> 0x2352f40 (132)
Created: 0x2346620 (431)
Realloced: 0x2346820 -> 0x2353c20 (664)
Removed: 0x2352f40
Realloced: 0x2346620 -> 0x2346420 (460)
Created: 0x233dd10 (314)
Realloced: 0x233dd10 -> 0x2353820 (927)
Realloced: 0x234faa0 -> 0x2353420 (841)
Removed: 0x2353c20
Created: 0x2354f80 (43)
Removed: 0x2353820
Created: 0x2353020 (680)
Realloced: 0x2346420 -> 0x234d020 (1349)
Removed: 0x2351560
Created: 0x2355c20 (837)
Created: 0x234f800 (588)
Created: 0x2351020 (1214)
Removed: 0x2353020
Realloced: 0x2354f80 -> 0x2356aa0 (1222)
Realloced: 0x234fd40 -> 0x2355820 (812)
Realloced: 0x2355820 -> 0x2356560 (1206)
Created: 0x2356020 (1128)
Created: 0x2355420 (659)
Removed: 0x2356aa0
Realloced: 0x2351020 -> 0x2357aa0 (1082)
Created: 0x234f560 (585)
Created: 0x2357560 (1173)
Removed: 0x2357aa0
Realloced: 0x2356020 -> 0x2358ca0 (641)
Realloced: 0x234f800 -> 0x2358980 (714)
Realloced: 0x2353420 -> 0x233aed0 (25)
Realloced: 0x2350e90 -> 0x2359fa0 (82)
Created: 0x235a820 (1337)
Removed: 0x2355c20
Removed: 0x234d020
Realloced: 0x234f560 -> 0x2355020 (777)
Created: 0x2357020 (1256)
Removed: 0x2357020
Removed: 0x2357560
Removed: 0x233aed0
Removed: 0x234eec0
Removed: 0x2358ca0
Realloced: 0x2356560 -> 0x2358660 (760)
Removed: 0x2355020
Removed: 0x2358980
Realloced: 0x2359fa0 -> 0x235bda0 (343)
Created: 0x234f2c0 (529)
Removed: 0x235bda0
Created: 0x234f020 (499)
Created: 0x235ce60 (254)
Created: 0x235a020 (1334)
Realloced: 0x234f2c0 -> 0x235daa0 (1255)
Removed: 0x2355420
Realloced: 0x235ce60 -> 0x235ed40 (501)
Created: 0x2350d40 (289)
Realloced: 0x235daa0 -> 0x235d560 (1304)
Removed: 0x235d560
Realloced: 0x2350d40 -> 0x235fc20 (893)
Created: 0x235d020 (1126)
Removed: 0x235a820
Realloced: 0x235ed40 -> 0x2358340 (730)
Removed: 0x2358660
Realloced: 0x235a020 -> 0x235f820 (961)
Realloced: 0x2358340 -> 0x2360aa0 (1028)
Realloced: 0x235f820 -> 0x235eaa0 (557)
Realloced: 0x235eaa0 -> 0x2360560 (1198)
Removed: 0x2360aa0
Realloced: 0x235d020 -> 0x2361820 (1429)
Created: 0x235e800 (501)
Realloced: 0x2361820 -> 0x2360020 (1160)
Realloced: 0x234f020 -> 0x2352e90 (135)
Removed: 0x235e800
Created: 0x235e560 (628)
Realloced: 0x235e560 -> 0x2361020 (1465)
Realloced: 0x2361020 -> 0x2362820 (1344)
Removed: 0x2360020
Removed: 0x2352e90
Realloced: 0x2362820 -> 0x235f420 (790)
Realloced: 0x2360560 -> 0x235f020 (793)
Realloced: 0x235f020 -> 0x2363f20 (145)
Created: 0x2362020 (1391)
Realloced: 0x235f420 -> 0x2337f00 (70)
Realloced: 0x235fc20 -> 0x2364c20 (762)
Created: 0x2346220 (361)
Created: 0x2364820 (762)
Created: 0x2358020 (691)
Realloced: 0x2364c20 -> 0x2365ca0 (678)
Created: 0x2365980 (691)
Removed: 0x2362020
Realloced: 0x2337f00 -> 0x2365660 (706)
Realloced: 0x2365660 -> 0x2364420 (887)
Removed: 0x2363f20
Created: 0x2366820 (1495)
Realloced: 0x2364420 -> 0x235e2c0 (530)
Created: 0x2364020 (791)
Removed: 0x2365ca0
Created: 0x2352de0 (132)
Removed: 0x2365980
Realloced: 0x2352de0 -> 0x2365340 (715)
Removed: 0x235e2c0
Realloced: 0x2346220 -> 0x2366020 (1480)
Realloced: 0x2358020 -> 0x2367f20 (190)
Realloced: 0x2367f20 -> 0x2365020 (642)
Realloced: 0x2365340 -> 0x2368aa0 (988)
Removed: 0x2365020
Removed: 0x2364820
Removed: 0x2366820
Created: 0x235e020 (607)
Removed: 0x2366020
Created: 0x2369d40 (560)
Created: 0x236a820 (1446)
Removed: 0x2369d40
Realloced: 0x2368aa0 -> 0x236bc20 (790)
Removed: 0x236bc20
Created: 0x2368560 (1258)
Created: 0x236cca0 (730)
Removed: 0x2368560
Removed: 0x235e020
Created: 0x2368020 (1075)
Removed: 0x236a820
Created: 0x236b820 (859)
Removed: 0x236cca0
Removed: 0x236b820
Removed: 0x2364020
Removed: 0x2368020
Created: 0x236b420 (848)
Removed: 0x236b420
Created: 0x236b020 (891)
Removed: 0x236b020
Created: 0x2369aa0 (616)
Realloced: 0x2369aa0 -> 0x2369800 (492)
Removed: 0x2369800
Created: 0x236df00 (232)
Realloced: 0x236df00 -> 0x2354f20 (55)
Realloced: 0x2354f20 -> 0x236a020 (1326)
Removed: 0x236a020
Created: 0x236efe0 (17)
Created: 0x236c980 (640)
Removed: 0x236efe0
Removed: 0x236c980
Created: 0x236efa0 (22)
Created: 0x236f820 (1313)
Created: 0x236c660 (686)
Created: 0x2370aa0 (1177)
Realloced: 0x2370aa0 -> 0x2346020 (358)
Removed: 0x2346020
Created: 0x2370560 (1128)
Realloced: 0x236efa0 -> 0x233dba0 (319)
Realloced: 0x233dba0 -> 0x2369560 (550)
Realloced: 0x2369560 -> 0x234cc80 (306)
Realloced: 0x234cc80 -> 0x2371e20 (376)
Realloced: 0x2370560 -> 0x23692c0 (590)
Removed: 0x236c660
Realloced: 0x236f820 -> 0x2371c20 (383)
Realloced: 0x23692c0 -> 0x2370020 (1218)
Realloced: 0x2371e20 -> 0x2359f20 (75)
Removed: 0x2370020
Created: 0x236c340 (754)
Created: 0x233da30 (315)
Realloced: 0x2359f20 -> 0x2372c20 (763)
Realloced: 0x2371c20 -> 0x236f020 (1420)
Realloced: 0x236c340 -> 0x2350bf0 (295)
Realloced: 0x236f020 -> 0x2373aa0 (1236)
Removed: 0x2373aa0
Removed: 0x2350bf0
Removed: 0x233da30
Created: 0x2373560 (1292)
Created: 0x236ddf0 (218)
Realloced: 0x236ddf0 -> 0x2373020 (1091)
Realloced: 0x2372c20 -> 0x2374820 (1405)
Realloced: 0x2373560 -> 0x236c020 (634)
Created: 0x2350aa0 (290)
Created: 0x2374020 (1352)
Removed: 0x2350aa0
Realloced: 0x2374820 -> 0x2369020 (507)
Created: 0x2335aa0 (1140)
Realloced: 0x2374020 -> 0x2335560 (1227)
Removed: 0x2369020
Created: 0x2334c20 (982)
Created: 0x2336d40 (537)
Created: 0x2337fe0 (19)
Created: 0x2338fc0 (33)
Removed: 0x236c020
Attempt to reallocate invalid pointer 0x2373020
Invalid pointer passed to realloc()
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

How does Boehm GC identify values as pointers?

Wolfgang Draxinger — 2013-02-15T11:25:10

Hi,

I'm currently implementing a library which frontend API does almost
everything through opaque, augmented, numeric handles. Internally the
handles are mapped to the actual objects then. The concept loosely
follows the way OpenGL manages internal objects (textures, buffers and
such).

The library itself does not use Boehm GC, as its own internal handle
based object management also doubles as a mark-sweep system for object
deallocation. However it may be used in programs, that actually do use
Boehm GC and now I'm wondering, how my handle values may clash with
pointer identification.

Since the handle values are augmented anyway, i.e. several bits of the
handle value designate the object type and other attributes which are
used to discard invalid handle values early before even looking them
up in the mapping to objects, I have a well defined interface in which I
can make several modifications to the bit patterns actually stored. This
would allow me to transform the numeric values in a way, that they don't
clash with Boehm GC, if this actually is a problem.


Regards,

Wolfgang

[PATCH] pthread-using tests -lpthread

Andy Wingo — 2013-02-13T14:46:42

Hi,

The attached patch fixes compilation of tests on my machine.

Cheers,

Andy

FreeBSD Itanium: gc-7.1 build failure: finalize.c:156: error:ALIGNMENT undeclared (first use in this function)

Anton Shterenlikht — 2013-01-30T17:37:14

I'm trying to build boehm-gc 7.1 on FreeBSD Itanium (ia64).

I get these errors:

 cc -DPACKAGE_NAME=\"gc\" -DPACKAGE_TARNAME=\"gc\" -DPACKAGE_VERSION=\"7.1\" "-DPACKAGE_STRING=\"gc 7.1\"" -DPACKAGE_BUGREPORT=\"Hans.Boehm-VXdhtT5mjnY< at >public.gmane.org\" -DGC_VERSION_MAJOR=7 -DGC_VERSION_MINOR=1 -DPACKAGE=\"gc\" -DVERSION=\"7.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DNO_EXECUTE_PERMISSION=1 -DALL_INTERIOR_POINTERS=1 -DGC_GCJ_SUPPORT=1 -DJAVA_FINALIZATION=1 -DATOMIC_UNCOLLECTABLE=1 -DKEEP_BACK_PTRS=1 -DDBG_HDRS_ALL=1 -I./include -fexceptions -I libatomic_ops/src -pipe -g -MT finalize.lo -MD -MP -MF .deps/finalize.Tpo -c finalize.c  -fPIC -DPIC -o .libs/finalize.o
finalize.c: In function 'GC_general_register_disappearing_link':
finalize.c:156: error: 'ALIGNMENT' undeclared (first use in this function)
finalize.c:156: error: (Each undeclared identifier is reported only once
finalize.c:156: error: for each function it appears in.)
finalize.c: In function 'GC_unregister_disappearing_link':
finalize.c:217: error: 'ALIGNMENT' undeclared (first use in this function)
finalize.c: In function 'GC_ignore_self_finalize_mark_proc':
finalize.c:269: error: 'ALIGNMENT' undeclared (first use in this function)
*** [finalize.lo] Error code 1

The full config and build logs are:

http://seis.bris.ac.uk/~mexas/config.log

http://seis.bris.ac.uk/~mexas/freebsd-ia64-boehm-gc-7.1.log

Please advise

Thanks

Anton

[Patch 2/2] Aarch64 libatomic_ops and Gc basic port

Yvan Roux — 2013-01-23T17:53:04

Gc patch.

Yvan
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

[Patch 1/2] Aarch64 libatomic_ops and Gc basic port

Yvan Roux — 2013-01-23T17:52:18

libatomic_ops patch.

Yvan
_______________________________________________
Gc mailing list
Gc-V9/bV5choksm30D7ZfaTJw< at >public.gmane.org
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/

[Patch 0/2] Aarch64 libatomic_ops and Gc basic port

Yvan Roux — 2013-01-23T17:50:52

Hi,

the next two emails contain a basic port of the libatomic_ops and the
Boehm Gc to the Aarch64 architecture. As Aarch64 is a completely
different architecture than the now old 32-bit ARM one (and as it is
the way it was done both in GCC and the Linux kernel), the support is
added as a new architecture.

The libatomic_ops is implemented with the __atomic_* GCC builtins, as
GCC (FSF or LInaro) is the only compiler which is targeting this
architecture.

The Gc support is only done for Linux and the bare machine mode (but
it has only be tested under Linux).

Both implementation were tested on the Foundation Model (notice that
the libpthread has to be added to the LIBS variable for running the Gc
make check, and that I'm not sure it is an expected behaviour).

Regards,
Yvan

Leak detector for libjansson

Илья Нечёса — 2013-01-18T11:06:20

Good afternoon. Sorry for bad English. I would like to ask a question 
about leak getector gc for libjansson.
In my project, I use a lot of objects jansson and that need to monitor. 
When creating an object jansson allocated memory which is then freed 
with json_decref(). You could not tell how can you use your leak 
detector for objects libjansson? Thank you in advance for your response.
Sincerely, Ilya Nechoysa