New submission from =?ISO-8859-1?Q?Daniel_Gor=EDn?= <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]> <http://bugs.darcs.net/issue472> ____________________________________
t.hs
Description: Binary data
test_curl.c
Description: Binary data
test_curl.h
Description: Binary data
_______________________________________________ darcs-devel mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-devel
