Bugs item #2523113, was opened at 2009-01-20 10:31
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2523113&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: crash
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: olivier cloarec (cloarec)
Assigned to: Daniel Stenberg (bagder)
Summary: Segmentation fault with Redhat 5.2

Initial Comment:
- CURL version: 7.19.2 (same problem with version 7.13)

- OS: Redhat 5.2 (with Redhat 4, it was OK)

- Compiled with following commands (cross compiler used):
autoconf;./configure --with-random=/dev/urandom --without-libidn --without-ssl --host=i386-angie-linux-gnu;make

- Used library: libcurl.a

- Problem: Program receives a SIGSEGV signal caused by libcurl.

- Workaround:
In hostip.c, I replaced "#define USE_ALARM_TIMEOUT" with "#undef USE_ALARM_TIMEOUT".
The library doesn't crash anymore but I don't really know the potential consequences of this modification.

You will find here under the backtrace.

Regards,

Olivier.

#13 0x00af19c9 in exit () from /lib/libc.so.6
(gdb)
#14 0x0804e8ed in allsig ()
(gdb)
#15 <signal handler called>
(gdb)
#16 0x00b1ec81 in fwrite () from /lib/libc.so.6
(gdb)
#17 0x081d4e33 in showit (data=0xa10e3f4, type=CURLINFO_TEXT, ptr=0xa10e6d8 "name lookup timed out\n", size=22) at sendf.c:386
386 sendf.c: No such file or directory.
        in sendf.c
(gdb)
#18 0x081d4eab in Curl_debug (data=0xa10e3f4, type=CURLINFO_TEXT, ptr=0xa10e6d8 "name lookup timed out\n", size=22, conn=0x2) at sendf.c:429
429 in sendf.c
(gdb)
#19 0x081d4fb1 in Curl_failf (data=0xa10e3f4, fmt=0x823dd28 "name lookup timed out") at sendf.c:177
177 in sendf.c
(gdb)
#20 0x081d3963 in Curl_resolv (conn=0x1, hostname=0x0, port=-1260873736, entry=0xb4d897fc) at hostip.c:416
416 hostip.c: No such file or directory.
        in hostip.c
(gdb)

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2009-01-21 22:32

Message:
Yes, I would like to see an as small source code as possible that repeats
this problem. I've run libcurl on systems with much older libc and kernel
versions with no problems...

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2009-01-21 19:17

Message:
The TODO item is listed here:
http://curl.haxx.se/docs/todo.html#signal_based_resolver_timeouts
Since you're using an older kernel and glibc, it seems unlikely that this
is the problem since it's worked fine for some time. Since this is custom
code, I highly suspect a problem somewhere there. What does the signal
handler look like, specifically?

----------------------------------------------------------------------

Comment By: olivier cloarec (cloarec)
Date: 2009-01-21 13:10

Message:
Sorry, but I don't understand the meaning of your sentence "I wonder if
this is TODO item 1.4 rearing its ugly head". Can you please decode it for
a poor french people?

Concerning the other questions:
- kernel=2.6.18-92.el5PAE
- glibc version:
> ll /lib/libc.*
lrwxrwxrwx 1 root root 11 Dec 5 10:05 libc.so.6 -> libc-2.5.so
> /lib/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al...

Do you still need the program I use to get this problem (requested by
bagder)?

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2009-01-21 06:34

Message:
What kernel and glibc version does this happen under? I wonder if this is
TODO item 1.4 rearing its ugly head. #undef USE_ALARM_TIMEOUT will cause
timeouts during the DNS resolve phase to not be honoured.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2009-01-20 13:02

Message:
Can you please show us exactly what program you use to get this problem?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2523113&group_id=976
Received on 2009-01-21