Building on FreeBSD 10.1 (x64)

[Nick Sivo]

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

[Nick Sivo]

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.

[Matthew Flatt]

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?

> --
> 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 racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> 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.

[Nick Sivo]

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)

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20150309025003.3BB3B6501B8%40mail-svr1.cs.utah.edu.

[Nick Sivo]

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

[Nick Sivo]

Also, since I didn't explicitly state it - leaving the free in and using GCC still fails.

-Nick

[Matthew Flatt]

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?

[Nick Sivo]

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

[Nick Sivo]

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!

[Matthew Flatt]

At Mon, 09 Mar 2015 13:57:55 -0700 (PDT), "Nick Sivo" wrote:
> 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?

After looking through the change logs and thinking about it for a
while, I'm not sure why I left OS X and Linux as special cases when I
added the rlimit code to compute the default stack size. I was probably
just being conservative (i.e., trying to not breaking builds that were
working before). The special case for OS X and Linux probably should be
removed, and I'll try that.