Andre Colomb wrote:
> Hi again!
> 
> Just took some more time to investigate on my problems with PHP-Gtk
> 2.0.0 and 2.0.1. Let me explain the overall situation first:
> 
> I work as a programmer for a research institute, currently on a project
> involving PHP-Gtk. Unfortunately so far it looks like it will not be
> open-sourced. The problems started occuring while I was trying to go
> from the beta version to the 2.0.0 release and were not fixed by 2.0.1.
> The application makes use of the ODBC extension and displays some data
> in several GtkTreeViews using stock GtkTreeStore and GtkListStore as
> well as custom derived model classes.
> 
> When running my application with PHP-Gtk starting at 2.0.0, I get an
> error message during startup saying that
> 'the instruction at "0x1008bd58" points to memory at "0x0000005d". The
> operation "read" could not be executed on that memory. Click OK to exit
> the program, Cancel to debug.' (Translated from the German error message.)
> 
> I tried to narrow it down to where in the PHP source the error occurs
> using simple echo statements. It's been a while since then and I was
> assigned to a different project meanwhile, then continued development
> with the PHP-Gtk beta version. So I'm not quite sure about the details I
> found out back then. IIRC, the error occured between calls to the
> append() and set() methods on a regular GtkListStore object. I fetched
> some data from the database into an associative array, then accessed the
> array when passing parameters to set(). Copying the value to another
> variable, then passing that to set() worked around the segfault but
> produced garbage in the list row (and another segfault at a later query
> I think).
> 
> Curiously, calling var_dump($database_result_row) also gave me garbage.
> That is, before the call to append() it contained the correct database
> values, but between append() and set(), the array content magically
> changed. So I guess that there is some kind of buffer overflow in the
> append() code or somewhere around it.
> 
> Now I have just successfully reproduced the segfault on my laptop at
> home. It occurs in a different place, but also between a database query
> and the list store append(). The query result array is still intact.
> However, a few lines above, a similar construct returns NULL values or
> random integer values for the database row and causes the segfault to
> appear a few lines earlier. But only when var_dump()ing that earlier result.
> 
> As you can see, the behaviour varies wildly between different machines
> and produces unpredictable behaviour when changing single lines of code.
> With the PHP-Gtk2 beta, I haven't had a single segfault so I think this
> is a regression. Unfortunately, it could be in a different module or
> even related to some other PHP extension, and just by accident always
> happens to show up between those calls.
> 
> I'm afraid I cannot give you much more useful information right now. I'm
> not very experienced in Windows debugging and have no clue about the
> Zend internals. Also, I'm not sure whether I can provide the source code
> for others to reproduce the error as I haven't succeded in writing a
> simpler test case yet. But I'm offering to spend some time trying to
> nail it down and report back my results.
> 
> So can someone please give me a quick introduction about PHP-Gtk
> debugging on a Windows XP system and the required Zend internals to find
> memory handling errors in some extension?
> 
> Hope this won't get too complicated and time-consuming as my boss will
> probably not support it and tell me to stick with the beta if it works.
> 
> Regards,
> Andre

Without a simple reproducing script this is going to be incredibly
difficult to debug, no matter how much you know about zend internals,
PHP, and windows.

Please take your code and hack it down to the smallest possible
reproducing script before you do anything else (20 lines or less if at
all possible), just var_dumping or echoing until you hit a segfault
often won't work if the issue is memory corruption since the corruption
might have happened a lot earlier in the script.

It might help if you can get a backtrace for the segfault (the crash
you're getting) - there are very good instructionw for that here -
http://bugs.php.net/bugs-generating-backtrace-win32.php

However a simple test case that shows the crash is the best way to get
it fixed.

Thanks,
Elizabeth Smith