freebsd stable - Jan 2008 - 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1

Hello again,

[to recap: drscheme, (which is an IDE that runs under the "mred"
runtime, built from ports/lang/drscheme (or actually manually
from a personal copy of that Makefile that builds the current
release:  372, rather than ver 370 in ports)) worked beautifully
on my system until I updated to 7-STABLE after 4 Jan.  I track
-STABLE every week or two.  After that, it segfaults before
printing or displaying anything, and running under gdb has found
that it stops in the garbage collector initialization.  I
haven't raised a PR for this yet because I still think that the
problem is probably the drscheme FreeBSD configuration that has
bit-rotted a little, now that FreeBSD has changed slightly.
Still investigating...  I've cc'd Joseph Koshy, because this
seems to be somehow related to PR ports/118808.]

I've done the binary search through CVS, and established that
the precise file and revision that is causing me (or rather,
drscheme) grief: src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1 marius
at 5 Jan 22:58.51.  Csupping back to 5 Jan 22:50 is enough to
make everyting happy again.

Unfortunately, I'm at a loss to explain how this change could be
causing an existing binary to run or not, because it changes the
compiler.  Well, presumably it changes the installed libc.so and
libstdc++.so, both of which are linked in at run-time (c++ is used
in mred/drscheme for the wxWidgets GUI).  Indeed, the most recent
time that I backed this revision of gthr-posix.h out (regressed
to 5 Jan 22:50), drscheme started to work as soon as the system
libraries had been installed, before I had rebooted.

Since there hasn't been any other wailing about incompatability
since this change, my guess is that mred was somehow working
around the previous FreeBSD behaviour: it has quite a bit of
low-level platform-specific configuration, since it is a
language runtime.  The ideal solution will be to figure out how
to tweak it's FreeBSD compatability to suit the new operation.
If anyone can offer a hint as to which area I should be looking
at for configuration knobs, I'd be really grateful.

Extra data:  ldd mred:
/usr/local/bin/mred:
	libmred3m-372.so => /usr/local/lib/libmred3m-372.so (0x800639000)
	libmzscheme3m-372.so => /usr/local/lib/libmzscheme3m-372.so (0x800a40000)
	libXaw8.so.8 => /usr/local/lib/libXaw8.so.8 (0x800e0f000)
	libXmu.so.6 => /usr/local/lib/libXmu.so.6 (0x800f7c000)
	libXt.so.6 => /usr/local/lib/libXt.so.6 (0x801094000)
	libSM.so.6 => /usr/local/lib/libSM.so.6 (0x8011f4000)
	libICE.so.6 => /usr/local/lib/libICE.so.6 (0x8012fc000)
	libXext.so.6 => /usr/local/lib/libXext.so.6 (0x801416000)
	libGL.so.1 => /usr/local/lib/libGL.so.1 (0x801526000)
	libXft.so.2 => /usr/local/lib/libXft.so.2 (0x8016a2000)
	libcairo.so.2 => /usr/local/lib/libcairo.so.2 (0x8017b5000)
	libfontconfig.so.1 => /usr/local/lib/libfontconfig.so.1 (0x801934000)
	libfreetype.so.9 => /usr/local/lib/libfreetype.so.9 (0x801a67000)
	libexpat.so.6 => /usr/local/lib/libexpat.so.6 (0x801be1000)
	libglitz.so.1 => /usr/local/lib/libglitz.so.1 (0x801d04000)
	libXrender.so.1 => /usr/local/lib/libXrender.so.1 (0x801e2d000)
	libX11.so.6 => /usr/local/lib/libX11.so.6 (0x801f36000)
	libXau.so.6 => /usr/local/lib/libXau.so.6 (0x80213a000)
	libXdmcp.so.6 => /usr/local/lib/libXdmcp.so.6 (0x80223d000)
	librpcsvc.so.4 => /usr/lib/librpcsvc.so.4 (0x802342000)
	libpng.so.5 => /usr/local/lib/libpng.so.5 (0x80244b000)
	libz.so.4 => /lib/libz.so.4 (0x802571000)
	libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 (0x802686000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x8027a7000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x8029a0000)
	libm.so.5 => /lib/libm.so.5 (0x802b9f000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802cb9000)
	libthr.so.3 => /lib/libthr.so.3 (0x802dc6000)
	libc.so.7 => /lib/libc.so.7 (0x802edc000)
	libXpm.so.4 => /usr/local/lib/libXpm.so.4 (0x8030f9000)
	libXp.so.6 => /usr/local/lib/libXp.so.6 (0x80320a000)
	libXxf86vm.so.1 => /usr/local/lib/libXxf86vm.so.1 (0x803312000)
	libXdamage.so.1 => /usr/local/lib/libXdamage.so.1 (0x803417000)
	libXfixes.so.3 => /usr/local/lib/libXfixes.so.3 (0x803519000)
	libdrm.so.2 => /usr/local/lib/libdrm.so.2 (0x80361e000)

ldd mzscheme (which works just fine: it's the command-line
language, without the wxWidgets GUI, but using exactly the same
garbage collector):
/usr/local/bin/mzscheme:
	libmzscheme3m-372.so => /usr/local/lib/libmzscheme3m-372.so (0x800638000)
	libm.so.5 => /lib/libm.so.5 (0x800a07000)
	libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x800b21000)
	libc.so.7 => /lib/libc.so.7 (0x800d1a000)

Cheers,

-- 
Andrew

Hi Marius,

On Tue, 22 Jan 2008 10:33:27 +0100
Marius Strobl <marius@alchemy.franken.de> wrote:
> The __gthread_active_p(), which returns false positives prior
> to the current version of gthr-posix.h, isn't only used in
> libstdc++ but also in headers that are installed beneath
> /usr/include/c++. So the code in those headers compiled into
> an existing binary which was built prior to the gthr-posix.h
> fix still might erroneously determine that it's running in a
> threaded environment while f.e. libstdc++ does not, causing
> the problems you see. Did you try a mred built on a stock
> 7-STABLE?
When it first stopped working (around the 11th, from memory), my
first approach was to rebuild it (over and over, and attempt to
debug it...)  No joy that way.  It's only since I reverted to
the earlier version of FreeBSD that it's started working again.

As part of the attempt to make mred work again, I re-built
*all* of the ports that I have installed (some 900-odd), so
all of the libraries in /usr/local/lib are post-15 Jan., and
have whatever effect the change introduces.  Perhaps that is
why epiphany has gone unstable on me (seems to be complaining
about failing to connect to gnomevfs).  I suspect that mred
wasn't minding false-positives before, because it's been
configured/compiled with pthreads enabled (for the benefit of
Mesa/OpenGL, apparently).

If you think that it might help to track things down, I can jump
forward to -STABLE again and rebuild at least all of mred's
dependencies, but that's going to be a slow process...

Reckon I'll give that a go.  No point staying in the past, now
that we know where abouts the breakage occurred.

Cheers,

-- 
Andrew

On Tue, Jan 22, 2008 at 09:44:05AM +1100, Andrew Reilly
wrote:
> Hello again,
> 
> [to recap: drscheme, (which is an IDE that runs under the "mred"
> runtime, built from ports/lang/drscheme (or actually manually
> from a personal copy of that Makefile that builds the current
> release:  372, rather than ver 370 in ports)) worked beautifully
> on my system until I updated to 7-STABLE after 4 Jan.  I track
> -STABLE every week or two.  After that, it segfaults before
> printing or displaying anything, and running under gdb has found
> that it stops in the garbage collector initialization.  I
> haven't raised a PR for this yet because I still think that the
> problem is probably the drscheme FreeBSD configuration that has
> bit-rotted a little, now that FreeBSD has changed slightly.
> Still investigating...  I've cc'd Joseph Koshy, because this
> seems to be somehow related to PR ports/118808.]
> 
> I've done the binary search through CVS, and established that
> the precise file and revision that is causing me (or rather,
> drscheme) grief: src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1 marius
> at 5 Jan 22:58.51.  Csupping back to 5 Jan 22:50 is enough to
> make everyting happy again.
> 
> Unfortunately, I'm at a loss to explain how this change could be
> causing an existing binary to run or not, because it changes the
> compiler.  Well, presumably it changes the installed libc.so and
> libstdc++.so, both of which are linked in at run-time (c++ is used
> in mred/drscheme for the wxWidgets GUI).  Indeed, the most recent
> time that I backed this revision of gthr-posix.h out (regressed
> to 5 Jan 22:50), drscheme started to work as soon as the system
> libraries had been installed, before I had rebooted.
The __gthread_active_p(), which returns false positives prior
to the current version of gthr-posix.h, isn't only used in
libstdc++ but also in headers that are installed beneath
/usr/include/c++. So the code in those headers compiled into
an existing binary which was built prior to the gthr-posix.h
fix still might erroneously determine that it's running in a
threaded environment while f.e. libstdc++ does not, causing
the problems you see. Did you try a mred built on a stock
7-STABLE?
> 
> Since there hasn't been any other wailing about incompatability
> since this change, my guess is that mred was somehow working
> around the previous FreeBSD behaviour: it has quite a bit of
> low-level platform-specific configuration, since it is a
> language runtime.  The ideal solution will be to figure out how
> to tweak it's FreeBSD compatability to suit the new operation.
> If anyone can offer a hint as to which area I should be looking
> at for configuration knobs, I'd be really grateful.
> 
Marius

Andrew Reilly wrote:
> Hello again,
> 
> [to recap: drscheme, (which is an IDE that runs under the "mred"
> runtime, built from ports/lang/drscheme (or actually manually
> from a personal copy of that Makefile that builds the current
> release:  372, rather than ver 370 in ports)) worked beautifully
> on my system until I updated to 7-STABLE after 4 Jan.  I track
> -STABLE every week or two.  After that, it segfaults before
> printing or displaying anything, and running under gdb has found
> that it stops in the garbage collector initialization.  I
> haven't raised a PR for this yet because I still think that the
> problem is probably the drscheme FreeBSD configuration that has
> bit-rotted a little, now that FreeBSD has changed slightly.
> Still investigating...  I've cc'd Joseph Koshy, because this
> seems to be somehow related to PR ports/118808.]
[...]

I had similar problems whith lang/drscheme. It refused to build ever 
since I switched to RELENG_7.
Building it from source (version 370 and 371) wasn't succesfull at all:
first it refused to find some X includes (which are present), then it 
wouldn't finish compiling because of a coredump in mred/mzscheme (I 
don't recall which one it was). My first thought was a broken compiler, 
but using gcc34 and icc 8.1 wasn't succesfull either ;-) After that, I 
decided not to spend any more time because I didn't know what steps were 
appropriate to take...


I just did compile Drscheme 372 with a "patched" Makefile of the port:
- uncomment this line: BROKEN=         Fails to install (signal 11)
- adapt distinfo:
MD5 (drscheme/372/plt-372-src-unix.tgz) = 751217f63bc64423a29a05423f917af8
SHA256 (drscheme/372/plt-372-src-unix.tgz) = 
6b635b41fcb27acbd1eaa773c88eb2c1131e9857b104c8ec1b111cff2d7fb2ec
SIZE (drscheme/372/plt-372-src-unix.tgz) = 15267684
- make; make install


This may be not the most correct way, but it works for me.

I'm running FreeBSD 7.0-PRERELEASE as of Jan 17 2008.


Regards,
Philipp