As a final update: Racket 6.1.1 on FreeBSD 10.1 is now live, powering Hacker News.
An unexpected and glorious side effect of clang in FreeBSD 10.1 vs gcc 4.2.1 in FreeBSD 9.x is that we now actually get back-traces in Racket error messages. Thanks again! On Mon, Mar 9, 2015 at 1:57 PM, Nick Sivo <[email protected]> wrote: > No, thank you! > > That seems to have fixed it for me, and 8192 bytes works fine. I noticed > that in mz_proc_thread_create OS X and Linux are pinned to 8192, should the > same be true for FreeBSD now as well? > > My hack for testing was to add > > if (stacksize < 8192) { > stacksize = 8192; > } > > to mz_proc_thread_create_w_stacksize. We'll run that for now and report any > further issues. I suspect the "right" fix would be to up the stack size > specified in port.c and fix the size in mz_proc_thread_create. > > Thanks a ton for looking into this! > > -Nick > > > On Mon, Mar 9, 2015 at 12:31 PM, Matthew Flatt <[email protected]> wrote: >> >> Thanks for your help! >> >> I think the problem is that Racket tries to start a thread with a stack >> that is too small. If I change the 4096 in start_green_thread_timer() >> in "port.c" to 16384, then I can leave the free() call in place and >> Racket doesn't crash in gdb. >> >> Does increasing that argument to mz_proc_thread_create_w_stacksize() >> fix the problem on your machine? >> >> At Mon, 09 Mar 2015 11:35:39 -0700 (PDT), "Nick Sivo" wrote: >> > 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/CAHuRc-9sUGj5JwT8cngoLaN15vm4ev06fR%2B7kLA7cXS8_0o%3DQA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
