Functional testing in modular application is not possible #469

pdeszynski · 2013-03-12T13:02:31Z

Hello,

There's a problem when putting more than one unittest in a row which initialize application and register modules. Even if the Phalcon\Mvc\Application object is recreated test will fail because it does the cache somewhere modules/classes definitions. It's easy to reproduce this using unittest class from cphalcon repository:

https://github.com/phalcon/cphalcon/blob/1.0.0/unit-tests/ApplicationMvcTest.php

I've added method there and just called different test (results will be exaclty the same if copy&paste testApplicationModulesDefinition() into following method's body):

<?php
class ApplicationMvcTest extends PHPUnit_Framework_TestCase
{
    //.....
    public function testApplicationModulesDefinitionSecondApplication()
    {
        $this->testApplicationModulesDefinition();
    }
    //----
}
?>

Running then a phpunit:

phpunit -c unit-tests/phpunit.xml unit-tests/ApplicationMvcTest.php

Will generate a fatal error (Cannot redeclare Frontend\Module..). This makes Phalcon modular application impossible to unittest.

The text was updated successfully, but these errors were encountered:

pdeszynski · 2013-03-12T13:04:57Z

This doesn't happen when modules are defined using closures.

niden · 2013-03-12T14:44:23Z

We are aware of this thanks :) Someone else reported this I don't remember where really.

I am in the process of rewriting the suite to cater for micro, simple and multi module applications as far as functional tests are concerned. The first step was to change every test (of the new suite) to take into account namespaces. There is a bit of work to be done still but I should have something out pretty soon.

pdeszynski · 2013-04-25T14:42:11Z

Was there any progress with this issute?

niden · 2013-04-25T15:44:11Z

@piteer1 Sorry about that. I will be working on this this weekend so hopefully I will have a strategy for you pretty soon.

pdeszynski · 2013-05-29T12:33:10Z

@niden I saw this feature is already in a next milestone. Thanks!

Plaputta · 2013-07-16T12:35:07Z

Hi, any updates on this?

pdeszynski · 2013-07-16T12:41:01Z

@Plaputta As I saw in version 1.2 this still doesn't work. I was able at the end to run such tests without Process Isolation, but it required from me simulationg module loading from PHP (I was loading a Module class using require_once and then calling all initialization methods from the module to init module itself). There's a big drawback thought. You have to delete all informations from Router and all Routes about module (so Phalcon will think that you're always in main module, but load correct classes). For now I didn't find any better solution thought (and this is rather a workaround than a real solution).

pdeszynski · 2013-07-23T08:43:22Z

@niden I saw there's a version 1.2.1, will any fix for test be released with current version?

Best regards

ghost · 2013-07-23T15:48:41Z

@piteer1 I think this has been fixed in #818, could you please check?

pdeszynski · 2013-07-24T06:40:10Z

Hello @sjinks Not sure if this is related to this fix (because I've also upgraded from Phalcon 1.2.0 beta2 to Phalcon 1.2.1) but now I'm getting segfaults. I will try to test this fix on clean app.

#2  0x00000000006a175c in gc_collect_cycles ()
#3  0x00000000006a1912 in gc_zobj_possible_root ()
... xdebug/suhosin
46 0x00007fffee9321be in phalcon_call_user_func_array_noex () from /usr/lib/php5/20090626/phalcon.so
#47 0x00007fffeea5f3d5 in zim_Phalcon_DI_Service_resolve () from /usr/lib/php5/20090626/phalcon.so
#48 0x00007fffee93a7bc in phalcon_alt_call_user_method () from /usr/lib/php5/20090626/phalcon.so
#49 0x00007fffee9405ca in phalcon_call_method_params_w () from /usr/lib/php5/20090626/phalcon.so
#50 0x00007fffeea450e7 in zim_Phalcon_DI_get () from /usr/lib/php5/20090626/phalcon.so
#51 0x00007fffee93a7bc in phalcon_alt_call_user_method () from /usr/lib/php5/20090626/phalcon.so
#52 0x00007fffee9405ca in phalcon_call_method_params_w () from /usr/lib/php5/20090626/phalcon.so
#53 0x00007fffee944646 in T.16858 () from /usr/lib/php5/20090626/phalcon.so
#54 0x00007fffeea44cf6 in zim_Phalcon_DI___call () from /usr/lib/php5/20090626/phalcon.so

pdeszynski · 2013-07-24T08:14:41Z

Ok, so as I've checked using separate unittest and it's working now. I will look more into the segfault issue and open separate one if I'll be able to find what's exactly the cause.

ghost · 2013-07-24T14:26:49Z

You will probably need to rebuild phalcon from scratch because the layout of internal data structures has changed.

pdeszynski · 2013-07-24T14:33:55Z

I found the reason. There's a bug with memory management with phalcon
Config (exactly merge function). I will post an issue later.
24 lip 2013 16:27, "Vladimir Kolesnikov" notifications@github.com
napisa³(a):

You will probably need to rebuild phalcon from scratch because the layout
of internal data structures has changed.

Reply to this email directly or view it on GitHubhttps://github.com//issues/469#issuecomment-21488360
.

ghost · 2013-07-24T14:38:06Z

Please do rebuild Phalcon first.

$ ZEND_MM_ALLOC=0 valgrind $(phpenv which php) unit-tests/manual-unit.php ConfigTest.php ConfigTest
==24886== Memcheck, a memory error detector
==24886== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==24886== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==24886== Command: /home/vladimir/.phpenv/versions/5.3.26/bin/php unit-tests/manual-unit.php ConfigTest.php ConfigTest
==24886== 
Testing ConfigTest [OK] (0) (4104) (280.2010)
==24886== 
==24886== HEAP SUMMARY:
==24886==     in use at exit: 175,329 bytes in 30 blocks
==24886==   total heap usage: 54,559 allocs, 54,529 frees, 7,894,141 bytes allocated
==24886== 
==24886== LEAK SUMMARY:
==24886==    definitely lost: 173,140 bytes in 21 blocks
==24886==    indirectly lost: 0 bytes in 0 blocks
==24886==      possibly lost: 0 bytes in 0 blocks
==24886==    still reachable: 2,189 bytes in 9 blocks
==24886==         suppressed: 0 bytes in 0 blocks
==24886== Rerun with --leak-check=full to see details of leaked memory
==24886== 
==24886== For counts of detected and suppressed errors, rerun with: -v
==24886== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

Memleaks are caused by phar_compile_file and are not related to Phalcon.

pdeszynski · 2013-07-25T06:54:48Z

@sjinks Sorry for delay. Yes all written tests are fine, but probably, because PHP's garbage collection doesn't start. If I run the tests without the one that I've written all tests are working fine and there's no segfault. Here's a gist for a test which will fail:
https://gist.github.com/piteer1/6077409

I've added just one method to a ConfigTest:

public function testConfigWithMergeAndGarbageCollection()
{
    $config = new Phalcon\Config(array('test1' => 1, 'test2' => 2));
    $config->merge(new Phalcon\Config(array('test2')));
    gc_collect_cycles();
}

Here's an output from valgrind

==16612== Memcheck, a memory error detector
==16612== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==16612== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==16612== Command: php unit-tests/manual-unit.php ConfigTest.php ConfigTest
==16612== 
Testing ConfigTest ==16612== Invalid read of size 8
==16612==    at 0x6A3B93: _zend_mm_free_canary_int (in /usr/bin/php5)
==16612==    by 0x682E7C: _zval_dtor_func (in /usr/bin/php5)
==16612==    by 0x676E9C: _zval_ptr_dtor (in /usr/bin/php5)
==16612==    by 0x690317: zend_hash_destroy (in /usr/bin/php5)
==16612==    by 0x6A5168: zend_object_std_dtor (in /usr/bin/php5)
==16612==    by 0xE2EE952: phalcon_config_object_dtor (in /usr/lib/php5/20090626/phalcon.so)
==16612==    by 0x6A8D6B: zend_objects_store_del_ref_by_handle_ex (in /usr/bin/php5)
==16612==    by 0x6A8D92: zend_objects_store_del_ref (in /usr/bin/php5)
==16612==    by 0x676E9C: _zval_ptr_dtor (in /usr/bin/php5)
==16612==    by 0x6AA99D: zend_leave_helper_SPEC (in /usr/bin/php5)
==16612==    by 0x6AB9FF: execute (in /usr/bin/php5)
==16612==    by 0x8A31378: xdebug_execute (xdebug.c:1435)
==16612==  Address 0x58b3e815fb5b73b7 is not stack'd, malloc'd or (recently) free'd
==16612== 
==16612== 
==16612== Process terminating with default action of signal 11 (SIGSEGV)
==16612==  General Protection Fault
==16612==    at 0x6A3B93: _zend_mm_free_canary_int (in /usr/bin/php5)
==16612==    by 0x682E7C: _zval_dtor_func (in /usr/bin/php5)
==16612==    by 0x676E9C: _zval_ptr_dtor (in /usr/bin/php5)
==16612==    by 0x690317: zend_hash_destroy (in /usr/bin/php5)
==16612==    by 0x6A5168: zend_object_std_dtor (in /usr/bin/php5)
==16612==    by 0xE2EE952: phalcon_config_object_dtor (in /usr/lib/php5/20090626/phalcon.so)
==16612==    by 0x6A8D6B: zend_objects_store_del_ref_by_handle_ex (in /usr/bin/php5)
==16612==    by 0x6A8D92: zend_objects_store_del_ref (in /usr/bin/php5)
==16612==    by 0x676E9C: _zval_ptr_dtor (in /usr/bin/php5)
==16612==    by 0x6AA99D: zend_leave_helper_SPEC (in /usr/bin/php5)
==16612==    by 0x6AB9FF: execute (in /usr/bin/php5)
==16612==    by 0x8A31378: xdebug_execute (xdebug.c:1435)
==16612== 
==16612== HEAP SUMMARY:
==16612==     in use at exit: 5,780,168 bytes in 39,939 blocks
==16612==   total heap usage: 43,364 allocs, 3,425 frees, 6,368,036 bytes allocated
==16612== 
==16612== LEAK SUMMARY:
==16612==    definitely lost: 0 bytes in 0 blocks
==16612==    indirectly lost: 0 bytes in 0 blocks
==16612==      possibly lost: 786,432 bytes in 2 blocks
==16612==    still reachable: 4,993,736 bytes in 39,937 blocks
==16612==         suppressed: 0 bytes in 0 blocks
==16612== Rerun with --leak-check=full to see details of leaked memory
==16612== 
==16612== For counts of detected and suppressed errors, rerun with: -v
==16612== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 25 from 10)
Segmentation fault

Please try to run this test in your environment also. I'm using

php --version
PHP 5.3.3-7+squeeze16 with Suhosin-Patch (cli) (built: Jul 17 2013 15:34:13) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans
    with Suhosin v0.9.32.1, Copyright (c) 2007-2010, by SektionEins GmbH

and Phalcon 1.2.1

ghost · 2013-07-25T14:28:22Z

OK, let me try it

ghost · 2013-07-25T20:22:45Z

@piteer1 Could you please test with the latest 1.2.2 branch?

pdeszynski · 2013-07-26T06:09:11Z

@sjinks After first check it looks like it works completely fine now.
Thanks

blog360space · 2016-04-07T18:56:07Z

Hi all, I have same problem in phalcon 2.0.9.

Unitest testing with codeception in modular application is not possible.

My module class:
`

registerNamespaces(array( 'Frontend\Controllers' => __DIR__ . '/controllers/', 'Frontend\Services' => __DIR__ . '/services/' )); $loader->register(); } ``` } ` and I can not load class in services in unitest. Please help me.

sergeyklay · 2016-04-07T21:25:18Z

@hunggau Create please separated issue

blog360space · 2016-04-07T21:51:59Z

Ohhh sorry I posted in a wrong thread,
Please read this, I created a new thread:
#11640

ghost assigned niden May 22, 2013

pdeszynski closed this as completed Jul 24, 2013

ghost mentioned this issue Jul 25, 2013

[BUG] Fix invalid memory reads when GC is on #927

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Functional testing in modular application is not possible #469

Functional testing in modular application is not possible #469

pdeszynski commented Mar 12, 2013

pdeszynski commented Mar 12, 2013

niden commented Mar 12, 2013

pdeszynski commented Apr 25, 2013

niden commented Apr 25, 2013

pdeszynski commented May 29, 2013

Plaputta commented Jul 16, 2013

pdeszynski commented Jul 16, 2013

pdeszynski commented Jul 23, 2013

ghost commented Jul 23, 2013

pdeszynski commented Jul 24, 2013

pdeszynski commented Jul 24, 2013

ghost commented Jul 24, 2013

pdeszynski commented Jul 24, 2013

ghost commented Jul 24, 2013

pdeszynski commented Jul 25, 2013

ghost commented Jul 25, 2013

ghost commented Jul 25, 2013

pdeszynski commented Jul 26, 2013

blog360space commented Apr 7, 2016

sergeyklay commented Apr 7, 2016

blog360space commented Apr 7, 2016

Functional testing in modular application is not possible #469

Functional testing in modular application is not possible #469

Comments

pdeszynski commented Mar 12, 2013

pdeszynski commented Mar 12, 2013

niden commented Mar 12, 2013

pdeszynski commented Apr 25, 2013

niden commented Apr 25, 2013

pdeszynski commented May 29, 2013

Plaputta commented Jul 16, 2013

pdeszynski commented Jul 16, 2013

pdeszynski commented Jul 23, 2013

ghost commented Jul 23, 2013

pdeszynski commented Jul 24, 2013

pdeszynski commented Jul 24, 2013

ghost commented Jul 24, 2013

pdeszynski commented Jul 24, 2013

ghost commented Jul 24, 2013

pdeszynski commented Jul 25, 2013

ghost commented Jul 25, 2013

ghost commented Jul 25, 2013

pdeszynski commented Jul 26, 2013

blog360space commented Apr 7, 2016

sergeyklay commented Apr 7, 2016

blog360space commented Apr 7, 2016