Ubuntu
php-svn package

php5-svn seg fault when repos_url is https

Bug #1583925 reported by Anders Sandblad
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
php-svn (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Tested on Ubuntu 14.04 with php5-svn (1.0.2-2).
When doing a query to a remote repos with svn_ls or svn_cat (those are the only functions I've tested) over https the script seg faults at the end of executing the script, not during.

Test script:

<?php
  svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_USERNAME, "user");
  svn_auth_set_parameter(SVN_AUTH_PARAM_DEFAULT_PASSWORD, "pass");

//print_r(svn_ls("https://svn.host.se/svn/repos/trunk/"));
//print_r(svn_ls("https://svn.host.se/svn/repos/"));
$contents = svn_cat("https://svn.host.se/svn/repos/trunk/sw/2061.MSW/applications/il.c");
?>

All of those make the script output
Segmentation fault (core dumped)
at the end of executing the script.
Running with http instead of https works fine.

Revision history for this message
Anders Sandblad (arune) wrote :

Oh! This only happens when php5-curl is installed!!

Revision history for this message
Anders Sandblad (arune) wrote :

Tried reproduce this in a container:

lxc launch ubuntu:14.04 testphp
lxc exec testphp -- bash

apt install php5-cli php5-svn

create test.php according above script

php test.php gives no output

then install php5-curl:

apt install php5-curl

and then run the script again and see it fail with segmentation fault.

Revision history for this message
Anders Sandblad (arune) wrote :
Download full text (3.3 KiB)

root@testphp:~# valgrind php test.php
==3716== Memcheck, a memory error detector
==3716== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==3716== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==3716== Command: php test.php
==3716==

==3716== Warning: invalid file descriptor -1 in syscall close()
==3716== Jump to the invalid address stated on the next line
==3716== at 0xEE7CDB0: ???
==3716== by 0x53437AE: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341B75: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x535125F: sk_pop_free (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341EFB: ENGINE_cleanup (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x7BB64CD: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7BB6E68: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7B926B4: curl_global_cleanup (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7959C97: zm_shutdown_curl (in /usr/lib/php5/20121212/curl.so)
==3716== by 0x6F4692: module_destructor (in /usr/bin/php5)
==3716== by 0x6F9904: ??? (in /usr/bin/php5)
==3716== by 0x6FB107: zend_hash_graceful_reverse_destroy (in /usr/bin/php5)
==3716== Address 0xee7cdb0 is not stack'd, malloc'd or (recently) free'd
==3716==
==3716==
==3716== Process terminating with default action of signal 11 (SIGSEGV)
==3716== Access not within mapped region at address 0xEE7CDB0
==3716== at 0xEE7CDB0: ???
==3716== by 0x53437AE: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341B75: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x535125F: sk_pop_free (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x5341EFB: ENGINE_cleanup (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==3716== by 0x7BB64CD: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7BB6E68: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7B926B4: curl_global_cleanup (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0)
==3716== by 0x7959C97: zm_shutdown_curl (in /usr/lib/php5/20121212/curl.so)
==3716== by 0x6F4692: module_destructor (in /usr/bin/php5)
==3716== by 0x6F9904: ??? (in /usr/bin/php5)
==3716== by 0x6FB107: zend_hash_graceful_reverse_destroy (in /usr/bin/php5)
==3716== If you believe this happened as a result of a stack
==3716== overflow in your program's main thread (unlikely but
==3716== possible), you can try to increase the size of the
==3716== main thread stack using the --main-stacksize= flag.
==3716== The main thread stack size used in this run was 8388608.
==3716==
==3716== HEAP SUMMARY:
==3716== in use at exit: 3,561,791 bytes in 18,770 blocks
==3716== total heap usage: 26,502 allocs, 7,732 frees, 5,611,800 bytes allocated
==3716==
==3716== LEAK SUMMARY:
==3716== definitely lost: 0 bytes in 0 blocks
==3716== indirectly lost: 0 bytes in 0 blocks
==3716== possibly lost: 0 bytes in 0 blocks
==3716== still reachable: 3,561,791 bytes in 18,770 blocks
==3716== suppressed: 0 bytes in 0 blocks
==3716== Rerun with --leak-check=full to see det...

Read more...

Revision history for this message
Anders Sandblad (arune) wrote :

Backtrace from gdb:

#0 0x00007fffedf9bdb0 in ?? ()
#1 0x00007ffff76a27af in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#2 0x00007ffff76a0b76 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#3 0x00007ffff76b0260 in sk_pop_free () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#4 0x00007ffff76a0efc in ENGINE_cleanup () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#5 0x00007ffff52904ce in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#6 0x00007ffff5290e69 in ?? () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#7 0x00007ffff526c6b5 in curl_global_cleanup () from /usr/lib/x86_64-linux-gnu/libcurl.so.4
#8 0x00007ffff54b0c98 in zm_shutdown_curl () from /usr/lib/php5/20121212/curl.so
#9 0x00000000006f4693 in module_destructor ()
#10 0x00000000006f9905 in ?? ()
#11 0x00000000006fb108 in zend_hash_graceful_reverse_destroy ()
#12 0x00000000006ed17e in zend_shutdown ()
#13 0x000000000068f4bb in php_module_shutdown ()
#14 0x0000000000461c36 in main ()

Revision history for this message
Anders Sandblad (arune) wrote :

Fun, if one disable curl extension in php (by running php5dismod curl) and instead loading curl as argument to php like this:

php -dextension=/usr/lib/php5/20121212/curl.so test.php

Does not make it segfault but still works as expected.

Revision history for this message
Steven MAYORGAS (msteven) wrote :

Hi,

Same problem for me !
uname -a :
Linux ### 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Do you have any news about it ?

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

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

Changed in php-svn (Ubuntu):
status: New → Confirmed
Revision history for this message
Anders Sandblad (arune) wrote :

No news, but there's no php-svn in php7 so I've rewritten most of my systems to not use php-svn.

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

Other bug subscribers

Remote bug watches

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