Bugs item #2523113, was opened at 2009-01-20 10:31
Message generated for change (Settings changed) 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: Closed
>Resolution: Works For Me
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: olivier cloarec (cloarec)
Date: 2009-01-30 10:57

Message:
I'm not able to provide a small source code that repeats the problem for
the moment.
My server will be unavailable for a few weeks.
I can't reproduce the problem.
I think you can close the incident and I will submit a new one with a
source code that repeats the problem when I will be ready to provide it.

Thanks for your effort.

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

Comment By: olivier cloarec (cloarec)
Date: 2009-01-27 10:42

Message:
Sorry for delay, but I use this libcurl in a quite important project and
I'm preparing an as small source code as possible that repeats the problem.

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

Comment By: Daniel Stenberg (bagder)
Date: 2009-01-26 16:27

Message:
Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this set to state to pending
and it will automatically get closed later on unless we get further info.

Please consider answering the outstanding questions or providing the
missing info so that we can proceed to resolve this issue!

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

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-02-18