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/1425934674548.85d088e1%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.
