boehm-gc troubles with 2.0.10 on NetBSD/i386

boehm-gc troubles with 2.0.10 on NetBSD/i386

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]


I've been a guile user erratically for a long time, and maintain the
entry for guile in pkgsrc.  Currently that's at 1.8.8 and it works fine.

There's a draft package for guile 2.  boehm-gc in pkgsrc on NetBSD is
built without threads, and I have --disable-threads passed to guile's
configure.

The build goes ok until trying to run guild.  Just starting it without
args leads to:

/usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild
0xbbbe12d4 is not a GC visible pointer location
GC_is_visible test failed
Abort trap (core dumped)

Trying with gdb:

Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.10/libguile/.libs/guile 

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1]
0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
(gdb) bt
#0  0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
#1  0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1
#2  0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1
#3  0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1
#4  0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29
#5  0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29
#6  0xbbb670bc in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29
#7  0xbbb672d7 in with_guile_and_parent () from .libs/libguile-2.0.so.29
#8  0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1
#9  0xbbb674b9 in scm_with_guile () from .libs/libguile-2.0.so.29
#10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29
#11 0x08048ce9 in main ()

When I run the included tests on boehm-gc 7.2e, they all past.


So I wonder if you think this is a boehm-gc issue, or something odd that
guile is doing to boehm-gc.  Any hints would be appreciated.



[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Mark H Weaver]

Hi Greg,

Greg Troxel <gdt@ir.bbn.com> writes:

> There's a draft package for guile 2.  boehm-gc in pkgsrc on NetBSD is
> built without threads, and I have --disable-threads passed to guile's
> configure.

As documented in our README and the output of ./configure --help,
"--without-threads" is the option you should be using.  To be honest,
I'm not sure what "--disable-threads" will do, if anything.  It's
possible that gnulib is somehow enabling that option to be accepted
without an error.

Also, please don't use Guile 2.0.10.  It was a brown-paper-bag release.
Please use Guile 2.0.11, which was released 3 days after 2.0.10.

> The build goes ok until trying to run guild.  Just starting it without
> args leads to:
>
> /usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild
> 0xbbbe12d4 is not a GC visible pointer location
> GC_is_visible test failed
> Abort trap (core dumped)

The relevant code is in gc.c line 632, which verifies that the GC can
see the static variable 'scm_protects' defined in the same file.  If it
can't, that indicates a serious problem with the garbage collector.

Before I investigate this any further, can you try with Guile 2.0.11 and
passing "--without-threads" to ./configure?

    Regards,
      Mark


> Trying with gdb:
>
> Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.10/libguile/.libs/guile 
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 1]
> 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
> (gdb) bt
> #0  0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
> #1  0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1
> #2  0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1
> #3  0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1
> #4  0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29
> #5  0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29
> #6  0xbbb670bc in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29
> #7  0xbbb672d7 in with_guile_and_parent () from .libs/libguile-2.0.so.29
> #8  0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1
> #9  0xbbb674b9 in scm_with_guile () from .libs/libguile-2.0.so.29
> #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29
> #11 0x08048ce9 in main ()
>
> When I run the included tests on boehm-gc 7.2e, they all past.
>
>
> So I wonder if you think this is a boehm-gc issue, or something odd that
> guile is doing to boehm-gc.  Any hints would be appreciated.

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 4440 bytes --]


Mark H Weaver <mhw@netris.org> writes:

> As documented in our README and the output of ./configure --help,
> "--without-threads" is the option you should be using.  To be honest,
> I'm not sure what "--disable-threads" will do, if anything.  It's
> possible that gnulib is somehow enabling that option to be accepted
> without an error.

Thanks for looking at my issue.

Sorry, I typed that from memory.  It was --with-threads=no and I changed
it to --without-threads.  My configure output shows:

checking what kind of threads to support... null-threads

> Also, please don't use Guile 2.0.10.  It was a brown-paper-bag release.
> Please use Guile 2.0.11, which was released 3 days after 2.0.10.

OK; I've updated the package to 2.0.11.  I now remember noticing that.

>> The build goes ok until trying to run guild.  Just starting it without
>> args leads to:
>>
>> /usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild
>> 0xbbbe12d4 is not a GC visible pointer location
>> GC_is_visible test failed
>> Abort trap (core dumped)
>
> The relevant code is in gc.c line 632, which verifies that the GC can
> see the static variable 'scm_protects' defined in the same file.  If it
> can't, that indicates a serious problem with the garbage collector.
>
> Before I investigate this any further, can you try with Guile 2.0.11 and
> passing "--without-threads" to ./configure?

After fixing the --disable-threads and updating to 2.0.11, I get the
following.  I'll ask pkgsrc/netbsd people about libgc, since that seems
to be the issue.

/usr/pkgsrc/wip/guile2/work/guile-2.0.11/libguile > LD_LIBRARY_PATH=.libs gdb .libs/guile 
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486--netbsdelf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile...(no debugging symbols found)...done.
(gdb) run
Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile 

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 1]
0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
(gdb) bt
#0  0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
#1  0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1
#2  0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1
#3  0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1
#4  0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29
#5  0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29
#6  0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29
#7  0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29
#8  0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1
#9  0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29
#10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29
#11 0x08048ce9 in main ()


I realize this packaging control file is a foreign language, but here's how it looks:

  # $NetBSD$
  #

  DISTNAME=	guile-2.0.11
  CATEGORIES=	lang
  MASTER_SITES=	ftp://ftp.gnu.org/gnu/guile/

  MAINTAINER=	root@zta.lk
  HOMEPAGE=	ftp://ftp.gnu.org/gnu/guile/
  COMMENT=	Official extension language for the GNU operating system
  LICENSE=	gnu-gpl-v3

  GNU_CONFIGURE=	yes
  USE_TOOLS+=	pkg-config

  PKGCONFIG_OVERRIDE+=	meta/guile-2.0.pc.in

  CONFIGURE_ARGS+=	--without-threads
  #.include "../../mk/pthread.buildlink3.mk"

  # These are in the order given in guile's README.
  .include "../../devel/gmp/buildlink3.mk"
  .include "../../converters/libiconv/buildlink3.mk"
  .include "../../devel/gettext-lib/buildlink3.mk"
  .include "../../devel/libltdl/buildlink3.mk"
  .include "../../textproc/libunistring/buildlink3.mk"
  .include "../../devel/boehm-gc/buildlink3.mk"
  .include "../../devel/libffi/buildlink3.mk"

  .include "../../mk/bsd.pkg.mk"


So really guile is building pretty close to natively.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Mark H Weaver]

Greg Troxel <gdt@ir.bbn.com> writes:

> After fixing the --disable-threads and updating to 2.0.11, I get the
> following.  I'll ask pkgsrc/netbsd people about libgc, since that seems
> to be the issue.
>
> /usr/pkgsrc/wip/guile2/work/guile-2.0.11/libguile > LD_LIBRARY_PATH=.libs gdb .libs/guile 
> GNU gdb (GDB) 7.3.1
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i486--netbsdelf".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile...(no
> debugging symbols found)...done.
> (gdb) run
> Starting program: /u0/n0/gdt/NetBSD-current/pkgsrc/wip/guile2/work/guile-2.0.11/libguile/.libs/guile 
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 1]
> 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
> (gdb) bt
> #0  0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
> #1  0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1
> #2  0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1
> #3  0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1
> #4  0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29
> #5  0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29
> #6  0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29
> #7  0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29
> #8  0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1
> #9  0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29
> #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29
> #11 0x08048ce9 in main ()

My guess is that this SIGSEGV is probably intentional, perhaps the
method used by GC on NetBSD to determine the bounds of the stack or some
other data area.  I would try continuing and seeing what happens next.
GC may also use some other signals for its own purposes.

> I realize this packaging control file is a foreign language, but here's how it looks:
>
>   # $NetBSD$
>   #
>
>   DISTNAME=	guile-2.0.11
>   CATEGORIES=	lang
>   MASTER_SITES=	ftp://ftp.gnu.org/gnu/guile/
>
>   MAINTAINER=	root@zta.lk
>   HOMEPAGE=	ftp://ftp.gnu.org/gnu/guile/
>   COMMENT=	Official extension language for the GNU operating system
>   LICENSE=	gnu-gpl-v3

I think this license field is incorrect.  Guile's license is the GNU
_Lesser_ General Public License v3-or-later.

     Mark

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]


Mark H Weaver <mhw@netris.org> writes:

>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to LWP 1]
>> 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
>> (gdb) bt
>> #0  0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
>> #1  0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1
>> #2  0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1
>> #3  0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1
>> #4  0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29
>> #5  0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29
>> #6  0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29
>> #7  0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29
>> #8  0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1
>> #9  0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29
>> #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29
>> #11 0x08048ce9 in main ()
>
> My guess is that this SIGSEGV is probably intentional, perhaps the
> method used by GC on NetBSD to determine the bounds of the stack or some
> other data area.  I would try continuing and seeing what happens next.
> GC may also use some other signals for its own purposes.

continuing leads to the program exiting.  I should build libgc with
debugging...

>>   LICENSE=	gnu-gpl-v3
>
> I think this license field is incorrect.  Guile's license is the GNU
> _Lesser_ General Public License v3-or-later.

Is everything that is installed under LGPL, even readline?
(But even if so, that should say "gnu-gpl-v3 AND gnu-lgpl-v3".)

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Mark H Weaver]

Greg Troxel <gdt@ir.bbn.com> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> [Switching to LWP 1]
>>> 0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
>>> (gdb) bt
>>> #0  0xbba868ae in GC_find_limit_with_bound () from /usr/pkg/lib/libgc.so.1
>>> #1  0xbba8696e in GC_find_limit () from /usr/pkg/lib/libgc.so.1
>>> #2  0xbba8699d in GC_init_netbsd_elf () from /usr/pkg/lib/libgc.so.1
>>> #3  0xbba85b3f in GC_init () from /usr/pkg/lib/libgc.so.1
>>> #4  0xbbaf9748 in scm_storage_prehistory () from .libs/libguile-2.0.so.29
>>> #5  0xbbb0abaf in scm_i_init_guile () from .libs/libguile-2.0.so.29
>>> #6  0xbbb6712c in scm_i_init_thread_for_guile () from .libs/libguile-2.0.so.29
>>> #7  0xbbb67347 in with_guile_and_parent () from .libs/libguile-2.0.so.29
>>> #8  0xbba85767 in GC_call_with_stack_base () from /usr/pkg/lib/libgc.so.1
>>> #9  0xbbb67529 in scm_with_guile () from .libs/libguile-2.0.so.29
>>> #10 0xbbb0ab67 in scm_boot_guile () from .libs/libguile-2.0.so.29
>>> #11 0x08048ce9 in main ()
>>
>> My guess is that this SIGSEGV is probably intentional, perhaps the
>> method used by GC on NetBSD to determine the bounds of the stack or some
>> other data area.  I would try continuing and seeing what happens next.
>> GC may also use some other signals for its own purposes.
>
> continuing leads to the program exiting.  I should build libgc with
> debugging...

In an earlier message, you wrote that guild prints the following when
run normally:

> /usr/pkgsrc/wip/guile2/work/guile-2.0.10/libguile > ../meta/uninstalled-env ../meta/guild
> 0xbbbe12d4 is not a GC visible pointer location
> GC_is_visible test failed
> Abort trap (core dumped)

Does this not happen when running it within GDB?

It would be good to try building with -g and -Og or -O0, and perhaps
also installing a more recent version of GDB.

While helping someone working on getting Guile 2 into FreeBSD ports, I
learned that FreeBSD includes a very old version of GDB, presumably to
avoid the GNU GPLv3.  We also learned that recent versions of GDB show
function arguments in the backtrace whereas the GDB included in FreeBSD
apparently doesn't.  Perhaps the situation is similar on NetBSD.

>>>   LICENSE=	gnu-gpl-v3
>>
>> I think this license field is incorrect.  Guile's license is the GNU
>> _Lesser_ General Public License v3-or-later.
>
> Is everything that is installed under LGPL, even readline?
> (But even if so, that should say "gnu-gpl-v3 AND gnu-lgpl-v3".)

The Guile distribution includes an optional 'libguilereadline' library,
which links with libreadline and is covered by GNU GPL v3-or-later.  It
is not used unless explicitly loaded by the user.  Guile itself is
covered by GNU LGPL v3-or-later.

     Regards,
       Mark

Re: boehm-gc troubles with 2.0.11 on NetBSD/i386

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]


A partial update:

  I am using 2.0.11 now.

  After updating to libgc 7.4.0, I have the same problem with a similar
  stack trace.  libgc is built without threads and passes it's "gmake
  check".

  I have the same problem with libgc 7.4.0 on netbsd-5/i386 (libgc
  passes gmake check on this combination also).

  On netbsd-5/i386, I tried to build libgc and guile with threads, but
  it failed to link with tls_get_addr.  This is likely a known lack of
  support in netbsd-5 which AFAIK doesn't provide thread-local storage.

  I haven't yet compiled libgc and guile with debugging symbols and
  without optimization; I realize that's what I need to do to figure
  this out.  I read a bit of the code to get started understanding the
  boot sequence.

  It seems there is detection of stack growth detection.  I wonder if
  that's somehow going astray.

I am curious if others are having success on other *BSD, and which
versions and architectures.

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

Re: boehm-gc troubles with 2.0.11 on NetBSD/i386

[Taylan Ulrich Bayirli/Kammer]

Greg Troxel <gdt@ir.bbn.com> writes:

> I am curious if others are having success on other *BSD, and which
> versions and architectures.

2.0.11 was fine on OpenBSD 5.3 amd64 AKA x86_64, with libgc 7.4.  (Sadly
I'm not on OpenBSD anymore so in case you have detailed questions I may
not be able to answer them.)

OS X 10.9 is also mostly fine, though with some issues.  See relevant ML
thread, "2.0.11 on OS X 10.9 / Xcode 5.1".

Taylan

Re: boehm-gc troubles with 2.0.11 on NetBSD/i386

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

Greg Troxel <gdt@ir.bbn.com> writes:
> I am curious if others are having success on other *BSD, and which
> versions and architectures.

zacts on #guile has done work on a guile 2.0.11 package for FreeBSD
ports, and based on his reports it seems to work well.  IIRC, he built
it (and boehm-gc) with threads enabled (pthreads).  There was just one
notable issue: guile needs a patch (see attached) for clang 3.4 on
32-bit systems.  I haven't yet pushed this to git because it needs to be
made more portable.  Anyway, I doubt it's related to the problem you're
seeing.

      Mark


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Preliminary guile fix for clang 3.4 on 32-bit systems --]
[-- Type: text/x-patch, Size: 1517 bytes --]

diff --git a/libguile/foreign.c b/libguile/foreign.c
index 01af900..59f5e72 100644
--- a/libguile/foreign.c
+++ b/libguile/foreign.c
@@ -814,7 +814,7 @@ SCM_DEFINE (scm_pointer_to_procedure, "pointer->procedure", 3, 0, 0,
 
 static const struct
 {
-  scm_t_uint64 dummy; /* ensure 8-byte alignment; perhaps there's a better way */
+  SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */
   const scm_t_uint8 bytes[10 * (sizeof (struct scm_objcode) + 8
                                 + sizeof (struct scm_objcode) + 32)];
 } raw_bytecode = {
@@ -867,7 +867,7 @@ make_objcode_trampoline (unsigned int nargs)
 
 static const struct
 {
-  scm_t_uint64 dummy; /* alignment */
+  SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */
   scm_t_cell cells[10 * 2]; /* 10 double cells */
 } objcode_cells = {
   0,
diff --git a/libguile/gsubr.c b/libguile/gsubr.c
index b6f261f..38b7ce1 100644
--- a/libguile/gsubr.c
+++ b/libguile/gsubr.c
@@ -213,7 +213,7 @@
 */
 static const struct
 {
-  scm_t_uint64 dummy; /* ensure 8-byte alignment; perhaps there's a better way */
+  SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */
   const scm_t_uint8 bytes[121 * (sizeof (struct scm_objcode) + 16
                                  + sizeof (struct scm_objcode) + 32)];
 } raw_bytecode = {
@@ -317,7 +317,7 @@ static const struct
 
 static const struct
 {
-  scm_t_uint64 dummy; /* alignment */
+  SCM_ALIGNED (8) scm_t_uint64 dummy; /* alignment */
   scm_t_cell cells[121 * 2]; /* 11*11 double cells */
 } objcode_cells = {
   0,

Re: boehm-gc troubles with 2.0.11 on NetBSD/i386

[In-Ho Yi]

I've continued execution after GC_find_limit_with_bound SIGSEGVs, and 
finally I hit this point

Program received signal SIGSEGV, Segmentation fault.
0x00007f7ff7721d84 in scm_variable_ref (var=0x0) at variable.c:93
93        SCM_VALIDATE_VARIABLE (1, var);
(gdb) bt
#0  0x00007f7ff7721d84 in scm_variable_ref (var=0x0) at variable.c:93
#1  0x00007f7ff771ff0a in scm_throw (key=0x0, args=0x658240) at 
throw.c:98
#2  0x00007f7ff77205ae in scm_ithrow (key=0x0, args=0x658240, 
no_return=1) at throw.c:435
#3  0x00007f7ff767cc7c in scm_error_scm (key=0x0, subr=0x644f80, 
message=0x644fa0, args=0x304, data=0x4) at error.c:94
#4  0x00007f7ff767cc2d in scm_error (key=0x0, subr=0x7f7ff778e162 
"scm_hash_fn_create_handle_x",
    message=0x7f7ff778e17e "void hashtable", args=0x304, rest=0x4) at 
error.c:60
#5  0x00007f7ff767d20e in scm_misc_error (subr=0x7f7ff778e162 
"scm_hash_fn_create_handle_x",
    message=0x7f7ff778e17e "void hashtable", args=0x304) at error.c:304
#6  0x00007f7ff76a08b2 in scm_hash_fn_create_handle_x (table=0x64cfe0, 
obj=0x644fc0, init=0x904,
    hash_fn=0x7f7ff771b60b <symbol_lookup_hash_fn>, 
assoc_fn=0x7f7ff771b634 <symbol_lookup_assoc_fn>, closure=0x0)
    at hashtab.c:691
#7  0x00007f7ff771b721 in intern_symbol (symbol=0x644fc0) at 
symbols.c:195
#8  0x00007f7ff771b7bf in scm_i_str2symbol (str=0x7f7ff79d9908) at 
symbols.c:218
#9  0x00007f7ff771b9cd in scm_string_to_symbol (string=0x7f7ff79d9908) 
at symbols.c:323
#10 0x00007f7ff7721fda in scm_init_variable () at 
../libguile/variable.x:4
#11 0x00007f7ff76a7fa7 in scm_i_init_guile (base=0x7f7fffffdad0) at 
init.c:407
#12 0x00007f7ff771d143 in scm_i_init_thread_for_guile 
(base=0x7f7fffffdad0, parent=0x0) at threads.c:833
#13 0x00007f7ff771d24e in with_guile_and_parent (base=0x7f7fffffdad0, 
data=0x7f7fffffdb10) at threads.c:899
#14 0x00007f7ff721de1f in GC_call_with_stack_base () from 
/usr/pkg/lib/libgc.so.1
#15 0x00007f7ff771d386 in scm_i_with_guile_and_parent 
(func=0x7f7ff76a7e1c <invoke_main_func>, data=0x7f7fffffdb80,
    parent=0x0) at threads.c:949
#16 0x00007f7ff771d3b2 in scm_with_guile (func=0x7f7ff76a7e1c 
<invoke_main_func>, data=0x7f7fffffdb80) at threads.c:955
#17 0x00007f7ff76a7dfd in scm_boot_guile (argc=1, argv=0x7f7fffffdc18, 
main_func=0x400fec <inner_main>, closure=0x0)
    at init.c:319
#18 0x0000000000401121 in main (argc=1, argv=0x7f7fffffdc18) at 
guile.c:108

where it finally fails. 

I'm trying guile2 2.0.11 built from pkgsrc wip with --without-threads 
configuration option on NetBSD/i386 6.1.4



--
View this message in context: http://gnu-guile.7481.n7.nabble.com/boehm-gc-troubles-with-2-0-10-on-NetBSD-i386-tp18473p19272.html
Sent from the Dev mailing list archive at Nabble.com.

Re: boehm-gc troubles with 2.0.11 on NetBSD/i386

[Mark H Weaver]

In-Ho Yi <chajath@gmail.com> writes:
> I've continued execution after GC_find_limit_with_bound SIGSEGVs, and 
> finally I hit this point
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007f7ff7721d84 in scm_variable_ref (var=0x0) at variable.c:93
> 93        SCM_VALIDATE_VARIABLE (1, var);

First, can you verify that you have the following patch applied?

  http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commitdiff;h=156119b0223cf14d335ebda84701a69b2ba95757

It was not in 2.0.11 and is needed for 32-bit clang builds.

> I'm trying guile2 2.0.11 built from pkgsrc wip with --without-threads 
> configuration option on NetBSD/i386 6.1.4

Which version of bdw-gc?

     Thanks,
       Mark

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Ludovic Courtès]

Greg, does libgc’s own ‘make check’ pass on this platform?

Ludo’.

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:
> Greg, does libgc’s own ‘make check’ pass on this platform?

In the first message of this thread, Greg wrote:
> When I run the included tests on boehm-gc 7.2e, they all past.

     Mark

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Greg Troxel]

[-- Attachment #1: Type: text/plain, Size: 10920 bytes --]


I am using gc-7.2e, which is what pkgsrc has, and which
  http://www.hboehm.info/gc/
indicates is the latest stable version.  This is with gcc 4.5.3 on i386.


ludo@gnu.org (Ludovic Courtès) writes:

> Greg, does libgc’s own ‘make check’ pass on this platform?

Yes.  libgc seems to have multiple tests.  pkgsrc has the following, and
it runs fine:

do-test:
        cd ${WRKSRC} && \
        ${RM} -f gctest && ${MAKE_PROGRAM} gctest && ./gctest && \
        ${RM} -f test_cpp && ${MAKE_PROGRAM} test_cpp && ./test_cpp 10

also, cding into the build directory after the package is built and "gmake check" passes.


gory details in case it matters, make test (above taret) and then check:

----------------------------------------
=> Bootstrap dependency digest>=20010302: found digest-20121220
WARNING: [license.mk] Every package should define a LICENSE.
===> Testing for boehm-gc-7.2e
cd /u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2 &&  /bin/rm -f gctest && /usr/pkg/bin/gmake gctest && ./gctest &&  /bin/rm -f test_cpp && /usr/pkg/bin/gmake test_cpp && ./test_cpp 10
gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .deps/test.Tpo -c -o test.o `test -f 'tests/test.c' || echo './'`tests/test.c
mv -f .deps/test.Tpo .deps/test.Po
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing  -Wl,-R/usr/pkg/lib -o gctest test.o ./libgc.la   
libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/gctest test.o  -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib
Completed 1 tests
Allocated 747393 collectable objects
Allocated 202 uncollectable objects
Allocated 1250000 atomic objects
Allocated 21760 stubborn objects
Finalized 2206/2206 objects - finalization is probably ok
Total number of bytes allocated is 90678890
Final heap size is 4927488 bytes
Collector appears to work
c++ -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -MT test_cpp.o -MD -MP -MF .deps/test_cpp.Tpo -c -o test_cpp.o `test -f 'tests/test_cpp.cc' || echo './'`tests/test_cpp.cc
mv -f .deps/test_cpp.Tpo .deps/test_cpp.Po
/bin/sh ./libtool  --tag=CXX   --mode=link c++ -fexceptions -O2  -Wl,-R/usr/pkg/lib -o test_cpp test_cpp.o libgccpp.la ./libgc.la  
libtool: link: c++ -fexceptions -O2 -Wl,-R/usr/pkg/lib -o .libs/test_cpp test_cpp.o  -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2/.libs -L./.libs -lgccpp -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -lgc -Wl,-rpath,/usr/pkg/lib
Starting iteration 1
Starting iteration 2
Starting iteration 3
Starting iteration 4
Starting iteration 5
Starting iteration 6
Starting iteration 7
Starting iteration 8
Starting iteration 9
Starting iteration 10
The test appears to have succeeded.
----------------------------------------
gmake[1]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake  libstaticrootslib.la gctest leaktest middletest smashtest hugetest realloc_test staticrootstest   test_cpp
gmake[2]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
/bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT staticrootslib.lo -MD -MP -MF .deps/staticrootslib.Tpo -c -o staticrootslib.lo `test -f 'tests/staticrootslib.c' || echo './'`tests/staticrootslib.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT staticrootslib.lo -MD -MP -MF .deps/staticrootslib.Tpo -c tests/staticrootslib.c  -fPIC -DPIC -o .libs/staticrootslib.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I./include -I./libatomic_ops/src -fexceptions -O2 -fno-strict-aliasing -MT staticrootslib.lo -MD -MP -MF .deps/staticrootslib.Tpo -c tests/staticrootslib.c -o staticrootslib.o >/dev/null 2>&1
mv -f .deps/staticrootslib.Tpo .deps/staticrootslib.Plo
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing -version-info 1:3:0 -no-undefined -rpath /nowhere -Wl,-R/usr/pkg/lib -o libstaticrootslib.la  staticrootslib.lo ./libgc.la  
libtool: link: gcc -shared  -fPIC -DPIC  .libs/staticrootslib.o   -Wl,-rpath,/usr/pkgsrc/devel/boehm-gc/work/gc-7.2/.libs -Wl,-rpath,/usr/pkg/lib -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib  -O2 -Wl,-R/usr/pkg/lib   -Wl,-soname -Wl,libstaticrootslib.so.1 -o .libs/libstaticrootslib.so.1.0.3
libtool: link: (cd ".libs" && rm -f "libstaticrootslib.so.1" && ln -s "libstaticrootslib.so.1.0.3" "libstaticrootslib.so.1")
libtool: link: (cd ".libs" && rm -f "libstaticrootslib.so" && ln -s "libstaticrootslib.so.1.0.3" "libstaticrootslib.so")
libtool: link: ar cru .libs/libstaticrootslib.a  staticrootslib.o
libtool: link: ranlib .libs/libstaticrootslib.a
libtool: link: ( cd ".libs" && rm -f "libstaticrootslib.la" && ln -s "../libstaticrootslib.la" "libstaticrootslib.la" )
gmake[2]: 'gctest' is up to date.
gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT leak_test.o -MD -MP -MF .deps/leak_test.Tpo -c -o leak_test.o `test -f 'tests/leak_test.c' || echo './'`tests/leak_test.c
mv -f .deps/leak_test.Tpo .deps/leak_test.Po
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing  -Wl,-R/usr/pkg/lib -o leaktest leak_test.o ./libgc.la  
libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/leaktest leak_test.o  -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib
gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT middle.o -MD -MP -MF .deps/middle.Tpo -c -o middle.o `test -f 'tests/middle.c' || echo './'`tests/middle.c
mv -f .deps/middle.Tpo .deps/middle.Po
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing  -Wl,-R/usr/pkg/lib -o middletest middle.o ./libgc.la  
libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/middletest middle.o  -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib
gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT smash_test.o -MD -MP -MF .deps/smash_test.Tpo -c -o smash_test.o `test -f 'tests/smash_test.c' || echo './'`tests/smash_test.c
mv -f .deps/smash_test.Tpo .deps/smash_test.Po
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing  -Wl,-R/usr/pkg/lib -o smashtest smash_test.o ./libgc.la  
libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/smashtest smash_test.o  -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib
gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT huge_test.o -MD -MP -MF .deps/huge_test.Tpo -c -o huge_test.o `test -f 'tests/huge_test.c' || echo './'`tests/huge_test.c
mv -f .deps/huge_test.Tpo .deps/huge_test.Po
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing  -Wl,-R/usr/pkg/lib -o hugetest huge_test.o ./libgc.la  
libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/hugetest huge_test.o  -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib
gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT realloc_test.o -MD -MP -MF .deps/realloc_test.Tpo -c -o realloc_test.o `test -f 'tests/realloc_test.c' || echo './'`tests/realloc_test.c
mv -f .deps/realloc_test.Tpo .deps/realloc_test.Po
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing  -Wl,-R/usr/pkg/lib -o realloc_test realloc_test.o ./libgc.la  
libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/realloc_test realloc_test.o  -L./.libs -lgc -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -Wl,-rpath,/usr/pkg/lib
gcc -DHAVE_CONFIG_H   -I./include -I./include -I./libatomic_ops/src -I./libatomic_ops/src  -fexceptions -O2 -fno-strict-aliasing -MT staticrootstest.o -MD -MP -MF .deps/staticrootstest.Tpo -c -o staticrootstest.o `test -f 'tests/staticrootstest.c' || echo './'`tests/staticrootstest.c
mv -f .deps/staticrootstest.Tpo .deps/staticrootstest.Po
/bin/sh ./libtool  --tag=CC   --mode=link gcc -fexceptions -O2 -fno-strict-aliasing  -Wl,-R/usr/pkg/lib -o staticrootstest staticrootstest.o ./libgc.la  libstaticrootslib.la 
libtool: link: gcc -fexceptions -O2 -fno-strict-aliasing -Wl,-R/usr/pkg/lib -o .libs/staticrootstest staticrootstest.o  -L/usr/pkgsrc/devel/boehm-gc/work/gc-7.2/.libs -L./.libs -L/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/.buildlink/lib -lstaticrootslib -lgc -Wl,-rpath,/usr/pkg/lib -Wl,-rpath,/nowhere
gmake[2]: 'test_cpp' is up to date.
gmake[2]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake  check-TESTS
gmake[2]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake[3]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
PASS: gctest
PASS: leaktest
PASS: middletest
PASS: smashtest
PASS: hugetest
PASS: realloc_test
PASS: staticrootstest
PASS: test_cpp
gmake[4]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake[5]: Entering directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake[5]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake[4]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
============================================================================
Testsuite summary for gc 7.2
============================================================================
# TOTAL: 8
# PASS:  8
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================
gmake[3]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake[2]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
gmake[1]: Leaving directory '/u0/n0/gdt/NetBSD-current/pkgsrc/devel/boehm-gc/work/gc-7.2'
----------------------------------------

[-- Attachment #2: Type: application/pgp-signature, Size: 180 bytes --]

Re: boehm-gc troubles with 2.0.10 on NetBSD/i386

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> Greg Troxel <gdt@ir.bbn.com> writes:
>
>> There's a draft package for guile 2.  boehm-gc in pkgsrc on NetBSD is
>> built without threads, and I have --disable-threads passed to guile's
>> configure.
>
> As documented in our README and the output of ./configure --help,
> "--without-threads" is the option you should be using.  To be honest,
> I'm not sure what "--disable-threads" will do, if anything.  It's
> possible that gnulib is somehow enabling that option to be accepted
> without an error.

As for all unrecognized options, ./configure prints a warning and
ignores it.

Ludo’.