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

go to bug id or search bugs for

Bug #50035 Crash during shutdown, zm_shutdown_ps_mm -> ps_mm_destroy -> mm_destroy
Submitted: 2009-10-29 14:12 UTC Modified: 2009-11-12 01:00 UTC
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: dhertel at gmail dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 5.3.1RC2 OS: linux 2.6.27
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: dhertel at gmail dot com
New email:
PHP Version: OS:

 

 [2009-10-29 14:12 UTC] dhertel at gmail dot com 
Description:
------------
I'm writing a CLI program with forking and ipc and stuff. It seems to work fine but in the current test the script eventually produces a segfault - every time... but only if i let it run until it's shutting down itself. if i interrupt it, it shuts down without segfaulting

php -i says it's version 5.3.1RC3-dev but i also had this problem with 5.3.0 (which unfortunately i can't downgrade to anymore to make a trace there)

when using valgrind to check memory the segfault doesn't happen

Reproduce code:
---------------
Though I don't believe that it's a problem with my actual code (as there are no execute() lines in the Backtrace), here it is:

http://pastebin.org/49244

the PFW_* classes are for handling processes in general, the MMAE_* classes are part of the actual software using PFW_*, where MMAE_Boot stays but Core and Core2 are only for seing if my PFW_* actually works.

Expected result:
----------------
no segfault

Actual result:
--------------
segfault

so here's the back trace
#0  0xb7441570 in ?? ()
#1  0x080b88d3 in zm_shutdown_ps_mm (type=1, module_number=7) at /usr/src/debug/php-5.3.1_git200910272307/ext/session/mod_mm.c:256
#2  0x080b6fd1 in zm_shutdown_session (type=1, module_number=7) at /usr/src/debug/php-5.3.1_git200910272307/ext/session/session.c:2192
#3  0x081bde7a in module_destructor (module=0x82cd180) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_API.c:2098
#4  0x081c4192 in zend_hash_apply_deleter (ht=0x82bbbc0, p=0x82cd150) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_hash.c:611
#5  0x081c4457 in zend_hash_graceful_reverse_destroy (ht=0x82bbbc0) at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend_hash.c:646
#6  0x081b85ac in zend_shutdown () at /usr/src/debug/php-5.3.1_git200910272307/Zend/zend.c:759
#7  0x0815d732 in php_module_shutdown () at /usr/src/debug/php-5.3.1_git200910272307/main/main.c:2103
#8  0x0824569c in main (argc=2, argv=0xbff47784) at /usr/src/debug/php-5.3.1_git200910272307/sapi/cli/php_cli.c:1385

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-10-29 15:07 UTC] dhertel at gmail dot com 
I'm sorry i couln't provide a shorter script :-(. I can't reproduce the segfault with a simple script.

I now stripped everything unnecessary from the script... doesn't need anything external now...

Strange thing is that the segfault doesn't occur every time the script ends but sometimes... and the more iterations mmae_core2 runs (line 59), the more often it seems to occur

http://pastebin.org/49264
 [2009-10-29 19:36 UTC] sjoerd@php.net 
I could not reproduce the crash with either script.
 [2009-10-29 19:41 UTC] dhertel at gmail dot com 
that somehow doesn't surprise me, as this segfault doesn't seem to come from the script... if i got the backtrace right, php segfaults after the script finished - correct me if i'm wrong :)
 [2009-11-03 10:54 UTC] jani@php.net 
It crashes in mod_mm.c line 256 which is ps_mm_destroy() doing mm_destroy(). See also bug #46434 which is about another MM related crash in session module. I would guess it's either MM which is buggy or we're doing something wrong here. (what libmm version do you have?)

Please try also with PHP 5.2.11 (no need for backtrace, just let us know if it crashes also).
 [2009-11-04 07:37 UTC] dhertel at gmail dot com 
unfortunately i can't as i use methods which have been introduced in php 5.3

my libmm version is 1.4.2 (1.4.2-16.79 from opensuse 11.1)
 [2009-11-04 10:39 UTC] jani@php.net 
What in that example script needs 5.3 and why can't you modify it to work in 5.2? I'm not asking you to do this on a live site, usually developers have development servers to test things with. I can't reproduce this, neither could some other devs so it's up to you do provide us the information. If you can't do that, this report is soon bogus.
 [2009-11-04 12:09 UTC] dhertel at gmail dot com 
it uses msg_queue_exists and pcntl_signal_dispatch

i could replace the first with a function that mimics it's functionality somehow but i couldn't replace the latter without destroying the functionality of the class itself (a process shouldn't halt if there's no signal to fetch and pcntl_sigtimedwait is also php >= 5.3)... but as i already said, i encountered this error in php 5.3.0 as well as in 5.3.1 RC3
 [2009-11-04 12:34 UTC] jani@php.net 
Exactly how do you run the script? What php.ini options do you use? (diff against whatever php.ini-* you used as base is enough)
 [2009-11-12 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Dec 26 21:01:28 2024 UTC