php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #45813 Segfault in error handling
Submitted: 2008-08-13 22:18 UTC Modified: 2013-02-18 00:33 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: hnangelo@php.net Assigned:
Status: No Feedback Package: Scripting Engine problem
PHP Version: 5.*, 6 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: hnangelo@php.net
New email:
PHP Version: OS:

 

 [2008-08-13 22:18 UTC] hnangelo@php.net 
Description:
------------
When error reporting is set to E_ALL, calling ob_start() in an error handler function causes a segfault when triggered by imap_open(). 

I don't know if this is an imap only issue, it didn't crash with a couple other functions I tested.

PHP6 snapshot compiled with --with-imap --with-imap-ssl

Reproduce code:
---------------
<?php
/* segfault on HEAD and memleak on 5_3 */
error_reporting(E_ALL);
set_error_handler('segfault');

function segfault() {
    ob_start();
}
 
imap_open($a,$b,$c);
?>


Actual result:
--------------
Segmentation fault

Backtrace:
----------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6bd76d0 (LWP 32715)]
php_output_handler_create_internal (name=0x0, output_handler=0x8279240 <php_output_handler_default_func>, chunk_size=0, flags=112) at /mnt/hd/gsoc/php6/Zend/zend.h:414
414             return ++pz->refcount__gc;
(gdb) bt
#0  php_output_handler_create_internal (name=0x0, output_handler=0x8279240 <php_output_handler_default_func>, chunk_size=0, flags=112) at /mnt/hd/gsoc/php6/Zend/zend.h:414
#1  0x0827a2e8 in php_output_start_user (output_handler=0x0, chunk_size=0, flags=112) at /mnt/hd/gsoc/php6/main/output.c:492
#2  0x0827a379 in zif_ob_start (ht=0, return_value=0x88000e4, return_value_ptr=0x8835638, this_ptr=0x0, return_value_used=0) at /mnt/hd/gsoc/php6/main/output.c:1346
#3  0x082edbb7 in zend_do_fcall_common_helper_SPEC (execute_data=0x88355e8) at /mnt/hd/gsoc/php6/Zend/zend_vm_execute.h:323
#4  0x082ed088 in execute (op_array=0x8833570) at /mnt/hd/gsoc/php6/Zend/zend_vm_execute.h:104
#5  0x082b400d in zend_call_function (fci=0xbf9a6044, fci_cache=0xbf9a5fcc) at /mnt/hd/gsoc/php6/Zend/zend_execute_API.c:933
#6  0x082b4dc8 in call_user_function_ex (function_table=0x86ac4c0, object_pp=0x0, function_name=0x87fff80, retval_ptr_ptr=0xbf9a60c0, param_count=5, params=0x88000c8, 
    no_separation=1, symbol_table=0x0) at /mnt/hd/gsoc/php6/Zend/zend_execute_API.c:729
#7  0x082c4d88 in zend_error (type=8, format=0x8604722 "%s") at /mnt/hd/gsoc/php6/Zend/zend.c:1632
#8  0x08268d33 in php_verror (docref=0x0, params=0x83b9100 "", type=8, format=0x85b8978 "%s (errflg=%ld)", args=0xbf9a618c "hH\203\b\002") at /mnt/hd/gsoc/php6/main/main.c:818
#9  0x08269233 in php_error_docref0 (docref=0x0, type=8, format=0x85b8978 "%s (errflg=%ld)") at /mnt/hd/gsoc/php6/main/main.c:839
#10 0x080f8c08 in zm_deactivate_imap (type=1, module_number=20) at /mnt/hd/gsoc/php6/ext/imap/php_imap.c:1117
#11 0x082c5ae2 in module_registry_cleanup (module=0x8708728) at /mnt/hd/gsoc/php6/Zend/zend_API.c:2487
#12 0x082d1936 in zend_hash_apply (ht=0x86abf40, apply_func=0x82c5ac0 <module_registry_cleanup>) at /mnt/hd/gsoc/php6/Zend/zend_hash.c:920
#13 0x082c3318 in zend_deactivate_modules () at /mnt/hd/gsoc/php6/Zend/zend.c:1394
#14 0x08267ba6 in php_request_shutdown (dummy=0x0) at /mnt/hd/gsoc/php6/main/main.c:1600
#15 0x08359aa4 in main (argc=2, argv=0xbf9a6674) at /mnt/hd/gsoc/php6/sapi/cli/php_cli.c:1329

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-08-14 16:21 UTC] felipe@php.net 
It is reproducible also in 5_2. (2 memory leaks)
 [2008-08-14 17:46 UTC] jani@php.net 
Propably just an issue with imap functions since most of the IMAP's warnings/errors happen during request shutdown. Of course any other similarly behaving stuff would cause the same..
 [2008-08-14 17:59 UTC] felipe@php.net 
Using error_reporting(E_ALL ^ E_NOTICE); the crash/memleak doesnt happen.
 [2010-06-08 15:56 UTC] tony2001@php.net
-Status: Open +Status: Feedback
 [2010-06-08 15:56 UTC] tony2001@php.net 
Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/
 [2013-02-18 00:33 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 01:01:30 2024 UTC