Segfaults around GtkListStore::append()

[Andre Colomb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
- --
Greetings...
From: Andre Colomb <acolomb@...>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjn50oACgkQZ6c/lG/u2qxvfgCgoYD5Y7CtoBQ/w0O0R4CYAWjX
EJgAnA6NasjNQItFPTg3jSQHz2PCeDH7
=Qt64
-----END PGP SIGNATURE-----

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Elizabeth M Smith]

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

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[kksou]

Hi Andre,

Yes, PHP-GTK2.0 and 2.0.1 is a lot more "temperamental" than the beta version. I've spent quite a bit of time too when migrating from the beta version to 2.0.

The most "frustrating" part is that: sometimes the error messages given do not correspond to the actual cause of the problem, which I believe is your case. I know it says segfault. But believe me, most likely it's nothing to do with any of the error message given.

Since you are using GtkTreeStore and GtkListStore, can you check if you have any statement like:
GtkTreeViewColumn::set_alignment(1), or
$cell_renderer->set_property("xalign", 1), or
$cell_renderer->set_property("yalign", 0);

If you have, change these to:
GtkTreeViewColumn::set_alignment(1.0), or
$cell_renderer->set_property("xalign", 1.0);
$cell_renderer->set_property("yalign", 0.0);

For the beta version, putting 0 or 1 works fine. But in PHP-GTK v2.0/2.01, putting 0 or 1 will give very strange and misleading error. You have to put 0.0 or 1.0. You might laugh at this. But try to see if you have any of these in your program. It might solve your problem.

I've documented some of my experiences in the article:
http://www.kksou.com/php-gtk2/References/Migration-to-the-new-PHP-GTK-v2.0-release.php
Hope it will save you some time.

I've been using PHP-GTK v2.0/v2.01 for some time. My experience so far is that it's as stable and robust (if not better) than the previous version. If there's any error, it's usually my own program error. Yes, there are still many desired features to be added in PHP-GTK2. But I've yet to find a bug that gives inconsistent output or unstable result.

Elizabeth M Smith wrote:

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.

The method described by Elizabeth is what I'm been using most of the time to debug PHP-GTK2 apps too. It's a bit tedious and "primitive". But it's the clearest and fastest way to debug a complicated PHP-GTK app. Interestingly, many of the sample codes on my site are the by-products of my debugging process.

If you still have problem finding where the bug is, and you're able to come out with the the smallest possible reproducing script as described by Elizabeth, please post the code here. I will help to find where might be the problem.

Regards,
/kksou

Elizabeth M Smith wrote:

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

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php