Segmentation fault using curl_exec (php5, apache2)

Bug #880756 reported by Laurent POLESE
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
curl (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I reproduced this problem on 2 very different computers.
Running this simple php script makes apache to seg fault :
<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://google.fr');
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT,15);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_TIMEOUT,30);
echo(curl_exec($ch));
curl_close($ch);

Here is the trace I get :
fstat(48, {st_mode=S_IFREG|0664, st_size=418, ...}) = 0
fstat(48, {st_mode=S_IFREG|0664, st_size=418, ...}) = 0
fstat(48, {st_mode=S_IFREG|0664, st_size=418, ...}) = 0
fstat(48, {st_mode=S_IFREG|0664, st_size=418, ...}) = 0
mmap(NULL, 418, PROT_READ, MAP_SHARED, 48, 0) = 0x7fdac3b1f000
munmap(0x7fdac3b1f000, 418) = 0
close(48) = 0
stat("/tmp/cachegrind.out.6982", 0x7fffe57b85d0) = -1 ENOENT (No such file or directory)
open("/tmp/cachegrind.out.6982", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 48
flock(48, LOCK_EX|LOCK_NB) = 0
fstat(48, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fdac3b1f000
write(48, "version: 1\ncreator: xdebug 2.1.2"..., 115) = 115
write(48, "fl=php:internal\nfn=php::curl_ini"..., 34) = 34
write(48, "10 40\n\n", 7) = 7
write(48, "fl=php:internal\nfn=php::curl_set"..., 36) = 36
write(48, "11 5\n\n", 6) = 6
write(48, "fl=php:internal\nfn=php::curl_set"..., 36) = 36
write(48, "12 0\n\n", 6) = 6
write(48, "fl=php:internal\nfn=php::curl_set"..., 36) = 36
write(48, "13 0\n\n", 6) = 6
write(48, "fl=php:internal\nfn=php::curl_set"..., 36) = 36
write(48, "14 0\n\n", 6) = 6
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
chdir("/*****/apache2-gdb-dump/") = 0
rt_sigaction(SIGSEGV, {SIG_DFL, [], SA_RESTORER|SA_INTERRUPT, 0x7fdac917f060}, {SIG_DFL, [], SA_RESTORER|SA_RESETHAND, 0x7fdac917f060}, 8) = 0
kill(6982, SIGSEGV) = 0
rt_sigreturn(0x1b46) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---

Here are binary versions
Ubuntu 11.10
PHP 5.3.6-13ubuntu3.2 with Suhosin-Patch (cli) (built: Oct 13 2011 23:09:42)
Server version: Apache/2.2.20 (Ubuntu)
curl 7.21.6 (x86_64-pc-linux-gnu) libcurl/7.21.6 OpenSSL/1.0.0e zlib/1.2.3.4 libidn/1.22 librtmp/2.3

Regards
Laurent

EDIT : forgot to mention, same script works just fine launched in cli.
---
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
DistroRelease: Ubuntu 11.10
InstallationMedia: Kubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427)
NonfreeKernelModules: fglrx
Package: curl 7.21.6-3ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Tags: oneiric
Uname: Linux 3.0.0-12-generic x86_64
UpgradeStatus: Upgraded to oneiric on 2011-10-15 (16 days ago)
UserGroups: adm admin cdrom dialout lp lpadmin netdev plugdev sambashare www-data

description: updated
Revision history for this message
Haitao Li (lht) wrote :

Not able to reproduce the fault. The script works fine on my Oneiric. I am using php5-suhosin 0.9.32.1-1.

To make the situation simpler, could you reproduce the crash by fetching a page from local server, like http://127.0.0.1?

Revision history for this message
Laurent POLESE (laurent-polese) wrote :

Same fault occurs when fetching http://127.0.0.1

I said I had the bug on 2 computers. Yesterday I was able to fix it on one of them (i386) by reinstalling curl package, but it didn't work on the other one (amd64).

Revision history for this message
Haitao Li (lht) wrote :

I was tested on amd64.

Maybe you should try to submit crash data with apport. Enable it by "sudo service apport start force_start=1" and reproduce the fault. Detailed instruction and explanation please see https://wiki.ubuntu.com/Apport#How_to_enable_apport

Revision history for this message
Haitao Li (lht) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 880756
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Changed in curl (Ubuntu):
status: New → Incomplete
Revision history for this message
Laurent POLESE (laurent-polese) wrote : Dependencies.txt

apport information

tags: added: apport-collected oneiric
description: updated
Revision history for this message
Haitao Li (lht) wrote :

Thanks! Looks like apport-collect didn't uploaded very much useful data. I think a backtrace would be very useful if you could provide.

If you already got a crash file in /var/crash after enabling apport, you could use apport-retrace to get a backtrace. Use command like: apport-retrace -o trace -R /var/crash/the-crash-file.crash.

Please install the libcurl3-dbg package (or other related dbg packages) first to get a readable stack trace.

Please check and remove privacy information from the generated trace file and upload it.

Or if apport-retrace didn't work and you got a coredump generated in the apache2-gdb-dump directory, please use gdb to get the backtrace.

Revision history for this message
Haitao Li (lht) wrote :

Just notice currently there is a bug (#855291) of libcurl3-dbg, which doesn't include debug symbols at all. So the resulting backtrace may just be worthless.

Revision history for this message
Laurent POLESE (laurent-polese) wrote : Re: [Bug 880756] Re: Segmentation fault using curl_exec (php5, apache2)

Hi,

I don't have any file in /var/crash, and don't know how to get some. I
installed dbg version of libcurl3, caused seg fault again but didn't get
any file.
Also, I configured the gdb dump in apache to write in a world-writable
directory, but I don't get the core either.

If you see anything I'm doing wrong, please tell me.

Laurent

On 31/10/2011 14:02, Haitao Li wrote:
> Thanks! Looks like apport-collect didn't uploaded very much useful data.
> I think a backtrace would be very useful if you could provide.
>
> If you already got a crash file in /var/crash after enabling apport, you
> could use apport-retrace to get a backtrace. Use command like: apport-
> retrace -o trace -R /var/crash/the-crash-file.crash.
>
> Please install the libcurl3-dbg package (or other related dbg packages)
> first to get a readable stack trace.
>
> Please check and remove privacy information from the generated trace
> file and upload it.
>
> Or if apport-retrace didn't work and you got a coredump generated in the
> apache2-gdb-dump directory, please use gdb to get the backtrace.
>

Revision history for this message
Haitao Li (lht) wrote :

If apport is enabled (by "sudo service apport start force_start=1") and a program crashes with segfault (signal 11), a crash file should have been written to directory /var/crash.

How to get a backtrace of apache2 is documented at /usr/share/doc/apache2.2-common/README.backtrace

Revision history for this message
Laurent POLESE (laurent-polese) wrote :
Download full text (8.8 KiB)

I'm getting an error when replying with apport-retrace crash file (over
7MB). Trying without it.
Below is my previous mail.

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

Ok, I joined what apport-retrace generates with the crash file.

Also, here's what I get with gdb :

*gdb backtrace :*
GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08
Copyright (C) 2011 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 "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/sbin/apache2...done.
[New LWP 10051]

warning: Can't read pathname for load map: Erreur d'entrée/sortie.
[Thread debugging using libthread_db enabled]
Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal 11, Segmentation fault.
#0 __GI_clock_gettime (clock_id=1, tp=0x7fffe245dbb0) at
../sysdeps/unix/clock_gettime.c:116
116 ../sysdeps/unix/clock_gettime.c: Aucun fichier ou dossier de ce
type.
         in ../sysdeps/unix/clock_gettime.c
(gdb) bt full
#0 __GI_clock_gettime (clock_id=1, tp=0x7fffe245dbb0) at
../sysdeps/unix/clock_gettime.c:116
         sc_ret = <optimized out>
         vdsop = <optimized out>
         retval = -1
#1 0x00007f54e437d7f3 in curlx_tvnow () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
No symbol table info available.
#2 0x00007f54e437ea93 in Curl_pgrsStartNow () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
No symbol table info available.
#3 0x00007f54e439de37 in Curl_pretransfer () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
No symbol table info available.
#4 0x00007f54e439e702 in Curl_do_perform () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
No symbol table info available.
#5 0x00007f54e45d4cb8 in zif_curl_exec (ht=1,
return_value=0x7f54ec965478, return_value_ptr=0x7f54ec993a80,
this_ptr=0x23e, return_value_used=40)
     at /build/buildd/php5-5.3.6/ext/curl/interface.c:2181
         error = CURLE_OK
         zid = 0x7f54ec964f38
         ch = 0x7f54ec964f88
#6 0x00007f54e4e2a083 in xdebug_execute_internal
(current_execute_data=0x7f54e5bd8068, return_value_used=1)
     at /home/*****/Téléchargements/xdebug-2.1.2/xdebug.c:1336
         edata = 0x7f54e5bd8068
         fse = 0x7f54ec98a740
         cur_opcode = 0x7f54e8599dc0
         do_return = 0
         function_nr = 6
#7 0x00007f54e7ed5c14 in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f54e5bd8068) at
/build/buildd/php5-5.3.6/Zend/zend_vm_execute.h:318
         opline = 0x7f54ec964a30
         should_change_scope = 0 '\000'
#8 0x00007f54e7e86ceb in execute (op_array=0x7f54ec963198) at
/build/buildd/php5-5.3.6/Zend/zend_vm_execute.h:107
         ret = 0
         execute_data = 0x7f54e5bd8068
         nested = 0 '\000'
         original_in_execution = 0 '\000'
#9 0x00007f54e4e29d3c in xdebug_execute (op_array=0x7f54ec963198) at
/home/*****/Téléchargements/xdebug-2.1.2/xdebug.c:1274
         dummy = 0x7f54ec963680
         ed...

Read more...

Haitao Li (lht)
Changed in curl (Ubuntu):
status: Incomplete → New
Revision history for this message
Alex Frenkel (sirshurf) wrote :

IS there any news about this bug???? I have it on my production server....

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in curl (Ubuntu):
status: New → Confirmed
Revision history for this message
its me (st-ry) wrote :

Same problem here running

Ubuntu 11.10, Zend-CE-5.6.0, PHP 5.3.9-ZS5.6.0, Apache/2.2.20

Revision history for this message
Ourfriendbernard (ourfriendbernard) wrote :

I have the same issue and have posted about it on the Zend Forums - http://forums.zend.com/viewtopic.php?f=44&t=44113

In my php build command it references '/usr/local/openssl-0.9.8o' which does not exist on my system.

Does anyone have any ideas what I could try to fix this?

Thanks.

Revision history for this message
Samuel Carlier (9-sacuel-6) wrote :

got the same problem. even the test release of PHP 5.4 Zend_CE-5.6.0 doensn't work.
any fixes around?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.