[darcs-devel] [issue472] bad interaction between withCString and libcurl

[Daniel Gorín]

New submission from =?ISO-8859-1?Q?Daniel_Gor=EDn?= <dgorin at dc.uba.ar>:

Hi

I've been having some non-deterministic misbehaviour when interacting  
with repositories via http. For example, running several times "darcs  
send -o my_patch http://some/repo" would give alternatively one of  
this results:

- "Can't understand repository"
- Darcs tries to send ALL the patches in my local repo (most came  
from the remote repo)
- Darcs behaves properly

I tracked down the error and I understand it boils down to this: non- 
deterministacally, libcurl is returning, instead of a 404 error, the  
webserver-generated document containing the 404 error (i.e. it is  
behaving as curl without the -f flag). Depending the moment in the  
execution of darcs where this misbehaviour occurs, I get the  
different results above (when it does not occur, darcs works fine).

Now, why is this happening? I think the reason is this: in Curl.hs,  
there is this function:

copyUrl u f cache =
   withCString darcs_version $ \vstr ->
   withCString u $ \ustr ->
   withCString f $ \fstr -> do
   ppwd <- getProxyUserPwd
   withCString ppwd $ \pstr -> do
   err <- get_curl vstr pstr fstr ustr (cachableToInt cache)
   when (err /= 0) $ fail $ ...

It calls get_curl, defined in hscurl.c, which in turn uses a _static_  
variable "c", that is created using curl_easy_init and managed with  
curl_easy_setopt.

However, the manpage for curl_easy_setopt states:

"Strings passed to libcurl as 'char *' arguments, will not be copied  
by the library. Instead you should keep them available until libcurl  
no longer needs them. Failing to do so will cause very odd behavior  
or even crashes. libcurl will need them until you call  
curl_easy_cleanup(3) or you set the same option again to use a  
different pointer."

while the documentation for withCString says:

"the memory is freed when the subcomputation terminates (either  
normally or via an exception), so the pointer to the temporary  
storage must not be used after this."

I was able to come up with a small test case that non- 
deterministically fails on my computer and I can confirm that, by not  
reusing the curl handler, the misbehaviour vanishes (incidentally, it  
also runs much faster). I'm attaching it but, due to the nature of  
this error, I'm not confident it will also fail elsewhere.

For the record, I had this issue using darcs 1.0.8 (installed through  
macports) and darcs 1.0.9 (compiled from sources). Curl version is  
7.16.1 (also from macports), and I'm running an Intel-based Mac,  
running OS X 10.4.9

Thanks
Daniel

----------
files: t.hs, test_curl.c, test_curl.h, unnamed
messages: 1718
nosy: EricKow, beschmi, dgorin, droundy, tommy
status: unread
title: bad interaction between withCString and libcurl

____________________________________
Darcs issue tracker <bugs at darcs.net>
<http://bugs.darcs.net/issue472>
____________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.hs
Type: application/octet-stream
Size: 1026 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070615/7f3d2099/t.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_curl.c
Type: application/octet-stream
Size: 2580 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070615/7f3d2099/test_curl.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_curl.h
Type: application/octet-stream
Size: 125 bytes
Desc: not available
Url : http://lists.osuosl.org/pipermail/darcs-devel/attachments/20070615/7f3d2099/test_curl-0001.obj
-------------- next part --------------