Another update - I left the free commented out (as you suggested), installed gcc48 from ports (/usr/ports/lang/gcc48) and was able to build using:
make unix-style PREFIX=$INSTALL_DIR CONFIGURE_ARGS_qq="--disable-gracket --disable-places --disable-futures --disable-docs --disable-extflonum --disable-strip" CC=/usr/local/bin/gcc48 CPP=/usr/local/bin/cpp48 LDFLAGS="-Wl,-rpath=/usr/local/lib/gcc48" I'm not super comfortable using this build - is the free I commented out per-thread? Or a one time thing? We use one or more threads per connection we accept, so it could add up quickly. -Nick On Sun, Mar 8, 2015 at 8:05 PM, Nick Sivo <[email protected]> wrote: > I was just about to reply and say that I'd refreshed enough to on gdb > and --disable-strip to track the crash down to that line. > > Commenting out the free allows the build to progress to a new failure: > > https://gist.github.com/kogir/ccf98a0b39d50c3d5851 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 801c06800 (LWP 100506/racketcgc)] > 0x0000000800855009 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 > (gdb) bt > #0 0x0000000800855009 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 > #1 0x000000080085389d in dl_iterate_phdr () from /libexec/ld-elf.so.1 > #2 0x0000000800854981 in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 > #3 0x00000008008547bc in _rtld_get_stack_prot () from /libexec/ld-elf.so.1 > #4 0x0000000800851fa0 in _r_debug_postinit () from /libexec/ld-elf.so.1 > #5 0x0000000800851bbb in _r_debug_postinit () from /libexec/ld-elf.so.1 > #6 0x0000000800851919 in _r_debug_postinit () from /libexec/ld-elf.so.1 > #7 0x000000080084f15d in .text () from /libexec/ld-elf.so.1 > #8 0x0000000800ea4ef6 in write () from /lib/libthr.so.3 > #9 0x0000000000537041 in child_done (ingored=<value optimized out>) > at ../../../racket/src/port.c:10839 > #10 0x0000000800ea747a in swapcontext () from /lib/libthr.so.3 > #11 0x0000000800ea7062 in sigaction () from /lib/libthr.so.3 > #12 <signal handler called> > #13 0x00000008011e08ba in nanosleep () from /lib/libc.so.7 > #14 0x00000008011e0436 in usleep () from /lib/libc.so.7 > #15 0x0000000800ea4d33 in usleep () from /lib/libthr.so.3 > #16 0x0000000000536e78 in green_thread_timer (data=0x801c16100) at > ../../../racket/src/port.c:11022 > #17 0x00000000005eca8a in mzrt_thread_stub (data=0x801c1c060) at > ../../../racket/src/mzrt.c:170 > #18 0x0000000800ea24f5 in pthread_create () from /lib/libthr.so.3 > #19 0x0000000000000000 in ?? () > (gdb) > > On Sun, Mar 8, 2015 at 7:50 PM, Matthew Flatt <[email protected]> wrote: >> I'm so far unable to replicate this problem in exactly the same way on >> FreeBSD 10.1. Still, when I build racketcgc and try to run it in gdb, I >> usually get a segfault from free() in a helper thread that Racket >> creates on startup. >> >> I don't see why it's a problem, but commenting out the >> >> free(data); >> >> on line 168 of "mzrt.c" avoids the crash. >> >> Does commenting out that line have any effect on your build? >> >> At Sun, 8 Mar 2015 16:57:20 -0700, "'Nick Sivo' via Racket Developers" wrote: >>> I've dug into this a bit more. At first I suspected that version >>> checking didn't properly handle the 10 > 9 scenario, but nothing in >>> the configure log looks incorrect. The same results are produced on >>> FreeBSD 9.3 and 10.1 systems. >>> >>> Now I'm starting to suspect it may be differences with clang vs gcc. >>> Was anything special required to support clang on OS X? I wasn't able >>> to find any special handling of clang vs gcc, but may have missed it. >>> >>> On Sat, Mar 7, 2015 at 6:11 PM, Nick Sivo <[email protected]> wrote: >>> > Hi, >>> > >>> > I'm having trouble building Racket on FreeBSD 10.1. I tried both 6.1.1 and >>> > the latest code from trunk. >>> > >>> > A build log (trunk) can be viewed here: >>> > https://gist.github.com/kogir/822107d011fe0d9b7518 >>> > >>> > I'm going to try to disable stripping and see where I get with gdb, but >>> > it's >>> > been ages and I'm not hopeful. Any pointers are welcome. >>> > >>> > Thanks, >>> > Nick >>> > >>> > >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Racket Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/racket-dev/CAHuRc-_Zta0S2xrp7MYasPVfhESiT0vcs >>> f%3DPNTpGApaXebuzgw%40mail.gmail.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Racket Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-dev/20150309025003.3BB3B6501B8%40mail-svr1.cs.utah.edu. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAHuRc-8vVeO9nW3%2BiRSNJdVPyv4z%2Bvm-r7pQn307xErDG5b09Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
