Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Volt engine template extension segfault #1031

Closed
wertyzp opened this issue Aug 8, 2013 · 17 comments
Closed

Volt engine template extension segfault #1031

wertyzp opened this issue Aug 8, 2013 · 17 comments

Comments

@wertyzp
Copy link

wertyzp commented Aug 8, 2013

When extending parent template, if you do not override one of the parent blocks - you get segmentation fault.
Debian 7 x64

@phalcon
Copy link
Collaborator

phalcon commented Aug 9, 2013

Can you please post a test for this issue?

@wertyzp
Copy link
Author

wertyzp commented Aug 12, 2013

make parent template like

parent.volt
{% block main %}aaa{% endblock %}
{% block footer %}bbb{% endblock %}

then extend it with something like
child.volt
{% extends "parent.volt" %}

{% block footer%}abc{%endblock%}

Notice that main block extension is absent. This causes segfaults 95% of time page accessed. 5% somehow works.
Debian 7 x64

@wertyzp
Copy link
Author

wertyzp commented Aug 12, 2013

Here's volt initialization call

$di->set('view', function() {
$view = new \Phalcon\Mvc\View();
$view->setViewsDir('../app/views/');
$view->registerEngines(array(
".volt" => function($view, $di) {
$volt = new \Phalcon\Mvc\View\Engine\Volt($view, $di);
$volt->setOptions(array(
"compiledPath" => "../app/compiled-templates/",
"compiledExtension" => ".compiled",
"compileAlways" => true
));
$volt->tag->setDoctype(\Phalcon\Tag::HTML5);
return $volt;
}
));
$view->title = "Sky";
return $view;
});

@wertyzp
Copy link
Author

wertyzp commented Aug 12, 2013

For some reason, nearly the same document structure on windows platform aborts page transfer at the end.
This means the page is loaded fully, tag met, but then connection is dropped and chrome shows page, but says in console "page load aborted". Firefox shows page, but then network error message is displayed.

@wertyzp
Copy link
Author

wertyzp commented Aug 12, 2013

Further testing shows that trouble in {% extends %} logic. If extends block removed - everything works fine

@ghost
Copy link

ghost commented Aug 12, 2013

What version of Phalcon do you use?

Did you build Phalcon yourself or used fortrabit repo?

I see only two memory leaks (which I am going to address) but cannot reproduce the crash.

@ghost
Copy link

ghost commented Aug 12, 2013

==8585== 32 bytes in 1 blocks are definitely lost in loss record 109 of 238
==8585==    at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8585==    by 0xAAF4BA: _emalloc (zend_alloc.c:2427)
==8585==    by 0x112BF744: phalcon_memory_alloc (memory.c:333)
==8585==    by 0x113D36FD: zim_Phalcon_Mvc_View_Engine_Volt_Compiler_compile (compiler.c:3596)
==8585==    by 0x112C2D15: phalcon_alt_call_method (fcall.c:824)
==8585==    by 0x112C33C9: phalcon_alt_call_user_method (fcall.c:947)
==8585==    by 0x112A0540: phalcon_call_method_vparams (fcall.c:218)
==8585==    by 0x112A0C58: phalcon_call_method_params (fcall.c:344)
==8585==    by 0x113D618F: zim_Phalcon_Mvc_View_Engine_Volt_render (volt.c:179)
==8585==    by 0x112C2D15: phalcon_alt_call_method (fcall.c:824)
==8585==    by 0x112C33C9: phalcon_alt_call_user_method (fcall.c:947)
==8585==    by 0x112A0540: phalcon_call_method_vparams (fcall.c:218)
==8585== 
==8585== 32 bytes in 1 blocks are definitely lost in loss record 110 of 238
==8585==    at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8585==    by 0xAAF4BA: _emalloc (zend_alloc.c:2427)
==8585==    by 0x112BF744: phalcon_memory_alloc (memory.c:333)
==8585==    by 0x113D36FD: zim_Phalcon_Mvc_View_Engine_Volt_Compiler_compile (compiler.c:3596)
==8585==    by 0x112C2D15: phalcon_alt_call_method (fcall.c:824)
==8585==    by 0x112C33C9: phalcon_alt_call_user_method (fcall.c:947)
==8585==    by 0x112A0540: phalcon_call_method_vparams (fcall.c:218)
==8585==    by 0x112A0C58: phalcon_call_method_params (fcall.c:344)
==8585==    by 0x113D03A5: zim_Phalcon_Mvc_View_Engine_Volt_Compiler__statementList (compiler.c:3141)
==8585==    by 0x112C2D15: phalcon_alt_call_method (fcall.c:824)
==8585==    by 0x112C33C9: phalcon_alt_call_user_method (fcall.c:947)
==8585==    by 0x112A0540: phalcon_call_method_vparams (fcall.c:218)
==8585== 

@ghost
Copy link

ghost commented Aug 12, 2013

Here is my code:

test.php:

<?php

$di = new \Phalcon\DI\FactoryDefault();
$di->set('view', function() {
        $view = new \Phalcon\Mvc\View();
        $view->setViewsDir(__DIR__ . '/');
        $view->registerEngines(array(
                ".volt" => function($view, $di) {
                        $volt = new \Phalcon\Mvc\View\Engine\Volt($view, $di);
                        $volt->setOptions(array(
                                "compiledPath" => __DIR__ . '/',
                                "compiledExtension" => ".compiled",
                                "compileAlways" => true
                        ));
                        $volt->tag->setDoctype(\Phalcon\Tag::HTML5);
                        return $volt;
                }
        ));

        $view->title = "Sky";
        return $view;
});

$view = $di->getShared('view');
$view->start();
$view->render('', 'child');
$view->finish();
echo $view->getContent();

parent.volt:

{% block main %}aaa{% endblock %}
{% block footer %}bbb{% endblock %}

child.volt:

{% extends "parent.volt" %}

{% block footer%}abc{%endblock%}

Could you please verify whether this code crashes?

@wertyzp
Copy link
Author

wertyzp commented Aug 12, 2013

Thank you for fast response. We will retest bug with various environment to localize it more precisely within 2 days.

@wertyzp
Copy link
Author

wertyzp commented Aug 14, 2013

I really don't understand this bug logic, but it works only on this environment:

Project structure (important):

app/
    view/
        index/
            index.volt
            parent.volt
public/
    test.php

app/view/index.volt code

{% extends "index/parent.volt" %}

{# % block head %}{% endblock % #}

{% block title %}Error 404{% endblock %}

{% block content %}
    <h1>Error 404</h1>
    <p>Page you're looking not found</p>
{% endblock %}

app/view/parent.volt code

{{get_doctype()}}
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
            {{ stylesheet_link("css/global.css") }}
            {% block head %}{% endblock %}
            <title>{% block title %}Main{% endblock %}</title>
    </head>
    <body>
        {% block content %}{% endblock %}
    </body>
</html>

public/test.php code:

$di = new \Phalcon\DI\FactoryDefault();
$di->set('view', function() {
        $view = new \Phalcon\Mvc\View();
        $view->setViewsDir(__DIR__ . '/../app/views/');
        $view->registerEngines(array(
                ".volt" => function($view, $di) {
                        $volt = new \Phalcon\Mvc\View\Engine\Volt($view, $di);
                        $volt->setOptions(array(
                                "compiledPath" => __DIR__ . '/../app/compiled-templates/',
                                "compiledExtension" => ".compiled",
                                "compileAlways" => true
                        ));
                        $volt->tag->setDoctype(\Phalcon\Tag::HTML5);
                        return $volt;
                }
        ));

        $view->title = "Sky";
        return $view;
});

$view = $di->getShared('view');
$view->start();
$view->render('', 'index/index');
$view->finish();
echo $view->getContent();

First I noticed this bug when added index.volt head block comments

Changing something like removing css link from index.volt, changing template position in filesystem, changing volt options like compileSeparator or compileAlways - everything removes this bug. Only this environment gives it.

I cloned project from github like it described in documentation and executed build/install script

My system is Debian 7 x64

@ghost
Copy link

ghost commented Aug 14, 2013

Could you please build phalcon in debug mode:

cd ext
phpize && ./configure CFLAGS="-g3 -O0" && make -j4
sudo make install

and try to run it under valgrind:

valgrind --read-var-info=yes --fullpath-after= --track-origins=yes /usr/bin/php /path/to/index.php

and paste the output somewhere here.

@wertyzp
Copy link
Author

wertyzp commented Aug 14, 2013

Command: valgrind --read-var-info=yes --fullpath-after= --track-origins=yes /usr/bin/php test.php

==5982== Memcheck, a memory error detector
==5982== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==5982== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==5982== Command: /usr/bin/php test.php
==5982== 
<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
            <link rel="stylesheet" href="/css/global.css" type="text/css">

            <title>Error 404</title>
    </head>
    <body>

    <h1>Error 404</h1>
    <p>Page you're looking not found</p>

    </body>
</html>==5982== Invalid read of size 1
==5982==    at 0x6BDE89: gc_zval_possible_root (in /usr/bin/php5)
==5982==    by 0x6ACA57: zend_hash_destroy (in /usr/bin/php5)
==5982==    by 0x69DC96: _zval_dtor_func (in /usr/bin/php5)
==5982==    by 0x68FCF9: _zval_ptr_dtor (in /usr/bin/php5)
==5982==    by 0x6BFBE6: zend_object_std_dtor (in /usr/bin/php5)
==5982==    by 0x6BFC18: zend_objects_free_object_storage (in /usr/bin/php5)
==5982==    by 0x6C5932: zend_objects_store_del_ref_by_handle_ex (in /usr/bin/php5)
==5982==    by 0x6C5952: zend_objects_store_del_ref (in /usr/bin/php5)
==5982==    by 0x68FCF9: _zval_ptr_dtor (in /usr/bin/php5)
==5982==    by 0x6ACA57: zend_hash_destroy (in /usr/bin/php5)
==5982==    by 0x6BFB8B: zend_object_std_dtor (in /usr/bin/php5)
==5982==    by 0x6BFC18: zend_objects_free_object_storage (in /usr/bin/php5)
==5982==  Address 0x21da04559 is not stack'd, malloc'd or (recently) free'd
==5982== 
==5982== 
==5982== Process terminating with default action of signal 11 (SIGSEGV)
==5982==  Access not within mapped region at address 0x21DA04559
==5982==    at 0x6BDE89: gc_zval_possible_root (in /usr/bin/php5)
==5982==    by 0x6ACA57: zend_hash_destroy (in /usr/bin/php5)
==5982==    by 0x69DC96: _zval_dtor_func (in /usr/bin/php5)
==5982==    by 0x68FCF9: _zval_ptr_dtor (in /usr/bin/php5)
==5982==    by 0x6BFBE6: zend_object_std_dtor (in /usr/bin/php5)
==5982==    by 0x6BFC18: zend_objects_free_object_storage (in /usr/bin/php5)
==5982==    by 0x6C5932: zend_objects_store_del_ref_by_handle_ex (in /usr/bin/php5)
==5982==    by 0x6C5952: zend_objects_store_del_ref (in /usr/bin/php5)
==5982==    by 0x68FCF9: _zval_ptr_dtor (in /usr/bin/php5)
==5982==    by 0x6ACA57: zend_hash_destroy (in /usr/bin/php5)
==5982==    by 0x6BFB8B: zend_object_std_dtor (in /usr/bin/php5)
==5982==    by 0x6BFC18: zend_objects_free_object_storage (in /usr/bin/php5)
==5982==  If you believe this happened as a result of a stack
==5982==  overflow in your program's main thread (unlikely but
==5982==  possible), you can try to increase the size of the
==5982==  main thread stack using the --main-stacksize= flag.
==5982==  The main thread stack size used in this run was 8388608.
==5982== 
==5982== HEAP SUMMARY:
==5982==     in use at exit: 6,189,199 bytes in 36,413 blocks
==5982==   total heap usage: 39,957 allocs, 3,544 frees, 6,565,031 bytes allocated
==5982== 
==5982== LEAK SUMMARY:
==5982==    definitely lost: 0 bytes in 0 blocks
==5982==    indirectly lost: 0 bytes in 0 blocks
==5982==      possibly lost: 0 bytes in 0 blocks
==5982==    still reachable: 6,189,199 bytes in 36,413 blocks
==5982==         suppressed: 0 bytes in 0 blocks
==5982== Rerun with --leak-check=full to see details of leaked memory
==5982== 
==5982== For counts of detected and suppressed errors, rerun with: -v
==5982== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 131 from 10)
Segmentation fault

@wertyzp
Copy link
Author

wertyzp commented Aug 15, 2013

Please, let me know if there any steps forward for this issue, as it very important for our current project.

@wertyzp
Copy link
Author

wertyzp commented Aug 15, 2013

I've recompiled recent phalcon 1.2.3 version for recent php 5.5.1 version. Bug is present.

@wertyzp
Copy link
Author

wertyzp commented Aug 15, 2013

Now I have debug information for php binary:

==16016== Memcheck, a memory error detector
==16016== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==16016== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==16016== Command: /usr/local/bin/php test.php
==16016==

<title>Error 404</title>
<h1>Error 404</h1>
<p>Page you're looking not found</p>
</body>
==16016== Invalid read of size 1 ==16016== at 0x6B7EA9: gc_zval_possible_root (/root/src/php-5.5.1/Zend/zend_gc.c:143) ==16016== by 0x6A67B7: zend_hash_destroy (/root/src/php-5.5.1/Zend/zend_hash.c:560) ==16016== by 0x6977AA: _zval_dtor_func (/root/src/php-5.5.1/Zend/zend_variables.c:45) ==16016== by 0x688A1F: _zval_ptr_dtor (/root/src/php-5.5.1/Zend/zend_variables.h:35) ==16016== by 0x6BAD36: zend_object_std_dtor (/root/src/php-5.5.1/Zend/zend_objects.c:54) ==16016== by 0x6BAD68: zend_objects_free_object_storage (/root/src/php-5.5.1/Zend/zend_objects.c:137) ==16016== by 0x6C0C25: zend_objects_store_del_ref_by_handle_ex (/root/src/php-5.5.1/Zend/zend_objects_API.c:221) ==16016== by 0x6C0C42: zend_objects_store_del_ref (/root/src/php-5.5.1/Zend/zend_objects_API.c:173) ==16016== by 0x688A1F: _zval_ptr_dtor (/root/src/php-5.5.1/Zend/zend_variables.h:35) ==16016== by 0x6A67B7: zend_hash_destroy (/root/src/php-5.5.1/Zend/zend_hash.c:560) ==16016== by 0x6BACDB: zend_object_std_dtor (/root/src/php-5.5.1/Zend/zend_objects.c:44) ==16016== by 0x6BAD68: zend_objects_free_object_storage (/root/src/php-5.5.1/Zend/zend_objects.c:137) ==16016== Address 0x19b57b819 is not stack'd, malloc'd or (recently) free'd ==16016== ==16016== ==16016== Process terminating with default action of signal 11 (SIGSEGV) ==16016== Access not within mapped region at address 0x19B57B819 ==16016== at 0x6B7EA9: gc_zval_possible_root (/root/src/php-5.5.1/Zend/zend_gc.c:143) ==16016== by 0x6A67B7: zend_hash_destroy (/root/src/php-5.5.1/Zend/zend_hash.c:560) ==16016== by 0x6977AA: _zval_dtor_func (/root/src/php-5.5.1/Zend/zend_variables.c:45) ==16016== by 0x688A1F: _zval_ptr_dtor (/root/src/php-5.5.1/Zend/zend_variables.h:35) ==16016== by 0x6BAD36: zend_object_std_dtor (/root/src/php-5.5.1/Zend/zend_objects.c:54) ==16016== by 0x6BAD68: zend_objects_free_object_storage (/root/src/php-5.5.1/Zend/zend_objects.c:137) ==16016== by 0x6C0C25: zend_objects_store_del_ref_by_handle_ex (/root/src/php-5.5.1/Zend/zend_objects_API.c:221) ==16016== by 0x6C0C42: zend_objects_store_del_ref (/root/src/php-5.5.1/Zend/zend_objects_API.c:173) ==16016== by 0x688A1F: _zval_ptr_dtor (/root/src/php-5.5.1/Zend/zend_variables.h:35) ==16016== by 0x6A67B7: zend_hash_destroy (/root/src/php-5.5.1/Zend/zend_hash.c:560) ==16016== by 0x6BACDB: zend_object_std_dtor (/root/src/php-5.5.1/Zend/zend_objects.c:44) ==16016== by 0x6BAD68: zend_objects_free_object_storage (/root/src/php-5.5.1/Zend/zend_objects.c:137) ==16016== If you believe this happened as a result of a stack ==16016== overflow in your program's main thread (unlikely but ==16016== possible), you can try to increase the size of the ==16016== main thread stack using the --main-stacksize= flag. ==16016== The main thread stack size used in this run was 8388608. ==16016== ==16016== HEAP SUMMARY: ==16016== in use at exit: 5,287,052 bytes in 25,455 blocks ==16016== total heap usage: 27,525 allocs, 2,070 frees, 5,475,502 bytes allocated ==16016== ==16016== LEAK SUMMARY: ==16016== definitely lost: 0 bytes in 0 blocks ==16016== indirectly lost: 0 bytes in 0 blocks ==16016== possibly lost: 0 bytes in 0 blocks ==16016== still reachable: 5,287,052 bytes in 25,455 blocks ==16016== suppressed: 0 bytes in 0 blocks ==16016== Rerun with --leak-check=full to see details of leaked memory ==16016== ==16016== For counts of detected and suppressed errors, rerun with: -v ==16016== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6) Segmentation fault

@phalcon
Copy link
Collaborator

phalcon commented Aug 15, 2013

Can you try compiling again from master?

@wertyzp
Copy link
Author

wertyzp commented Aug 16, 2013

Excellent! Test code now works. I very appreciate your work guys. Thanks.

@wertyzp wertyzp closed this as completed Aug 16, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant