wxSplitterWindow

[davekimble2]

<?php
$frame = new wxFrame(null, wxID_TOP, "Splitter Test" );
    $vbox = new wxBoxSizer(wxVERTICAL);
        $splitter = new wxSplitterWindow($frame);
            $leftpane = new wxWindow($splitter, wxID_ANY);
            $rightpane = new wxWindow($splitter, wxID_ANY);
        $splitter->SplitVertically($leftpane, $rightpane, 200);
    $vbox->Add($splitter, 1, wxEXPAND|wxALL, 5);
$frame->SetSizer($vbox);
$frame->Show();
wxEntry();
?>

produces: Segmentation fault (core dumped)

[davekimble2]

It works OK if you replace "wxWindow" with "wxPanel", and that amounts to the same thing as wxPanel inherits from wxWindow. That gets round my problem, but it's a bit odd, isn't it?

[jgmdev]

will debug this later to see if it is a bug in wxphp

[halfer]

@davekimble2: what version of PHP were you using with this issue? I'd like to add an example file on how to use this, so it would be good to know if there's any instability to watch out for.

[davekimble2]

It is doing it now on Lubuntu 14.04 with: PHP 5.5.9-1ubuntu4.14 wxPHP 3.0.2.0 wxWidgets 3.0.2

[halfer]

Thanks @davekimble2 - I've got a similar config with Ubuntu 14.04, will see what happens here. I guess if there is a workaround then the splitter device is at least usable, but I agree it would be good to polish any rough edges.

[halfer]

@davekimble2 - I get the same also.

Anyone here speak Valgrind? Here's a snippet of output:

--23260-- REDIR: 0x69950c0 (libc.so.6:__GI___strncasecmp_l) redirected to 0x4c2f0b0 (__GI___strncasecmp_l)
--23260-- Reading syms from /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libcanberra-gtk3-module.so
--23260--   Considering /usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libcanberra-gtk3-module.so ..
--23260--   .. CRC mismatch (computed 343caaea wanted 334d8d33)
--23260--    object doesn't have a symbol table
--23260-- Reading syms from /usr/lib/x86_64-linux-gnu/libcanberra-gtk3.so.0.1.9
--23260--   Considering /usr/lib/x86_64-linux-gnu/libcanberra-gtk3.so.0.1.9 ..
--23260--   .. CRC mismatch (computed 0a02c9de wanted 0949ba6e)
--23260--    object doesn't have a symbol table
--23260-- Reading syms from /usr/lib/x86_64-linux-gnu/libcanberra.so.0.2.5
--23260--   Considering /usr/lib/x86_64-linux-gnu/libcanberra.so.0.2.5 ..
--23260--   .. CRC mismatch (computed 6fce074f wanted ce6bac11)
--23260--    object doesn't have a symbol table
--23260-- Reading syms from /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3.3.4
--23260--    object doesn't have a symbol table
--23260-- Reading syms from /usr/lib/x86_64-linux-gnu/libtdb.so.1.2.12
--23260--   Considering /usr/lib/x86_64-linux-gnu/libtdb.so.1.2.12 ..
--23260--   .. CRC mismatch (computed b2a17100 wanted b4d683f4)
--23260--    object doesn't have a symbol table
--23260-- Reading syms from /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.0
--23260--   Considering /usr/lib/x86_64-linux-gnu/libltdl.so.7.3.0 ..
--23260--   .. CRC mismatch (computed d26b41ab wanted 3a5c804f)
--23260--    object doesn't have a symbol table
--23260-- REDIR: 0x152cd120 (libstdc++.so.6:operator delete[](void*)) redirected to 0x4c2c7d0 (operator delete[](void*))
--23260-- memcheck GC: 1000 nodes, 830 survivors ( 83.0%)
--23260-- memcheck GC: 1414 new table size (stepup)
--23260-- REDIR: 0x6989210 (libc.so.6:memalign) redirected to 0x4c2d070 (memalign)
--23260-- REDIR: 0x69a8030 (libc.so.6:wcscmp) redirected to 0x4c32390 (wcscmp)
==23260== Stack overflow in thread 1: can't grow stack to 0xffe801ff8
==23260==
==23260== Process terminating with default action of signal 11 (SIGSEGV)
==23260==  Access not within mapped region at address 0xFFE801FF8
==23260==    at 0x6F8132: zend_parse_parameters_ex (in /usr/bin/php5)
==23260==  If you believe this happened as a result of a stack
==23260==  overflow in your program's main thread (unlikely but
==23260==  possible), you can try to increase the size of the
==23260==  main thread stack using the --main-stacksize= flag.
==23260==  The main thread stack size used in this run was 8388608.
--23260-- Discarding syms at 0x233c76d0-0x233c8a06 in /usr/lib/x86_64-linux-gnu/gconv/UTF-32.so due to munmap()
--23260-- Discarding syms at 0x241cd2a0-0x241d3f63 in /lib/x86_64-linux-gnu/libnss_files-2.19.so due to munmap()
==23260==
==23260== HEAP SUMMARY:
==23260==     in use at exit: 24,548,940 bytes in 150,605 blocks
==23260==   total heap usage: 270,641 allocs, 120,036 frees, 35,322,941 bytes allocated
==23260==
==23260== Searching for pointers to 150,071 not-freed blocks
==23260== Checked 41,367,744 bytes
==23260==
==23260== 8 bytes in 1 blocks are possibly lost in loss record 701 of 40,908
==23260==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23260==    by 0x4C2CF1F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23260==    by 0x14B3B6AE: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0)
==23260==    by 0x148C7618: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==23260==    by 0x148CC0D4: g_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==23260==    by 0x148D4F71: g_pointer_type_register_static (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==23260==    by 0x148D4FF7: g_gtype_get_type (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==23260==    by 0x148BA8E7: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==23260==    by 0x148A75E9: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0)
==23260==    by 0x4010139: call_init.part.0 (dl-init.c:78)

Does the segfault involving zend_parse_parameters_ex shed any light on this?

I used this instructional to run Valgrind.