cURL / Mailing Lists / curl-library / Single Mail

curl-library

Purify problems with libCurl

From: John Lee <jhn134910_at_gmail.com>
Date: Thu, 18 Mar 2010 11:35:46 +0000

Hello there,
I'll be straight up-front. I'm not sure if this is a problem with purify,
libCurl or my application driving libCurl. My app code is enclosed. Code
only crashes when instrumented with purify.
Using libCurl-7.12.1; gdb 6.3.0.0-1.143.el4rh; x86 32-bit RHEL4, gcc 3.4.6,
PurifyPlus 7.0.

First off I'm getting a generated SIGILL.

Program received signal SIGILL, Illegal instruction.
[Switching to Thread -1207993536 (LWP 13262)]
0x0089a138 in Curl_hash_init (h=0x81f3fe8, slots=-1073749100,
dtor=0x83b3908) at hash.c:82
82 free(h->table);
(gdb) backtrace
#0 0x0089a138 in Curl_hash_init (h=0x81f3fe8, slots=-1073749100,
dtor=0x83b3908) at hash.c:82
#1 0x0088763c in curl_maprintf (format=Variable "format" is not available.
) at mprintf.c:1084
#2 0x0084d212 in create_hostcache_id (server=Variable "server" is not
available.
) at hostip.c:210
#3 0x0084d8f5 in Curl_resolv (conn=0x83b3908, hostname=0x81c1870
"localhost", port=80,
    entry=0xbfffe49c) at hostip.c:396
#4 0x008754a9 in Curl_connect (data=0x81f3fe8, in_connect=0x81c8584,
asyncp=0xbfffefdb "")
    at url.c:3240
#5 0x0089c153 in curl_multi_perform (multi_handle=0x81d8e10,
running_handles=0xbffff1bc)
    at multi.c:372
#6 0x0011f654 in http_client_send_request () at http_client.c:363
#7 0x0808821b in main_http_test_loop (arg=Could not find the frame base for
"main_http_test_loop".
) at main.c:360
#8 0x08087e4b in main (argc=1, argv=0xbffff3f4) at main.c:310
(gdb)

**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 14292 at Thu Mar 18
10:15:02 2010)
  * Purify 7.0 Linux (32-bit) (C) Copyright IBM Corporation. 1992, 2006 All
Rights Reserved.
  * For contact information type: "purify -help"
  * Options settings: -purify -chain-length=10 -follow-child-processes=yes \
    -log-file=purifyhttptest \

-purify-home=/home/tecnomen/Purify_Install/Puri/releases/purify.i386_linux2.7.0
\
    -gcc3_path=/usr/bin/gcc \

-cache-dir=/home/tecnomen/Purify_Install/Puri/releases/purify.i386_linux2.7.0/cache
\
    -hw_cap=yes
  * License successfully checked out.
  * Command-line: /opt/xpu/bin/HTTP_TEST

**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 14292) ****
COR: Fatal core dump:
  * This is occurring while in thread 14292:
        Curl_hash_init [hash.c:82]
        curl_maprintf [mprintf.c:1084]
        create_hostcache_id [hostip.c:210]
        Curl_resolv [hostip.c:396]
        Curl_connect [url.c:3240]
        curl_multi_perform [multi.c:372]
        http_client_send_request [http_client.c:363]
        main_http_test_loop [main.c:360]
        main [main.c:310]
        __libc_start_main [libc.so.6]
  * Received signal 4 (SIGILL - Illegal instruction)
  * Handler function: SIG_DFL
  * Faulting instruction address = 0x168138
  * Signal mask: (SIGINT | SIGQUIT | SIGILL | SIGTRAP | SIGABRT | \
    SIGBUS | SIGKILL | SIGUSR2 | SIGALRM | SIGTERM | SIGCONT | SIGTTIN | \
    SIGTTOU | SIGURG | SIGXFSZ | SIGPROF | SIGWINCH | SIGPWR | \
    SIGReserved35 | SIGReserved36 | SIGReserved38 | SIGReserved39 | \
    SIGReserved41 | SIGReserved43 | SIGReserved46 | SIGReserved47 | \
    SIGReserved49 | SIGReserved51 | SIGReserved54 | SIGReserved55 | \
    SIGReserved58 | SIGReserved60 | SIGReserved62 | SIGReserved63)
  * Pending signals:

**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 14292) ****
Purify: Searching for all memory leaks...

Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)

Purify Heap Analysis (combining suppressed and unsuppressed blocks)
                         Blocks Bytes
              Leaked 27 3312
  Potentially Leaked 0 0
              In-Use 4577 2377254
  ----------------------------------------
     Total Allocated 4604 2380566

**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 14292) ****
  * Program terminated.
  * 1 access error, 1 total occurrence.
  * 0 bytes leaked.
  * 0 bytes potentially leaked.
  * Basic memory usage (including Purify overhead):
    441984 code
    179760 data/bss
    2940928 heap (peak use)
    12916 stack
  * Shared library memory usage (including Purify overhead):
...

Looking closer at curl_maprintf() :
char *curl_maprintf(const char *format, ...)
{
  va_list ap_save; /* argument pointer */
  int retcode;
  struct asprintf info;

  info.buffer = NULL;
  info.len = 0;
  info.alloc = 0;
  info.fail = FALSE;

  va_start(ap_save, format);
  retcode = dprintf_formatf(&info, alloc_addbyter, format, ap_save);
  va_end(ap_save);
  if((-1 == retcode) || info.fail) {
    if(info.alloc)
==> free(info.buffer);
    return NULL;
  }

One question: Why are we trying to free non-heap memory? I thought this may
be a problem or the "illegal instruction" so I commented out the line and
ran the test again. This time then I get a segmentation fault:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1207993536 (LWP 22511)]
0x6f430064 in ?? ()
(gdb) backtrace
#0 0x6f430064 in ?? ()
#1 0x001e9045 in hash_element_dtor (user=0x1f56ce, element=0xbfffe3b4) at
hash.c:60
#2 0x001d6875 in curl_maprintf (format=Variable "format" is not available.
) at mprintf.c:1084
#3 0x0019c246 in create_hostcache_id (server=Variable "server" is not
available.
) at hostip.c:210
#4 0x0019c929 in Curl_resolv (conn=0x83b06c8, hostname=0x81c1870
"localhost", port=80,
    entry=0xbfffe4bc) at hostip.c:396
#5 0x001c44dd in Curl_connect (data=0x81f3fe8, in_connect=0x81c8584,
asyncp=0xbfffeffb "")
    at url.c:3240
#6 0x001eb33b in curl_multi_perform (multi_handle=0x81d8e10,
running_handles=0xbffff1dc)
    at multi.c:372
#7 0x00200654 in http_client_send_request () at http_client.c:363
#8 0x08088217 in main_http_test_loop (arg=Could not find the frame base for
"main_http_test_loop".
) at main.c:360
#9 0x08087e47 in main (argc=1, argv=0xbffff414) at main.c:310
(gdb)

**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 32080) ****
SOF: Stack overflow error:
  * This is occurring while in thread 32080:
        curl_maprintf [mprintf.c:1084]
        create_hostcache_id [hostip.c:210]
        Curl_resolv [hostip.c:396]
        Curl_connect [url.c:3240]
        curl_multi_perform [multi.c:372]
        http_client_send_request [http_client.c:363]
        main_http_test_loop [main.c:360]
        main [main.c:310]
        __libc_start_main [libc.so.6]
        _start [crt1.o]
  * Stack pointer 0x7ed158, frame size 24672 bytes

**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 32080) ****
SIG: Signal handled:
  * This is occurring while in thread 32080:
        Curl_hash_alloc [hash.c:97]
        curl_maprintf [mprintf.c:1084]
        create_hostcache_id [hostip.c:210]
        Curl_resolv [hostip.c:396]
        Curl_connect [url.c:3240]
        curl_multi_perform [multi.c:372]
        http_client_send_request [http_client.c:363]
        main_http_test_loop [main.c:360]
        main [main.c:310]
        __libc_start_main [libc.so.6]
  * Received signal 11 (SIGSEGV - Segmentation fault)
  * Handler function:
        vShutdownHandler [main.c:543]
  * Faulting address = 0x30303030
  * Signal mask: (SIGSEGV | SIGALRM)
  * Pending signals:

**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 32080) ****
Current file descriptors in use: 9
**** Purify instrumented /opt/xpu/bin/HTTP_TEST (pid 32080) ****
Purify: Searching for all memory leaks...

Memory leaked: 0 bytes (0%); potentially leaked: 0 bytes (0%)

Using printf's I managed to determine that the stack overflow happens
somewhere when calling dprintf_IsQualifierNoDollar(*fmt) in the
dprintf_Pass1() function in mprintf.c? I've heard sometimes that tool chains
can have problems parsing variadic functions with non-standard data types
but I've really no idea what the problem could be here?

I could update to the latest libCurl version but I think the code is the
same in this area? Any suggestions would be much appreciated...
BRs //John.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html

Received on 2010-03-18