curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: libcurl 7.81.0 via homebrew on macOS clean up issues

From: Ray Satiro via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 18 Jan 2022 02:58:36 -0500

On 1/17/2022 4:06 PM, Gavin Henry via curl-library wrote:
> I'm getting alternate failing tests (my own tests) on macOS with this from lldb:
>
> Process 13623 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
> frame #0: 0x00007fff332cc43e libcurl.4.dylib`Curl_hash_next_element + 109
> libcurl.4.dylib`Curl_hash_next_element:
> -> 0x7fff332cc43e <+109>: movq (%rdx), %rax
> 0x7fff332cc441 <+112>: popq %rbp
> 0x7fff332cc442 <+113>: retq
> 0x7fff332cc443 <+114>: nop
> Target 0: (runner) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
> * frame #0: 0x00007fff332cc43e libcurl.4.dylib`Curl_hash_next_element + 109
> frame #1: 0x00007fff332e70cd
> libcurl.4.dylib`conncache_find_first_connection + 31
> frame #2: 0x00007fff332e7004
> libcurl.4.dylib`Curl_conncache_close_all_connections + 21
> frame #3: 0x00007fff332cf135 libcurl.4.dylib`curl_multi_cleanup + 195
> frame #4: 0x00007fff332b61ee libcurl.4.dylib`Curl_close + 64
> frame #5: 0x00007fff332c5be6 libcurl.4.dylib`curl_easy_cleanup + 39
> frame #6: 0x000000010000825a
> runner`curl_get_url(url="http://localhost:8082/health-check") at
> test_http_api.c:94:2
> frame #7: 0x00000001000080a0
> runner`test_http_api_get(state=0x0000000100b20710) at
> test_http_api.c:117:2
> frame #8: 0x000000010013aa88
> libcmocka.0.dylib`cmocka_run_one_test_or_fixture + 381
> frame #9: 0x0000000100138eb8 libcmocka.0.dylib`_cmocka_run_group_tests + 976
> frame #10: 0x0000000100008deb runner`main at runner.c:64:9
> frame #11: 0x00007fff207aff3d libdyld.dylib`start + 1
> frame #12: 0x00007fff207aff3d libdyld.dylib`start + 1
>
>
> then I get:
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
> frame #0: 0x00007fff2076592e libsystem_kernel.dylib`__pthread_kill + 10
> libsystem_kernel.dylib`__pthread_kill:
> -> 0x7fff2076592e <+10>: jae 0x7fff20765938 ; <+20>
> 0x7fff20765930 <+12>: movq %rax, %rdi
> 0x7fff20765933 <+15>: jmp 0x7fff2075fad9 ; cerror_nocancel
> 0x7fff20765938 <+20>: retq
> Target 0: (runner) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
> * frame #0: 0x00007fff2076592e libsystem_kernel.dylib`__pthread_kill + 10
> frame #1: 0x00007fff207945bd libsystem_pthread.dylib`pthread_kill + 263
> frame #2: 0x00007fff206e9406 libsystem_c.dylib`abort + 125
> frame #3: 0x00007fff205c9165 libsystem_malloc.dylib`malloc_vreport + 548
> frame #4: 0x00007fff205dd7e9 libsystem_malloc.dylib`malloc_zone_error + 183
> frame #5: 0x00007fff205c12e1
> libsystem_malloc.dylib`tiny_free_list_remove_ptr + 690
> frame #6: 0x00007fff205c0601 libsystem_malloc.dylib`tiny_free_no_lock + 1014
> frame #7: 0x00007fff205c00c9 libsystem_malloc.dylib`free_tiny + 442
> frame #8: 0x00007fff332b6a9e libcurl.4.dylib`conn_free + 297
> frame #9: 0x00007fff332b6968 libcurl.4.dylib`Curl_disconnect + 302
> frame #10: 0x00007fff332e703a
> libcurl.4.dylib`Curl_conncache_close_all_connections + 75
> frame #11: 0x00007fff332cf135 libcurl.4.dylib`curl_multi_cleanup + 195
> frame #12: 0x00007fff332b61ee libcurl.4.dylib`Curl_close + 64
> frame #13: 0x00007fff332c5be6 libcurl.4.dylib`curl_easy_cleanup + 39
> frame #14: 0x000000010000825a
> runner`curl_get_url(url="http://127.0.0.1:8082/blah") at
> test_http_api.c:94:2
> frame #15: 0x00000001000080c5
> runner`test_http_api_get(state=0x0000000100b20710) at
> test_http_api.c:121:2
> frame #16: 0x000000010013aa88
> libcmocka.0.dylib`cmocka_run_one_test_or_fixture + 381
> frame #17: 0x0000000100138eb8
> libcmocka.0.dylib`_cmocka_run_group_tests + 976
> frame #18: 0x0000000100008deb runner`main at runner.c:64:9
> frame #19: 0x00007fff207aff3d libdyld.dylib`start + 1
> frame #20: 0x00007fff207aff3d libdyld.dylib`start + 1
>
> then all good:
>
> [ OK ] test_route_regex_check
> [ RUN ] test_sip_message
> [ OK ] test_sip_message
> [==========] 14 test(s) run.
> [ PASSED ] 14 test(s).
> Process 15176 exited with status = 0 (0x00000000)
>
> Am I cleaning up correctly?
>
> https://github.com/SentryPeer/SentryPeer/blob/main/tests/unit_tests/test_http_api.c#L94


I can't find anything wrong with your curl_get_url function except that
it returns more than one type (CURLcode, stdlib exit code or http
response code) and that is bad practice. If you're using libcurl from
multiple threads please review libcurl thread safety guidelines [1]. If
not can you give us a minimal self contained example that can be used to
reproduce?

[1]: https://curl.se/libcurl/c/threadsafe.html

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2022-01-18