headers
Wayne Richards | 2 Sep 2006 18:32
Favicon

Win32 static threads

I'm attempting to compile a static lib on windows, using v6.7 libgc.
My ActiveX Dlls use the multithreaded c runtime, which seems to conflict with
the supplied NT_STATIC_THREADS_MAKEFILE (which uses the single-threaded runtime?).

I'm only moderately experienced with msvc or nmake, so I need very basic-level help
getting the libraries to work together.  Am I correct that both the static lib
and my ActiveX dlls should use the Multithreaded run-time libraries?  I've gotten
various symptoms when testing, generally pointing back to issues with threading.
Any general advice on how to track down the problem?  If these questions are too
general, I can post plenty of info, but I've tried so many different combinations
that it's difficult to know where to start.

Wayne
Permalink | Reply | 0 comments |
headers
jim marshall | 13 Sep 2006 17:59
Favicon

Purify and the GC

Hello,
 We have a need to use Purify with our application (customer 
requirement). I'm wondering if anyone has used Purify with the GC? This 
is on Linux and we are using GC 6.7.

Thanks

--

-- 
Jim Marshall
Sr. Staff Engineer
WBEM Solutions, Inc.
978-947-3607
Permalink | Reply | 0 comments |
headers
Alec Orr | 19 Sep 2006 15:51
Favicon

SIGSEGV in mark.c:759 (GC6.8/linux)

Good morning:

I have been seeing a SIGSEGV in GC_mark_from() when running two threads at once
(each works individually).  I am looking  for ways to troubleshoot this (we're
pretty sure we're doing something wrong).  We have tried to track down the cause
without much luck (Valgrind, Purify, dmalloc, etc).

We are aware that the GC will try to read past the stack, and the SIGSEGV should
be caught.  Could this SIGSEGV be caused by stack corruption or a timing problem?

I am using:
- Linux pcname 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux
- GC 6.8 (posix threads, full-debug-enabled, gc-assertions-enabled).

Below are 5 thread stack traces, only #3 (the 1st one listed) is of interest
since others appear to be sleeping, or waiting on a condition.

Thank you in advance for any advice,
Alec

Program received signal SIGSEGV, Segmentation fault.

Thread 3
#0  0x4002c91d in GC_mark_from (mark_stack_top=0x8052260,
     mark_stack=0x80520a8, mark_stack_limit=0x805a0a8) at mark.c:759
#1  0x4002d450 in GC_mark_some (
     cold_gc_frame=0x405c9b40 "i[\002 <at> ;&\002 <at> \234�\003 <at> ") at mark.c:361
#2  0x400226d0 in GC_stopped_mark (stop_func=0x40021b00 <GC_never_stop_func>)
     at alloc.c:531
#3  0x40022a3d in GC_try_to_collect_inner (
(Continue reading)

Permalink | Reply | 3 comments |
headers
Boehm, Hans | 20 Sep 2006 01:17
Picon
Favicon

RE: SIGSEGV in mark.c:759 (GC6.8/linux)

Somehow you ended up with an object on the mark stack that is not addressable, or at least not completely
addressable.  It would be interesting to know

- What address is being dereferenced.  If it fails at this particular point, it will be the value of the
variable "limit".

- How that object got pushed onto the mark stack.  If you don't have custom mark procedures or the like, I would
guess that it is being pushed as part of the root set.  Since it only happens with threads, I would guess there
may be an issue with correctly identifying the thread stacks.  Are other threads being created in this
process?  Or do you just have two long-lived threads?  I would look at whether the address is in the general
vicinity of other thread stacks, using /proc/≤pid>/maps.  You can also determine fairly easily what the
size of the offending object is, which might tell you something.

This is otherwise a default configuration?  USE_PROC_FOR_LIBRARIES is not defined?  Presumably neither
is malloc interception, since otherwise you'd be unlikely to get this far with threads. 
USE_PROC_FOR_LIBRARIES is probably not 100% reliable with threads in 6.8 and really shouldn't be used
with threads.  The symptoms would probably be similar ...

Hans

> -----Original Message-----
> From: gc-bounces@... 
> [mailto:gc-bounces@...] On Behalf Of Alec Orr
> Sent: Tuesday, September 19, 2006 6:52 AM
> To: gc@...
> Subject: [Gc] SIGSEGV in mark.c:759 (GC6.8/linux)
> 
> Good morning:
> 
> I have been seeing a SIGSEGV in GC_mark_from() when running
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hans Boehm | 20 Sep 2006 07:00
Picon
Favicon

gc7.0alpha7

I put gc7.0alpha7 in the standard location in www.hpl.hp.com (not in the
experimental directory).  The version in the CVS repository went from
7.0alpha6 to 7.0alpha8 in the process.  I also attempted to tag the
released version with 7_0alpha7 in the CVS tree, but given my lack of
expertise there, CVS mistakes are certainly possible.

I think 7.0alpha7 should generally be in reasonable shape, except
possibly for some Windows configurations.

My next priority is to merge some of the pending patches into 7.0alpha8
...

Hans
Permalink | Reply | 0 comments |
headers
Boehm, Hans | 21 Sep 2006 02:32
Picon
Favicon

RE: Could gc linux stop-world signals hang PAM?

Going through old mail ...

I think the problem here is that dlopen is being called directly, rather
than GC_dlopen.  GC_dlopen exists since dlopen may try to allocate while
holding a dynamic loader lock.  The GC tries to acquire the dynamic
loader lock so that it can find roots in dynamic libraries.

Unfortunately, the best workaround probably consists of linker games to
get pam to call the right thing.

Hans

> -----Original Message-----
> From: gc-bounces@... 
> [mailto:gc-bounces@...] On Behalf Of Alec Orr
> Sent: Thursday, August 24, 2006 4:42 PM
> To: gc@...
> Subject: [Gc] Could gc linux stop-world signals hang PAM?
> 
> Good evening folks:
> 
> I was wondering if anyone had seen a deadlock like this 
> before using the PAM libraries with GC.
> 
> We use Boehm GC 6.7
> PAM PAM 0.74
> RH Linux 2.4.20-8 (GNU/Linux).
> 
> I have 2 threads that are GC enabled, one uses PAM (which is 
> dlopened).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Boehm, Hans | 21 Sep 2006 02:39
Picon
Favicon

RE: Building gc.lib and test under MSVC++ 4.0

The short answer is probably yes, you do want a more recent version.
Gc_cpp.h has slowly evolved to compensate for compiler changes, and I
generally can't test that we don't break old compilers in the process.
Very old versions of gc_cpp.* might work better.  Also note that these
files are fairly simple wrappers for the C interface, and can usually be
adapted without understanding much about collector internals.

Hans

> -----Original Message-----
> From: gc-bounces@... 
> [mailto:gc-bounces@...] On Behalf Of D.
> Sent: Wednesday, August 23, 2006 9:14 AM
> To: gc@...
> Subject: [Gc] Building gc.lib and test under MSVC++ 4.0
> 
> Hi,
> 
> I would like to build the gc6.7 tests and gc.lib using
> MSVC++ 4.0. I am using the NT_STATIC_MAKEFILE.
> 
> I find that when I run the makefile, I get a huge number of 
> errors in gc_cpp.h and gc_cpp.cpp.
> 
> See below for example of errors.
> 
> Do I need a more recent version of MSVC++?
> 
> Any suggestions?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Petter Urkedal | 21 Sep 2006 18:55
Picon

Re: [boehms-gc] Extend Boehm's GC disappearing link facility with callbacks-on-disappear

Laurynas Biveinis wrote:
> Hi,
>
> Boehm's GC has weak pointer support, but sometimes setting the weak
> pointer to NULL when the object pointed by it disappears, is not what
> is required for the application, for example GCC hash tables use
> non-NULL values for deleted entries.
>
I hope I'm not too late responding here, I haven't followed the list 
very closely lately.

Since you are talking about hash tables, I suspect you may be doing the 
same as me, namely remove objects from hash tables as they are 
reclaimed.  Is that correct?  I tried to do this using finalisers, then 
with weak pointers.  The weak pointer solution was the most efficient, 
though as you mention it's not straight forward.

However, I have very tight requirements on efficiency and space 
overhead, since I am using this for hash-consing expression-trees, and 
since the tree nodes may consume the majority of memory for some 
applications (like automated logic provers).  Therefore, neither the 
finaliser nor the weak-pointer implementations are feasible in my case.  
Callbacks on weak-pointers would give the required functionality, but in 
my case I suspect overhead is still too big (at list memory-wise).

I have been using a new patch which takes a rather different approach 
from the one I posted.  Apologies to Boehm for not informing that I had 
abandoned the patch.

Assuming we are trying to solve the same problem, I think it would be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alec Orr | 22 Sep 2006 08:57
Favicon

Re: SIGSEGV in mark.c:759 (GC6.8/linux)

Hans,

Thank you kindly for your replies!  We do have other threads running, but none
being created or ending (we have 2 long lived threads for now).  I couldn't find 
a USE_PROC_FOR_LIBRARIES defined in our gc headers.  We built GG 2.8 with
assertions, full debug and POSIX threads using the configure script.

The 'limit' always lies outside any address range /opt/≤proc>/maps.

You mentioned that "You can also determine fairly easily what the size of the 
offending object is, which might tell you something"

Can you point me in the right direction on how to I can fetch this?

Thanks again for your time,
Alec

(gdb) print (void*)limit
$2 = (void *) 0x4166a308
(gdb) bt
#0  GC_mark_from (mark_stack_top=0x8051250, mark_stack=0x80510a8, 
mark_stack_limit=0x80590a8) at mark.c:759
#1  0x4002c380 in GC_mark_some (cold_gc_frame=0x40646b10 "") at mark.c:361
#2  0x400220c0 in GC_stopped_mark (stop_func=0x400214f0 <GC_never_stop_func>) at 
alloc.c:531
#3  0x4002241a in GC_try_to_collect_inner (stop_func=0x400214f0 
<GC_never_stop_func>) at alloc.c:378
#4  0x40022726 in GC_collect_or_expand (needed_blocks=1, ignore_off_page=0) at 
alloc.c:1036
#5  0x40028900 in GC_alloc_large (lw=599, k=1, flags=0) at malloc.c:62
(Continue reading)

Permalink | Reply | 1 comment |
headers
Boehm, Hans | 23 Sep 2006 01:42
Picon
Favicon

RE: SIGSEGV in mark.c:759 (GC6.8/linux)

You can probably get some idea of the object size by looking at the
difference between current_p and limit.  If descr is visible to gdb,
that might give you the entire size, in bytes.

Since this is likely to be a large range, it may have been split.  In
that case, I think *mark_stack_top should describe the remainder of the
range.

Given that this seems to be nowhere near the heap, a more interesting
question might be whether it's in the GC root set.  Try
GC_print_static_roots() at that point.  If it's not in the root set, you
might try turning on DEBUG_THREADS in pthread_stop_world.c, and see
whether it gets pushed as a thread stack.

If you need to check more systematically how this is getting onto the
mark stack, there's a bit of support for that in gc7 (grep for
ENABLE_TRACE), but probably not in 6.8.  But that really only works as
is if the address is somewhat reproducible.

Hans

> -----Original Message-----
> From: Alec Orr [mailto:Alec.Orr@...] 
> Sent: Thursday, September 21, 2006 11:57 PM
> To: Boehm, Hans
> Cc: gc@...
> Subject: Re: [Gc] SIGSEGV in mark.c:759 (GC6.8/linux)
> 
> Hans,
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane