Andrew Reilly
2008-Jan-21 17:15 UTC
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
Andrew Reilly
2008-Jan-22 02:10 UTC
7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
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
Marius Strobl
2008-Jan-22 02:13 UTC
7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
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
Philipp Ost
2008-Jan-23 21:14 UTC
7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
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