Also, since I didn't explicitly state it - leaving the free in and using GCC still fails.
-Nick On Sun, Mar 8, 2015 at 10:35 PM, Nick Sivo <[email protected]> wrote: > 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/1425926138940.91a6133b%40Nodemailer. For more options, visit https://groups.google.com/d/optout.
