hsenv segfaults on OS X when using the --ghc flag about hsenv

[tmhedberg]

It looks like hsenv wasn't initializing OpenSSL properly, which we got away with until now because haskell.org didn't used to redirect HTTP requests (e.g. for downloading GHC tarballs) to HTTPS, but now it does.

Anyway, the bug should be fixed now. Thanks for reporting it.

[yfyf]

I seem to be running into the same issue, in particular it segfaults because of an HTTP 302. If you tell me how I can help you with debugging this, I'll be glad to help.

Also, unrelated and please feel free to ingore this opinion, but I would very much recommend re-considering issue #23, because protocol-related problems will always haunt you + using cURL would allow to fetch GHC tarballs from many more places than just HTTP endpoints (SCP/SFTP/etc), which is a great feature.

λ uname -a
Linux zebra 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux
λ hsenv --version
0.5
λ dpkg --status openssl
Package: openssl
<..>
Version: 1.0.1k-3
Depends: libc6 (>= 2.15), libssl1.0.0 (>= 1.0.1)
λ strace hsenv --ghc=7.8.4
execve("/home/yfyf/bin/hsenv", ["hsenv", "--ghc=7.8.4"], [/* 45 vars */]) = 0
<..>
sendto(7, "GET /ghc/dist/7.8.4/ghc-7.8.4-x8"..., 164, 0, NULL, 0) = 164
recvfrom(7, 0x2915690, 4096, 0, 0, 0)   = -1 EAGAIN (Resource temporarily unavailable)
epoll_ctl(3, EPOLL_CTL_ADD, 7, {EPOLLIN, {u32=7, u64=7}}) = 0
write(6, "\1\0\0\0\0\0\0\0", 8)         = 8
futex(0x290f11c, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x290f118, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
futex(0x290f148, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0xde1b58, FUTEX_WAKE_PRIVATE, 1)  = 1
futex(0x290effc, FUTEX_WAIT_PRIVATE, 7, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
rt_sigreturn({mask=[]})                 = 202
<..>
futex(0x290effc, FUTEX_WAIT_PRIVATE, 7, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
rt_sigreturn({mask=[]})                 = 202
futex(0x290effc, FUTEX_WAIT_PRIVATE, 7, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
rt_sigreturn({mask=[]})                 = 202
futex(0x290effc, FUTEX_WAIT_PRIVATE, 7, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
rt_sigreturn({mask=[]})                 = 202
futex(0x290effc, FUTEX_WAIT_PRIVATE, 7, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=0}} ---
rt_sigreturn({mask=[]})                 = 202
futex(0x290effc, FUTEX_WAIT_PRIVATE, 7, NULL) = 0
futex(0x290f028, FUTEX_WAKE_PRIVATE, 1) = 0
recvfrom(7, "HTTP/1.1 302 Moved Temporarily\r\n"..., 4096, 0, NULL, NULL) = 593
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++
Segmentation fault

[tmhedberg]

I haven't actually released the fixed version to Hackage yet, so if you're using the Hackage version, then that probably explains the segfault. I'll get a new release uploaded soon; my apologies for not doing that more promptly. In the mean time, try it with the latest from GitHub and see if that solves it for you.

Regarding cURL, I'm not really opposed to the idea of going back to using an external binary for downloads, but it does come with its own set of tradeoffs. I'll consider it. I'm not sure how much widespread use there would be for non-HTTP protocols for downloading tarballs, seeing as how the vast majority of people who use that feature just want to grab the latest official GHC release (or candidate), which is always available over HTTP. But it probably can't hurt to make it possible, regardless. If you want to expedite the process, patches are always welcome. :)

[yfyf]

I haven't actually released the fixed version to Hackage yet, so if you're using the Hackage version, then that probably explains the segfault.

Ah, ok! Tried out the GH, it works "OK", but now 404s, since I think the URLs have changed on haskell.org:

[~/sandbox/test-bah]λ hsenv --ghc=7.8.4
Creating Virtual Haskell directory structure
Installing GHC
Failed to download /home/yfyf/sandbox/test-bah/ghc-download31192/tarball: http response returned 404

hsenv.log file contains detailed description of the process.
[~/sandbox/test-bah]λ cat hsenv.log 
Creating Virtual Haskell directory structure
<..>
Installing GHC
  Downloading GHC from http://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux.tar.bz2

Failed to download /home/yfyf/sandbox/test-bah/ghc-download31192/tarball: http response returned 404

Regarding cURL, I'm not really opposed to the idea of going back to using an external binary for downloads, but it does come with its own set of tradeoffs.

From the harsh experience of pretty much always burning my hands when 1) needing/wanting to handle arbitrary URLs 2) not using cURL, I am always advocating cURL. Especially so because with hsenv you do not care so much about Windows support and cURL is universally available on Linux/*BSD, usually with well-tested an bug-free packing. I think it's definitely simpler to just say "you need cURL with SSL/TLS support", than trying to figure out which Haskell packages do this reliably and maintaining that yourself.

If you want to expedite the process, patches are always welcome. :)

I'll see what I can do.

[yfyf]

It seems the tarball naming changes between 7.6.* and 7.8.*, all of the later Linux tarballs are suffixed with either -deb7 or -centos65. Ugh.

In theory you could fix this with some heuristic, like checking whether rpm or deb commands are available, but that is not reliable since some people have rpm available on deb-based systems and vice-versa. Perhaps it's best to ask for an explicit input in case of Linux and GHC version requested >= 7.8.* (via a flag or so).