public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kurt Miller <kurt@intricatesoftware.com>
To: "Boehm, Hans" <hans.boehm@hp.com>
Cc: "java@gcc.gnu.org" <java@gcc.gnu.org>
Subject: Re: gcj 4.6 on OpenBSD/x86
Date: Wed, 10 Oct 2012 13:33:00 -0000	[thread overview]
Message-ID: <5075791E.3060307@intricatesoftware.com> (raw)
In-Reply-To: <A3E67C2071F49C4CBC4F17E6D77CDDD235F8B32F@G4W3296.americas.hpqcorp.net>

On 10/9/12 1:21 PM, Boehm, Hans wrote:
> It may be worth checking whether the garbage collector tests, particularly gctest, run correctly in your environment.  If not, that might give you an easier debugging task.
>
> Hans
Hi Hans,

Initially gctest was failing which was caused by OpenBSD not having 
pthread_getattr_np(). We have pthread_stackseg_np() so I put an OpenBSD 
specific implementation into pthread_support.c 
GC_get_thread_stack_base(). This corrected the gctest failure and 'gmake 
check' passes all tests now. However gjar still segfaults  unless 
GC_DONT_GC is used.

Based on the output below is there a place you can suggest I look for 
the problem? or can you suggest a way for me to isolate which part of GC 
is not setup correctly on OpenBSD?

Thanks,
-Kurt

$ GC_PRINT_STATS=1 ./.libs/gjar cf test.jar headers.stamp
Increasing heap size by 65536 after 0 allocated bytes
Initiating full world-stop collection 1 after 0 allocd bytes
--> Marking for collection 1 after 0 allocd bytes + 0 wasted bytes
Collection 0 finished ---> heapsize = 65536 bytes
World-stopped marking took 30 msecs
Complete collection took 30 msecs
Grew fo table to 1 entries
Grew fo table to 2 entries
Grew fo table to 4 entries
Grew fo table to 8 entries
Increasing heap size by 65536 after 11436 allocated bytes
Grew fo table to 16 entries
Grew fo table to 32 entries
Grew fo table to 64 entries
Grew fo table to 128 entries
Increasing heap size by 65536 after 22796 allocated bytes
Grew fo table to 256 entries
Grew fo table to 512 entries
Increasing heap size by 69632 after 78976 allocated bytes
Increasing heap size by 90112 after 146000 allocated bytes
Increasing heap size by 122880 after 224344 allocated bytes
Grew fo table to 1024 entries
Grew dl table to 1 entries
Grew dl table to 2 entries
Grew dl table to 4 entries
Grew dl table to 8 entries
Increasing heap size by 163840 after 328216 allocated bytes
Increasing heap size by 217088 after 480352 allocated bytes
Increasing heap size by 290816 after 704192 allocated bytes
Increasing heap size by 385024 after 1003400 allocated bytes
Increasing heap size by 516096 after 1367328 allocated bytes
Grew dl table to 16 entries
Grew fo table to 2048 entries
Increasing heap size by 733184 after 1869512 allocated bytes
Increasing heap size by 929792 after 2607408 allocated bytes
Increasing heap size by 1241088 after 3531840 allocated bytes
Initiating full world-stop collection 2 after 4753976 allocd bytes
--> Marking for collection 2 after 4753976 allocd bytes + 36728 wasted bytes
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Mark stack overflow; current size = 4096 entries
Grew mark stack to 8192 frames
Collection 1 finished ---> heapsize = 4988928 bytes
World-stopped marking took 90 msecs
Complete collection took 90 msecs
Segmentation fault (core dumped)


  parent reply	other threads:[~2012-10-10 13:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-08 20:08 Kurt Miller
2012-10-08 20:35 ` David Daney
2012-10-08 22:10   ` Kurt Miller
2012-10-09  0:51     ` Andrew Haley
2012-10-09 13:06       ` Kurt Miller
2012-10-09 17:22         ` Boehm, Hans
2012-10-09 18:27           ` Kurt Miller
2012-10-10 13:33           ` Kurt Miller [this message]
2012-10-14 11:26             ` Kurt Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5075791E.3060307@intricatesoftware.com \
    --to=kurt@intricatesoftware.com \
    --cc=hans.boehm@hp.com \
    --cc=java@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).