Now, what I suspect the problem is related to is that I am having a daemon
spawning a child any time somebody connects to it. I understand from the
documentation (hopefully correctly) that I should not do the
curl_global_init - curl_global_cleanup each time a child is forked. So,
instead I am calling curl_global_init at the time the parent process starts.
Then I should call curl_easy_init and curl_easy_cleanup in each child. But
is crashes the first time a child is forked in the way I described below. Do
I misunderstand something completely?
Due to the nature of this architecture, it is not very easy to debug...
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Thursday, December 14, 2006 7:05 PM
To: libcurl development
Subject: Re: crash in curl_easy_init
On Thu, 14 Dec 2006, Vajda Zoltán wrote:
> I started using cURL on SunOS 5.8 with the example source
> getinmemory.c as it is provided. Statically linked it works fine.
> However, if I dinamically link the libcurl.so.4.0.0 into my
> application together with other libraries and call the function (the
> same as in main() in the above example source), there is a core dump
> generated during
> ----------------- lwp# 1 / thread# 1 --------------------
> fcaa5c28 Curl_open (1b, 0, 0, 0, 0, ffbeeea4) + 114
> fcab2308 curl_easy_init (0, 0, 0, 0, 0, 0) + 44 fca1e570 curltest
> (ffbeefa8, fca52660, fca52648, 4f, 0, 12b864) + 30
Curl_open() doesn't do anything complicated. This is not a problem caused by
libcurl itself, but rather something weird in your environment. Perhaps
you've screwed up the memory before the call so the malloc() or similar
Can you rebuild curl with debug enable and see exctly what source line it
crashes on and what the contents of the relevant local variables are at that
Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2006-12-15