Re: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 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:10:14PM +1100, Andrew Reilly wrote: Hi Marius, On Tue, 22 Jan 2008 10:33:27 +0100 Marius Strobl [EMAIL PROTECTED] 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). Ok, in your previous mail you talked about an exisiting binary so I assumed you haden't tried with a recompiled one or a recompiled one didn't exhibit the problem. Anyway, you're right and I've overlooked that mred is threaded anyway so in this case it shouldn't matter if __gthread_active_p() prevously returned false-positives or not. The only way I currently can think of the new __gthread_active_p() causing problems would be if now it returned false-negatives. So far I can't reproduce such a problem nor see how that could happen though. It would help if you could debug where mred craches and what __gthread_active_p() returned in this case. Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, 2008-01-22 at 21:10 +1100, Andrew Reilly wrote: Hi Marius, On Tue, 22 Jan 2008 10:33:27 +0100 Marius Strobl [EMAIL PROTECTED] 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. Am I right to assume that this is *not* i386? I have 7-PRERELEASE (i386) cvsup'ed on January 22, early morning EST, and mred built from vanilla 372 sources (per your earlier recommendation) on January 8th. They seem to be pretty happy with each other. If there is any information I can provide that will help you with your quest, please, let me know. Cheers, -- Alexandre Sunny Kovalenko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7-STABLE regression that breaks lang/drscheme is src/contrib/gcc/gthr-posix.h 1.1.1.8.2.1
On Tue, 22 Jan 2008 19:41:54 -0500
Alexandre \Sunny\ Kovalenko [EMAIL PROTECTED] wrote:
Am I right to assume that this is *not* i386? I have 7-PRERELEASE (i386)
cvsup'ed on January 22, early morning EST, and mred built from vanilla
372 sources (per your earlier recommendation) on January 8th. They seem
to be pretty happy with each other. If there is any information I can
provide that will help you with your quest, please, let me know.
You're correct, I'm running an amd64 system, and it turns out
that a bunch of the garbage collection code is different/more
complicated in that case. And it contains a bug:
Found it, and fixed it. Works fine in my test-build at -O0, and
I'm just re-building at -O2 to make sure...
--- plt-372.orig/src/mzscheme/gc2/newgc.c 2007-10-08 21:40:43.0 +1
000
+++ plt-372/src/mzscheme/gc2/newgc.c2008-01-23 11:21:25.0 +1100
@@ -260,13 +260,13 @@ inline static struct mpage **create_page
pos = (unsigned long)p 48;
page_maps = page_mapss[pos];
if (!page_maps) {
-page_maps = (struct mpage ***)malloc(sizeof(struct mpage **) * (1 16));
+page_maps = (struct mpage ***)calloc(1 16, sizeof(struct mpage **));
page_mapss[pos] = page_maps;
}
pos = ((unsigned long)p 32) ((1 16) - 1);
page_map = page_maps[pos];
if (!page_map) {
-page_map = (struct mpage **)malloc(sizeof(struct mpage *) * (1
USEFUL_ADDR_BITS));
+page_map = (struct mpage **)calloc(1 USEFUL_ADDR_BITS, sizeof(struct
mpage *));
page_maps[pos] = page_map;
}
return page_map;
In essence, it was using malloc to create second-tier page maps
on the fly, and assuming (incorrectly) that the memory returned
would be initialized to zero. What's mildly confusing, then,
is that the memory that it was getting here in the pre-Jan-5
version of the system *was* zero. Probably just luck. Let this
be a lesson: I should have turned on the malloc-debug knob in
the first instance.
I'll feed the patches (I've also made some tweaks to ensure that
it all compiles with -Werror-implicit-function-declaration,
because that's usually a good source of breakage on 64-bit
systems) up-stream, and see what happens. I'll add the new
patches to the port PR, too.
Thanks, everyone, for your patience with my red-herring reports.
--
Andrew
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
