Fwd: core dump on curl function call

From: treesa fairy joseph via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 1 Oct 2021 14:56:06 +0530

I am using curl-7.73.0. The full core dump is as follows

gdb lte_tr069 core
GNU gdb (Cavium Inc. Version 0.99 build 440) 7.8.50.20140823-cvs
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-thunderx-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.cavium.com/support.html>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lte_tr069...done.
[New LWP 3847]
[New LWP 3837]
[New LWP 3838]
[New LWP 3848]

warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `./lte_tr069 ../cfg/eNodeB_Configuration.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000005377c4 in Curl_hash_clean_with_criterium (h=0xffff7c0a4d50,
user=0xffff8b28d970,
    comp=0x4ba604 <hostcache_timestamp_remove>) at hash.c:243
243 hash.c: No such file or directory.
(gdb) bt
#0 0x00000000005377c4 in Curl_hash_clean_with_criterium (h=0xffff7c0a4d50,
user=0xffff8b28d970,
    comp=0x4ba604 <hostcache_timestamp_remove>) at hash.c:243
#1 0x00000000004ba6ac in hostcache_prune (hostcache=0xffff7c0a4d50,
cache_timeout=60, now=1633097634) at hostip.c:216
#2 0x00000000004ba734 in Curl_hostcache_prune (data=0xffff7c0161a8) at
hostip.c:240
#3 0x00000000004d42ac in multi_done (data=0xffff7c0161a8, status=CURLE_OK,
premature=false) at multi.c:622
#4 0x00000000004d7810 in multi_runsingle (multi=0xffff7c017cd8,
nowp=0xffff8b28dca8, data=0xffff7c0161a8) at multi.c:2420
#5 0x00000000004d7bd8 in curl_multi_perform (multi=0xffff7c017cd8,
running_handles=0xffff8b28dcf4) at multi.c:2559
#6 0x00000000004af2fc in easy_transfer (multi=0xffff7c017cd8) at easy.c:592
#7 0x00000000004af510 in easy_perform (data=0xffff7c0161a8, events=false)
at easy.c:682
#8 0x00000000004af558 in curl_easy_perform (data=0xffff7c0161a8) at
easy.c:701
#9 0x0000000000420814 in ipr_cwmp_send_http_msg (
    msg=0xffff7c02f1e0 "<?xml version=\"1.0\"
encoding=\"UTF-8\"?>\n<SOAP-ENV:Envelope xmlns:SOAP-ENV=\"
http://schemas.xmlsoap.org/soap/envelope/\" xmlns:SOAP-ENC=\"
http://schemas.xmlsoap.org/soap/encoding/\" xmlns:xsi=\"http://www.w3"...,
    URL=0xffff8b28e6b8 "https://192.168.66.106:8443/acs/AcsServlet",
response_message=0xffff8b28e580,
    username=0xac37e2 <g_ipr_cwmp_S_Device_Man_Ser+258>
"BaseStationClass-002488-1114B00025",
    password=0xac38e3 <g_ipr_cwmp_S_Device_Man_Ser+515> "abcd1234") at
http.c:597
#10 0x000000000043857c in ipr_cwmp_Inform (informReq=0x2e187da8,
    URL=0xffff8b28e6b8 "https://192.168.66.106:8443/acs/AcsServlet",
status=0xffff8b28e7e4, in_header=0xffff8b28e7d0,
    username=0xac37e2 <g_ipr_cwmp_S_Device_Man_Ser+258>
"BaseStationClass-002488-1114B00025",
    password=0xac38e3 <g_ipr_cwmp_S_Device_Man_Ser+515> "abcd1234",
session_id=0xffff8b28e6a0) at session_manager.c:1793
#11 0x0000000000436fd0 in ipr_cwmp_SessionInit (devidstruct=0xffff7c0008e0,
    url=0xac36e1 <g_ipr_cwmp_S_Device_Man_Ser+1> "
https://192.168.66.106:8443/acs/AcsServlet", paramList=0x0,
    username=0xac37e2 <g_ipr_cwmp_S_Device_Man_Ser+258>
"BaseStationClass-002488-1114B00025",
    password=0xac38e3 <g_ipr_cwmp_S_Device_Man_Ser+515> "abcd1234") at
session_manager.c:734
#12 0x000000000041f2d8 in ipr_cwmp_startSession (arg=0x2e187e90) at
event_handler.c:225
#13 0x00000000008b66c8 in start_thread (arg=0x0) at pthread_create.c:335
#14 0x00000000008fe948 in thread_start () at
../sysdeps/unix/sysv/linux/aarch64/clone.S:94
(gdb)


Thanks in advance,
Treesa

---------- Forwarded message ---------
From: treesa fairy joseph <treesafj_at_gmail.com>
Date: Fri, Oct 1, 2021 at 10:36 AM
Subject: Re: core dump on curl function call
To: Daniel Stenberg <daniel_at_haxx.se>
Cc: treesa fairy joseph via curl-library <curl-library_at_lists.haxx.se>


Thanks, I will do that.

On Thu, Sep 30, 2021 at 5:46 PM Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Thu, 30 Sep 2021, treesa fairy joseph via curl-library wrote:
>
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0 0x00000000004c3008 in singlesocket ()
> > (gdb) bt
> > #0 0x00000000004c3008 in singlesocket ()
> > #1 0x00000000004c6ac8 in curl_multi_remove_handle ()
> > Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
>
> I suggest you rebuild curl with debug symbols present so that the stack
> trace
> becomes useable. Then you can investigate exactly what happned there in
> frame
> 0 and possibly why. Or at least tell us more details and we might be able
> to
> help.
>
> I presume this is a recent libcurl? I'm not aware of any known flaw in
> that
> function in recent time.
>
> --
>
> / daniel.haxx.se
> | Commercial curl support up to 24x7 is available!
> | Private help, bug fixes, support, ports, new features
> | https://curl.se/support.html
>

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Received on 2021-10-01