Hello list,
I've been trying to get one last GDAL module to compile and load in PHP. At
the moment, it's getting hung up on a line that appears to be producing a null
pointer exception (If I'm interpreting the output from valgrind correctly -
see below). That is, the module compiles fine...but when PHP attempts to load
the module it produces a segfault on startup (i.e., before any PHP code is
even executed). The error appears to be specifically related to a line that is
written to the gdal_wrap.cpp file that looks like the following:
ZEND_REGISTER_RESOURCE(z, value, *(int *)(type->clientdata));
I can manually comment-out that line and recompile, and it does eliminate the
segault...but I'm sure that's not the solution here. I'm not clear on whether
the problem is an issue with the typemaps or other configuration with the swig
bindings for the GDAL project, or if this is a SWIG-specific bug that is
producing the issue. The valgrind output is below - if it would help, I can
include a copy of the gdal_wrap.cpp that is also being generated.
Would anyone have any suggestions?
Best regards,
Mike
=====================================================
==18577== Memcheck, a memory error detector
==18577== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==18577== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==18577== Command: ./gdaltest
==18577== Parent PID: 19916
==18577==
==18577== Invalid read of size 8
==18577== at 0x69E5FF: _zend_hash_index_update_or_next_insert (in
/usr/bin/php5)
==18577== by 0x6A16C3: zend_list_insert (in /usr/bin/php5)
==18577== by 0x6A180D: zend_register_resource (in /usr/bin/php5)
==18577== by 0x7CFF764: SWIG_ZTS_SetPointerZval(_zval_struct*, void*,
swig_type_info*, int) (in /usr/lib/php5/20090626/php_gdal.so)
==18577== by 0x7D2E129: zm_startup_gdal (in
/usr/lib/php5/20090626/php_gdal.so)
==18577== by 0x69372D: zend_startup_module_ex (in /usr/bin/php5)
==18577== by 0x69F8D3: zend_hash_apply (in /usr/bin/php5)
==18577== by 0x6975C9: zend_startup_modules (in /usr/bin/php5)
==18577== by 0x63FA83: php_module_startup (in /usr/bin/php5)
==18577== by 0x72BA4C: php_cli_startup (in /usr/bin/php5)
==18577== by 0x72C447: main (in /usr/bin/php5)
==18577== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==18577==
==18577==
==18577== Process terminating with default action of signal 11 (SIGSEGV)
==18577== Access not within mapped region at address 0x0
==18577== at 0x69E5FF: _zend_hash_index_update_or_next_insert (in
/usr/bin/php5)
==18577== by 0x6A16C3: zend_list_insert (in /usr/bin/php5)
==18577== by 0x6A180D: zend_register_resource (in /usr/bin/php5)
==18577== by 0x7CFF764: SWIG_ZTS_SetPointerZval(_zval_struct*, void*,
swig_type_info*, int) (in /usr/lib/php5/20090626/php_gdal.so)
==18577== by 0x7D2E129: zm_startup_gdal (in
/usr/lib/php5/20090626/php_gdal.so)
==18577== by 0x69372D: zend_startup_module_ex (in /usr/bin/php5)
==18577== by 0x69F8D3: zend_hash_apply (in /usr/bin/php5)
==18577== by 0x6975C9: zend_startup_modules (in /usr/bin/php5)
==18577== by 0x63FA83: php_module_startup (in /usr/bin/php5)
==18577== by 0x72BA4C: php_cli_startup (in /usr/bin/php5)
==18577== by 0x72C447: main (in /usr/bin/php5)
==18577== If you believe this happened as a result of a stack
==18577== overflow in your program's main thread (unlikely but
==18577== possible), you can try to increase the size of the
==18577== main thread stack using the --main-stacksize= flag.
==18577== The main thread stack size used in this run was 8388608.
==18577==
==18577== HEAP SUMMARY:
==18577== in use at exit: 2,598,225 bytes in 18,707 blocks
==18577== total heap usage: 20,944 allocs, 2,237 frees, 2,858,531 bytes
allocated
==18577==
==18577== LEAK SUMMARY:
==18577== definitely lost: 0 bytes in 0 blocks
==18577== indirectly lost: 0 bytes in 0 blocks
==18577== possibly lost: 3,610 bytes in 120 blocks
==18577== still reachable: 2,594,615 bytes in 18,587 blocks
==18577== suppressed: 0 bytes in 0 blocks
==18577== Rerun with --leak-check=full to see details of leaked memory
==18577==
==18577== For counts of detected and suppressed errors, rerun with: -v
==18577== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 16 from 8)

On 15/03/11 01:54, David Maxwell wrote:
> Hi:
>
> In the tiny example with full source listed below I am wrapping some C++ code for calling in python. There is a function with declaration
>
> void echo(const char msg[],int level=3);
>
> begin wrapped. When called from python [import example; example.echo('hi')] there is an error message:
>
> NotImplementedError: Wrong number of arguments for overloaded function 'echo'.
> Possible C/C++ prototypes are:
> echo(char const [],int)
> echo(char const [])
>
> Changing the definition to use char* rather than char[] results in code that runs fine:
>
> void echo(const char *msg,int level=3);
>
> Similarly, removing the default argument
>
> void echo(const char msg[],int level);
>
> leads to code that runs just fine.
>
> The error seems to arise from the call to:
> int res = SWIG_AsCharArray(argv[0], (char *)0, 0);
> in the generated function _wrap_echo. The only way I can see that this call will not return an error is if argv[0] has length zero (and indeed example.echo("") works!).
>
> Can someone suggest a workaround? I'd prefer to not make wholesale changes of char[] to char * to the code that I am wrapping. Is there a way for me to replace the body of SWIG_AsCharArray with code that behaves better?
>
I've fixed this in svn. You can just use this typecheck typemap instead
in your interface file until you upgrade:
%typemap(typecheck,noblock=1,precedence=140,
fragment="SWIG_AsCharPtrAndSize") const char[] {
int res = SWIG_AsCharPtrAndSize($input, 0, NULL, 0);
$1 = SWIG_CheckState(res);
}
William

In versions of swig prior to 2.0, I could pass the path to the input file in
quotes and it would properly deal with spaces in the path, like so:
Now with 2.0.2, it exits with:
(4) : Error: Unable to find 'c:\Users\barkley\My'
(999999) : Error: Unterminated string constant starting at line 4
Obviously, from the path name, this is happening with the Windows build of
swig. I've verified that this worked with swigwin-1.3.40.
Is this a regression, or is there a new/better way of handling paths with
spaces for swig 2?