GC range detection not implemented on FreeBSD (druntime fails to build)

[sumo]

FreeBSD xxx 9.1-RELEASE-p17 FreeBSD 9.1-RELEASE-p17

ldc/runtime/druntime/src/rt/sections_ldc.d(301): Error: static assert "TLS range detection not implemented for this OS."
*** [runtime/src/core/thread.o] Error code 1

Wild guess but could this, for FreeBSD, be :

void[] initTLSRanges()
{
auto pbeg = cast(void_)&tlsstart;
auto pend = cast(void)&_tlsend;
return pbeg[0 .. pend - pbeg];
}

as defined in rt/sections_freebsd.d?

[dnadlinger]

Probably, yes. You could try copying that definition over. If you are suddenly getting weird crashes in the test suite, then you know it wasn't it. ;)

Edit: I haven't had a closer look at the *BSDs at all yet, but I think _tlsstart and _tlsend in sections_freebsd.d might be the DMD-generated bracketing symbols. Probably FreeBSD offers something similar to either OS X, Linux or Windows, but I have no idea about its system internals. If you want to help out with this (which would be great, as nobody on the LDC core team regularly uses FreeBSD, as far as I'm aware), I guess the easiest way to proceed would be to ask some of the FreeBSD compiler gurus (IRC/ML/?) about how to determine the address range for TLS data on the current thread.

In case I magically have a chunk of free time at some point to look into this, what would be a good place/VirtualBox image to start from?

[dnadlinger]

(updated comment)

[redstar]

The piece of code above does not work. As first work around I simply copied the Linux version (return null;). Now I get an undefined reference error during linking. The symbols core.sys.freebsd.execinfo.backtrace and core.sys.freebsd.execinfo.backtrace_symbols are missing.

[redstar]

BTW: I downloaded the DVD image from ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.1/ and installed FreeBSD from it. After that I had to add some ports:

pkg_add -r git
pkg_add -r libconfig
pkg_add -r llvm
pkg_add -r cmake

Then I was able to checkout ldc and compile it.

[dnadlinger]

initTLSRanges is called on each new thread, except for the main thread, and can only be skipped on Linux due to a glibc peculiarity (see code comment) – no idea how the FreeBSD libc behaves here.

As for the linking errors, the FreeBSD sys directory probably needs to be added to CMake.

[dnadlinger]

Oh, and thanks for the getting started info, it might come handy at some point (though I should probably fix OS X 10.8 first…).

[redstar]

FreeBSD crashes with the simple implementation. :-) The pull request with the added freebsd files is running now on Travis.

[dnadlinger]

I guess we could try to bring back the old /proc-table-based solution for FreeBSD then, but I have no idea if that has ever correctly worked either (D1 didn't have TLS by default). And even if so, it it still ugly and covers TLS more or less only by accident…

[redstar]

I created a Druntime pull request (dlang/druntime#586) to add missing header files. With these headers, the Linux solution to find the TLS section compiles.
FreeBSD supports _etext, _edata and _end, but I am not sure if this really helps.
Using both approaches, section_ldc.d compiles and a Hello-World program links without problems. But there is a crash in the GC then.

[sumo]

How can I reproduce the crash? I have copied the Linux code for initTLSRanges, initSections, and the supporting elf methods and run a Hello-World and not had a crash. I will try a more complex program and see.

I haven't had a response in the mailing lists so I am going to try the FreeBSD forums.

[sumo]

For druntime - druntime_src_core_thread_release_run is the only test that fails with seg fault. Doing a debug build to try and get a gdb backtrace.

[redstar]

I did exactly what you did: copy the linux code for finding the TLS start address.
The crash appeared in some test cases while calling the free method of the garbage collector. I don't remember right but I think one of the failing unit tests was tsd.bigint.
From my experiments the range from _etext to _end is not the right one. I tried to identify the range using the Elf header which seems to work. Now I have some thread related issues - maybe the same as you get.

[redstar]

I committed a possible solution. Could you please try it? It's enough to pull the latest druntime commit.

[sumo]

I've build the latest head and run tests but the following failures occur:

12 - druntime_src_core_thread_release_run (SEGFAULT)
705 - phobos_std_range_debug_build (OTHER_FAULT)
706 - phobos_std_range_debug_run (Not Run)
762 - phobos_std_regex_debug_run (SEGFAULT)
764 - phobos_std_regex_release_run (SEGFAULT)
842 - phobos_std_parallelism_debug_run (OTHER_FAULT)
865 - phobos_std_datetime_debug_build (OTHER_FAULT)
866 - phobos_std_datetime_debug_run (Not Run)
868 - phobos_std_datetime_release_run (Failed)
877 - phobos_std_algorithm_debug_build (OTHER_FAULT)
878 - phobos_std_algorithm_debug_run (Not Run)
879 - phobos_std_algorithm_release_build (OTHER_FAULT)
880 - phobos_std_algorithm_release_run (Not Run)
949 - phobos_std_net_curl_debug_build (Failed)
950 - phobos_std_net_curl_debug_run (Not Run)
951 - phobos_std_net_curl_release_build (Failed)
952 - phobos_std_net_curl_release_run (Not Run)
1065 - phobos_etc_c_curl_debug_build (Failed)
1066 - phobos_etc_c_curl_debug_run (Not Run)
1067 - phobos_etc_c_curl_release_build (Failed)
1068 - phobos_etc_c_curl_release_run (Not Run)
1078 - dmd-testsuite_debug (Failed)
1080 - dmd-testsuite_release (Failed)

[redstar]

I currently recheck - the test suite is still running. So far I don't get a failure. Especially I do not see the core.thread failure.
The failure of the curl test cases is normally due to linking problems. Could you please execute

bin/ldc2 -unittest -main ../ldc/runtime/phobos/std/net/curl.d

in your build folder to compile the test and check the output?

[sumo]

bin/ldc2 -unittest -main ../runtime/phobos/std/net/curl.d 

failed with an eror about -lcurl

bin/ldc2 -L=-L/usr/local/lib -unittest -main ../runtime/phobos/std/net/curl.d 

succeeded.

[redstar]

What gcc and llvm version do you use? With gcc 4.2.1 and LLVM 3.1 I get:

• compiler faults in std.exception, std.range
• runtime errors in std.datetime, std.regex
• std.net.curl and etc.c.curl builds are failing with linker problem

That's all. Other unit tests seem to work.

BTW: How can I update gcc? The fault in std.exception seems to be an infinite recursion which looks like a gcc bug.

[redstar]

With clang 3.0, the compiler faults are gone. I think I compile a more recent clang/LLVM version myself to verify it.

[sumo]

I used llvm33 and clang33. I don't believe you can update the system compiler.

druntime_src_core_thread_release_run SEGFAULT occurs intermittently. When I run the test 7 times out of 10 it fails with the segfault. I'll add some debug and try again.

[redstar]

I compiled ldc with clang 3.3 and LLVM 3.3 (git checkout). The tests are still running but there is no failure in core.thread so far.

[sumo]

You're right I've upgraded llvm & clang to 3.3.1 and no failure in core.thread.

[sumo]

I spoke too soon.

% ./runtime/druntime_src_core_thread_release 
0x419be8 <???+0> at /usr/home/mediabag/ldc/build/runtime/druntime_src_core_thread_release
zsh: segmentation fault  ./runtime/druntime_src_core_thread_release

I built with

cmake ../ -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX:PATH=/usr/local -DLLVM_CONFIG=/usr/local/bin/llvm-config33 -DCMAKE_C_COMPILER=`which clang33` -DCMAKE_CXX_COMPILER=`which clang++33`

[redstar]

That's funny. After I installed clang & LLVM 3.3, only the runtime errors in std.datetime and std.regex are still there. I am investigation what's going on ...
I have no problem with the unit test of core.thread.

[sumo]

I've tried this on two PC-BSD 9.2 machines (server only so very minimal) and it consistently fails. I am going to try a vanilla FreeBSD 9.2 install to see if that works. Are you able to try a PC-BSD install and see if core.thread fails?

[redstar]

I try. They provide a VirtualBox image - that should be easy going.

[redstar]

I installed PC-BSD 9.2 (amd64) (Desktop, customized with VCS). I only added llvm-3.3, cmake-2.8 and libconfig. I build LDC with clang 3.3 (I set CC and CXX.)
The tests are still running, but again no druntime failure. Like above, the first failure I get is in std.datetime (debug and release).

[redstar]

I' now baffled. After running the tests several times, I get reproducable:

• core.thread segfaults (release only)
• std.datetime and std.process have assertion errors (debug+release)
• std.regex segfaults (debug+release)

I have no glue why the behaviour has changed. I ran the test suite at least 3 times without getting the segfault in `core.thread' but now it's there...
@sumo Are you getting the same results?

[redstar]

std.process fails because the csh (the shell which was installed for my user) does not understand the command echo bar 1>&2. Therefore this unit test depends on (undocumented) externals and can be considered buggy in my eyes.

[sumo]

Pretty much the same results. core.thread release build segfaults more often than not.

ldc itself is segfaulting when compiling but I'll raise another issue when I find the offending code.

[redstar]

@sumo The offending test in core.thread seems to be line 4317. It is the test "Multiple threads running shared fibers" and it crashes in the call to joinAll(). If I disable this test then the unit test of core.thread does not crash.

[sumo]

If its not GC related close this issue and open a new one if you prefer.

[redstar]

@sumo Do you have the same test failures? If yes then I would close this issue and open a new one.

[sumo]

I do have the same test failures. Thanks BTW, very informative seeing you at work.

[dnadlinger]

Very informative to see whom at what work? ;)

[redstar]

As follow up I created issues #495 and #496.