On Sat, May 10, 2014 at 10:53 AM, Gerald Gutierrez < gerald.gutier...@gmail.com> wrote:
> frame #2: 0x00007fff8fbf7264 libcrypto.0.9.8.dylib`BIO_read + 100 > frame #3: 0x00007fff86b6513d libssl.0.9.8.dylib`ssl3_read_n + 365 > frame #4: 0x00007fff86b65b9f libssl.0.9.8.dylib`ssl3_read_bytes + 735 > frame #5: 0x00007fff86b63dec libssl.0.9.8.dylib`ssl3_read + 156 > frame #6: 0x00007fff86b4e4c9 libssl.0.9.8.dylib`ssl_read + 73 > frame #7: 0x00007fff8fbf7264 libcrypto.0.9.8.dylib`BIO_read + 100 > frame #8: 0x0000000105719ba2 fossil`ssl_receive(NotUsed=<unavailable>, > pContent=<unavailable>, N=<unavailable>) + 50 at http_ssl.c:399 > > So, it's hanging in the BIO_read function. > As your (very lovely, btw) stack trace shows, that is > ... > frame #9: 0x000000010571a3a6 fossil`transport_fetch(pUrlData=<unavailable>, > zBuf=0x00007fa1c2e078b0, N=1000) + 102 at http_transport.c:311 > two levels removed from fossil. The hang is happening via libcrypo, two DLLs removed from fossil's process. i.e. it is very unlikely that this is a fossil bug. > -> 311 got = ssl_receive(0, zBuf, N); > There's not much fossil can do wrong with that call, provided its ranges are valid. This seems to me to be a clear case of an upstream problem. (But i'm not always right!) -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
