On Tue, May 26, 2020 at 4:26 PM Daniel Stenberg wrote:
> On Tue, 26 May 2020, James Read wrote:
>
> > So, I guess that's problem solved. Thanks.
>
> Lovely!
>
> With that issue nailed and perhaps with some newfound knowledge in your
> head,
> is there something we should think about to clarify or
On Tue, 26 May 2020, James Read wrote:
So, I guess that's problem solved. Thanks.
Lovely!
With that issue nailed and perhaps with some newfound knowledge in your head,
is there something we should think about to clarify or update in the
documentation that would make this behavior clearer or
On Tue, May 26, 2020 at 3:43 PM Daniel Stenberg wrote:
> On Tue, 26 May 2020, James Read via curl-library wrote:
>
> > When parallel connections reaches 0 g->still_running is still reporting
> a
> > number of easy handles in progress. How can this be? Surely, the answer
> to
> > this question is
On Tue, 26 May 2020, James Read via curl-library wrote:
When parallel connections reaches 0 g->still_running is still reporting a
number of easy handles in progress. How can this be? Surely, the answer to
this question is the answer to the memory leaks?
Your code makes funny assumptions about
On Tue, May 26, 2020 at 2:31 PM James Read wrote:
>
>
> On Tue, May 26, 2020 at 12:47 PM James Read
> wrote:
>
>>
>>
>> On Tue, May 26, 2020 at 7:30 AM Patrick Monnerat via curl-library <
>> curl-library@cool.haxx.se> wrote:
>>
>>> On 5/26/20 1:15 AM, James Read via curl-library wrote:
>>> >
>>>
On Tue, May 26, 2020 at 12:47 PM James Read wrote:
>
>
> On Tue, May 26, 2020 at 7:30 AM Patrick Monnerat via curl-library <
> curl-library@cool.haxx.se> wrote:
>
>> On 5/26/20 1:15 AM, James Read via curl-library wrote:
>> >
>> > git clone https://github.com/JamesRead5737/libcurlmemoryleak.git
>
On Tue, May 26, 2020 at 7:30 AM Patrick Monnerat via curl-library <
curl-library@cool.haxx.se> wrote:
> On 5/26/20 1:15 AM, James Read via curl-library wrote:
> >
> > git clone https://github.com/JamesRead5737/libcurlmemoryleak.git
> >
> > No need to make. Just compile with gcc crawler.c -g -lssl
On 5/26/20 1:15 AM, James Read via curl-library wrote:
git clone https://github.com/JamesRead5737/libcurlmemoryleak.git
No need to make. Just compile with gcc crawler.c -g -lssl -lcurl
Run valgrind with valgrind -v --tool=memcheck --leak-check=full
--show-reachable=yes --track-origins=yes --lo
On Tue, May 26, 2020 at 12:32 AM Jeffrey Walton wrote:
> On Mon, May 25, 2020 at 7:16 PM James Read
> wrote:
> >
> >
> >
> > On Tue, May 26, 2020 at 12:02 AM Jeffrey Walton
> wrote:
> >>
> >> On Mon, May 25, 2020 at 6:27 PM James Read via curl-library
> >> wrote:
> >> >
> >> > ...
> >> >
> >>
On Mon, May 25, 2020 at 7:16 PM James Read wrote:
>
>
>
> On Tue, May 26, 2020 at 12:02 AM Jeffrey Walton wrote:
>>
>> On Mon, May 25, 2020 at 6:27 PM James Read via curl-library
>> wrote:
>> >
>> > ...
>> >
>> > Gmail seems to have taken out all the formatting. Apologies. It should
>> > still
On Tue, May 26, 2020 at 12:02 AM Jeffrey Walton wrote:
> On Mon, May 25, 2020 at 6:27 PM James Read via curl-library
> wrote:
> >
> > ...
> >
> > Gmail seems to have taken out all the formatting. Apologies. It should
> still compile though.
>
> I can't speak for others, but... You should probabl
On Mon, May 25, 2020 at 6:27 PM James Read via curl-library
wrote:
>
> ...
>
> Gmail seems to have taken out all the formatting. Apologies. It should still
> compile though.
I can't speak for others, but... You should probably reduce the code
to a minimal reproducer, and then put it on GitHub or
On Mon, May 25, 2020 at 11:15 PM James Read wrote:
>
>
> On Mon, May 25, 2020 at 10:37 PM Daniel Stenberg wrote:
>
>> On Mon, 25 May 2020, James Read wrote:
>>
>> > I call curl_multi_cleanup here:
>>
>> > I call curl_easy_cleanup here:
>>
>> > What am I missing?
>>
>> I don't think we'll be able
On Mon, May 25, 2020 at 10:37 PM Daniel Stenberg wrote:
> On Mon, 25 May 2020, James Read wrote:
>
> > I call curl_multi_cleanup here:
>
> > I call curl_easy_cleanup here:
>
> > What am I missing?
>
> I don't think we'll be able to tell you that. We can't reproduce this
> problem.
> We don't see
On Mon, 25 May 2020, James Read wrote:
I call curl_multi_cleanup here:
I call curl_easy_cleanup here:
What am I missing?
I don't think we'll be able to tell you that. We can't reproduce this problem.
We don't see any memory leak in any builds on any platforms.
I suggest you write up a
On Mon, May 25, 2020 at 7:56 AM Daniel Stenberg wrote:
> On Sun, 24 May 2020, James Read via curl-library wrote:
>
> > ==78076==by 0x48BBEE0: curl_dbg_calloc (memdebug.c:205)
> > ==78076==by 0x490A1D0: Curl_ssl_initsessions (vtls.c:608)
>
> This is the TLS session ID cache. Do you cleanup
On Sun, 24 May 2020, James Read via curl-library wrote:
==78076==by 0x48BBEE0: curl_dbg_calloc (memdebug.c:205)
==78076==by 0x490A1D0: Curl_ssl_initsessions (vtls.c:608)
This is the TLS session ID cache. Do you cleanup this multi handle correctly?
==78076==by 0x489E601: allocate_
On Sun, May 24, 2020 at 9:56 PM Patrick Schlangen
wrote:
> Am 24.05.2020 um 21:56 schrieb James Read via curl-library <
> curl-library@cool.haxx.se>:
> > ...
> > On closer inspection my valgrind output has the following lines:
> >
> > --69689-- Reading syms from /usr/lib/x86_64-linux-gnu/libcurl.
Am 24.05.2020 um 21:56 schrieb James Read via curl-library
:
> ...
> On closer inspection my valgrind output has the following lines:
>
> --69689-- Reading syms from /usr/lib/x86_64-linux-gnu/libcurl.so.4.6.0
> --69689--object doesn't have a symbol table
>
> So something is definitely wrong
On Sun, May 24, 2020 at 5:43 PM James Read wrote:
>
>
> On Sun, May 24, 2020 at 4:47 PM James Read
> wrote:
>
>>
>>
>> On Sun, May 24, 2020 at 4:07 PM Daniel Stenberg wrote:
>>
>>> On Sun, 24 May 2020, James Read via curl-library wrote:
>>>
>>> > Valgrind reports a memory leak in my web crawler
On Sun, May 24, 2020 at 4:47 PM James Read wrote:
>
>
> On Sun, May 24, 2020 at 4:07 PM Daniel Stenberg wrote:
>
>> On Sun, 24 May 2020, James Read via curl-library wrote:
>>
>> > Valgrind reports a memory leak in my web crawler:
>>
>> ...
>>
>> > What is memory being allocated for?
>>
>> Since
On Sun, May 24, 2020 at 4:07 PM Daniel Stenberg wrote:
> On Sun, 24 May 2020, James Read via curl-library wrote:
>
> > Valgrind reports a memory leak in my web crawler:
>
> ...
>
> > What is memory being allocated for?
>
> Since your stack trace has no debug symbols it is hard for us to tell
> ex
On Sun, 24 May 2020, James Read via curl-library wrote:
Valgrind reports a memory leak in my web crawler:
...
What is memory being allocated for?
Since your stack trace has no debug symbols it is hard for us to tell exactyl
what's going on here.
What do I need to free?
If you use the
On Sun, May 24, 2020 at 1:02 PM Aleksandar Lazic
wrote:
> Hi.
>
> On 24.05.20 02:44, James Read via curl-library wrote:
> > Valgrind reports a memory leak in my web crawler:
> >
> > ==36126== 923,440 bytes in 485 blocks are possibly lost in loss record
> 56 of 56
> > ==36126==at 0x483DD99: ca
Hi.
On 24.05.20 02:44, James Read via curl-library wrote:
> Valgrind reports a memory leak in my web crawler:
>
> ==36126== 923,440 bytes in 485 blocks are possibly lost in loss record 56 of
> 56
> ==36126== at 0x483DD99: calloc (in
> /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd
25 matches
Mail list logo