Problems with GTK+ 2, and window updating/refreshing.

wxPython Users
1

As I don’t know if this is a wxPython, or a wxWidgets issue (I’m leaning towards wxWidgets/wxGTK), I am sending to both lists, hoping someone will bite and help out of this jam.

My problem is: when in a GTK environment, any GTK environment, my windows start to act a little strange. My application (which is a Python app, and I am using wxPython for the GUI) has various frames which can be opened, with a number of controls on them (wxTextCtrl, wxListCtrl, wxCheckBox, wxButton, etc.). Sometimes (I have not quite nailed down exactly when, or how) when the window loads, it ceases to “update” these controls at all. Which means that clicking on them, entering anything in them, selecting anything from them, or data being loaded into them programmatically does not update the display. This more or less renders my application useless. The bizarre thing is that after about 30 seconds or so, everything updates and is ok, until some other unknown event happens that stops the updates from happening again – almost as if the main event loop gets broken, or the updates somehow get pulled out from the event loop. Curiously, I have been able to test and see that doing things to the UI does still produce events I am able to capture/handle – it just doesn’t update the UI at all (and moving the frame off-screen with the mouse, and back to on-screen, the controls look all garbled or wiped-clean off the frame – like something is sort of ‘stalling out’ during the update process).

Now… the following messages also come spewing out onto my console window where I start the application:

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1561 (g_object_re

f): assertion `G_IS_OBJECT (object)’ failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 841 (gtk_style_attach): a
ssertion `window != NULL’ failed

(python:25454): Gdk-CRITICAL **: file gdkwindow.c
: line 2262 (gdk_window_invalid
ate_maybe_recurse): assertion `window != NULL’ failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 910 (gtk_style_detach): a
ssertion `GTK_IS_STYLE (style)’ failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579 (g_object_un
ref): assertion `G_IS_OBJECT (object)’ failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579 (g_object_un

ref): assertion `G_IS_OBJECT (object)’ failed

I have tried to look and find what I could on the subject, but have failed miserably. I had originally thought it was the same error as the following bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1484670&group_id=9863&atid=109863

But it doesn’t appear to be the case. I had followed to the patch the individual who posted that bug had made:


http://sourceforge.net/tracker/index.php?func=detail&aid=1484667&group_id=9863&atid=309863

and tried it, with completely unsuccessful results. I really am at a loss here, and as this is for a system that needs to be ready to ship to a customer soon, I’m also quickly becoming short on time to resolve the issue. Any help would be most appreciated.

···

–
“I’m not responcabel fer my computer’s spleling errnors” - Xlorep DarkHelm
Website: http://darkhelm.org

2

Now... the following messages also come spewing out onto my console
window where I start the application:

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1561
(g_object_re
f): assertion `G_IS_OBJECT (object)' failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 841
(gtk_style_attach): a
ssertion `window != NULL' failed

(python:25454): Gdk-CRITICAL **: file gdkwindow.c : line 2262
(gdk_window_invalid
ate_maybe_recurse): assertion `window != NULL' failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 910
(gtk_style_detach): a
ssertion `GTK_IS_STYLE (style)' failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_un
ref): assertion `G_IS_OBJECT (object)' failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_un
ref): assertion `G_IS_OBJECT (object)' failed

I can not be sure if these assertions indicate that your problem might
happen, but critical warnings aren't good, and I have not seen those
before as to label them not causing your problem - they very well
might.

Have you tried with a different theme engine? For example the gtk-qt
engine, that makes gtk apps use the qt theme, has been historically very
prone to all kinds of problems. It would be worthwhile to try a
completely different theme engine, especially as some critical warnings
are style related, which in turn is drawing related.

It would also be interesting to know what causes these assertions
exactly. Could you try debugging this, setting a breakpoint at g_log, as
to see the stacktrace at that point, and see or report what's going on?
You might want to set the breakpoint after one run in gdb or in the
middle, as for gdb to actually know about the symbol from deep inside of
glib.

I have tried to look and find what I could on the subject, but have
failed miserably. I had originally thought it was the same error as
the following bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1484670&group_id=9863&atid=109863

But it doesn't appear to be the case. I had followed to the patch the
individual who posted that bug had made:

http://sourceforge.net/tracker/index.php?func=detail&aid=1484667&group_id=9863&atid=309863

and tried it, with completely unsuccessful results. I really am at a
loss here, and as this is for a system that needs to be ready to ship
to a customer soon, I'm also quickly becoming short on time to resolve
the issue. Any help would be most appreciated.

These patches are about forced updates in _user_ code, for the most
part. The symptoms you describe should have nothing to do with the above
tracker items.

Regards,
Mart Raudsepp

PS: I am not subscribed to wxPython-users, so replies to both lists
please, or at least wx-users.

···

On Mon, 2006-07-10 at 13:05 -0700, Cliff Hill wrote:

3

Now… the following messages also come spewing out onto my console
window where I start the application:

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1561
(g_object_re
f): assertion `G_IS_OBJECT (object)’ failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 841
(gtk_style_attach): a
ssertion `window != NULL’ failed

(python:25454): Gdk-CRITICAL **: file gdkwindow.c : line 2262
(gdk_window_invalid
ate_maybe_recurse): assertion `window != NULL’ failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 910
(gtk_style_detach): a
ssertion `GTK_IS_STYLE (style)’ failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_un
ref): assertion `G_IS_OBJECT (object)’ failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_un
ref): assertion `G_IS_OBJECT (object)’ failed

I can not be sure if these assertions indicate that your problem might

happen, but critical warnings aren’t good, and I have not seen those
before as to label them not causing your problem - they very well
might.

Have you tried with a different theme engine? For example the gtk-qt

engine, that makes gtk apps use the qt theme, has been historically very
prone to all kinds of problems. It would be worthwhile to try a
completely different theme engine, especially as some critical warnings

are style related, which in turn is drawing related.

Not entirely certain how to go about doing that. The thing is –
this is an application going on a production machine, that must remain
vanilla Red Hat Enterprise Linux 4, with as minimal modifications
(primarily installing the packages I need for my database & GUI
widgets) as I can get. I am using whatever theme engine that came
with the system, and I am using wxGTK, to my knowledge for wxWidgets to
work.

It would also be interesting to know what causes these assertions
exactly. Could you try debugging this, setting a breakpoint at g_log, as

to see the stacktrace at that point, and see or report what’s going on?
You might want to set the breakpoint after one run in gdb or in the
middle, as for gdb to actually know about the symbol from deep inside of

glib.

Not entirely certain how to perform a debug like you request in
Python. I’m also not authorized to add development software to
the production machine. I have seen this problem both on that
system, and on my home system where I was testing it out – my
home system uses ubuntu 6.06 (dapper) for its packages, and I
just simply used what was available in the distro.

I have tried to look and find what I could on the subject, but have

failed miserably. I had originally thought it was the same error as
the following bug:


http://sourceforge.net/tracker/index.php?func=detail&aid=1484670&group_id=9863&atid=109863

But it doesn’t appear to be the case. I had followed to the patch the
individual who posted that bug had made:

http://sourceforge.net/tracker/index.php?func=detail&aid=1484667&group_id=9863&atid=309863

and tried it, with completely unsuccessful results. I really am at a
loss here, and as this is for a system that needs to be ready to ship
to a customer soon, I’m also quickly becoming short on time to resolve

the issue. Any help would be most appreciated.

These patches are about forced updates in user code, for the most
part. The symptoms you describe should have nothing to do with the above
tracker items.

Ok.

Regards,
Mart Raudsepp

PS: I am not subscribed to wxPython-users, so replies to both lists

please, or at least wx-users.

No worries, I can send to both, anyone who can shed some light my
direction one way or the other on this would be a good thing.
After about a week of attempting to resolve this problem on my own, I
need some new eyes to look at it.

I’ll provide whatever information/data is needed, including snippets of
code (which would be Python, not C++ code), that is, if I can figure
out what code is doing this.

To make my GUI initially, I used wxGlade which produced the starting point for me, if that matters.

···

On 7/10/06, Mart Raudsepp leio@dustbite.net wrote:

On Mon, 2006-07-10 at 13:05 -0700, Cliff Hill wrote:

To unsubscribe, e-mail: wx-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wx-users-help@lists.wxwidgets.org

–
“I’m not responcabel fer my computer’s spleling errnors” - Xlorep DarkHelm
Website: http://darkhelm.org

4

There seems to be some connection to this happening and me opening a new frame.

···

On 7/10/06, Cliff Hill <xlorepdarkhelm@gmail.com > wrote:

On 7/10/06, Mart Raudsepp leio@dustbite.net wrote:

On Mon, 2006-07-10 at 13:05 -0700, Cliff Hill wrote:

Now… the following messages also come spewing out onto my console
window where I start the application:

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1561
(g_object_re
f): assertion `G_IS_OBJECT (object)’ failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 841
(gtk_style_attach): a
ssertion `window != NULL’ failed

(python:25454): Gdk-CRITICAL **: file gdkwindow.c : line 2262
(gdk_window_invalid
ate_maybe_recurse): assertion `window != NULL’ failed

(python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 910
(gtk_style_detach): a
ssertion `GTK_IS_STYLE (style)’ failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_un
ref): assertion `G_IS_OBJECT (object)’ failed

(python:25454): GLib-GObject-CRITICAL **: file gobject.c: line 1579
(g_object_un
ref): assertion `G_IS_OBJECT (object)’ failed

I can not be sure if these assertions indicate that your problem might

happen, but critical warnings aren’t good, and I have not seen those
before as to label them not causing your problem - they very well
might.

Have you tried with a different theme engine? For example the gtk-qt

engine, that makes gtk apps use the qt theme, has been historically very
prone to all kinds of problems. It would be worthwhile to try a
completely different theme engine, especially as some critical warnings

are style related, which in turn is drawing related.

Not entirely certain how to go about doing that. The thing is –
this is an application going on a production machine, that must remain
vanilla Red Hat Enterprise Linux 4, with as minimal modifications
(primarily installing the packages I need for my database & GUI
widgets) as I can get. I am using whatever theme engine that came
with the system, and I am using wxGTK, to my knowledge for wxWidgets to
work.

It would also be interesting to know what causes these assertions

exactly. Could you try debugging this, setting a breakpoint at g_log, as

to see the stacktrace at that point, and see or report what’s going on?
You might want to set the breakpoint after one run in gdb or in the
middle, as for gdb to actually know about the symbol from deep inside of

glib.

Not entirely certain how to perform a debug like you request in
Python. I’m also not authorized to add development software to
the production machine. I have seen this problem both on that
system, and on my home system where I was testing it out – my
home system uses ubuntu 6.06 (dapper) for its packages, and I
just simply used what was available in the distro.

I have tried to look and find what I could on the subject, but have

failed miserably. I had originally thought it was the same error as
the following bug:

[

http://sourceforge.net/tracker/index.php?func=detail&aid=1484670&group_id=9863&atid=109863](http://sourceforge.net/tracker/index.php?func=detail&aid=1484670&group_id=9863&atid=109863)

But it doesn’t appear to be the case. I had followed to the patch the
individual who posted that bug had made:

http://sourceforge.net/tracker/index.php?func=detail&aid=1484667&group_id=9863&atid=309863

and tried it, with completely unsuccessful results. I really am at a
loss here, and as this is for a system that needs to be ready to ship
to a customer soon, I’m also quickly becoming short on time to resolve

the issue. Any help would be most appreciated.

These patches are about forced updates in user code, for the most
part. The symptoms you describe should have nothing to do with the above
tracker items.

Ok.

Regards,
Mart Raudsepp

PS: I am not subscribed to wxPython-users, so replies to both lists

please, or at least wx-users.

No worries, I can send to both, anyone who can shed some light my
direction one way or the other on this would be a good thing.
After about a week of attempting to resolve this problem on my own, I
need some new eyes to look at it.

I’ll provide whatever information/data is needed, including snippets of
code (which would be Python, not C++ code), that is, if I can figure
out what code is doing this.

To make my GUI initially, I used wxGlade which produced the starting point for me, if that matters.

To unsubscribe, e-mail: wx-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wx-users-help@lists.wxwidgets.org

–
“I’m not responcabel fer my computer’s spleling errnors” - Xlorep DarkHelm

Website: http://darkhelm.org

–
“I’m not responcabel fer my computer’s spleling errnors” - Xlorep DarkHelm
Website: http://darkhelm.org

5

        > Now... the following messages also come spewing out onto my
        console
        > window where I start the application:
        >
        > (python:25454): GLib-GObject-CRITICAL **: file gobject.c:
        line 1561
        > (g_object_re
        > f): assertion `G_IS_OBJECT (object)' failed
        >
        > (python:25454): Gtk-CRITICAL **: file gtkstyle.c: line 841
        > (gtk_style_attach): a
        > ssertion `window != NULL' failed

<snip>

        I can not be sure if these assertions indicate that your
        problem might
        happen, but critical warnings aren't good, and I have not seen
        those
        before as to label them not causing your problem - they very
        well
        might.
        
        Have you tried with a different theme engine? For example the
        gtk-qt
        engine, that makes gtk apps use the qt theme, has been
        historically very
        prone to all kinds of problems. It would be worthwhile to try
        a
        completely different theme engine, especially as some critical
        warnings
        are style related, which in turn is drawing related.

Not entirely certain how to go about doing that. The thing is -- this
is an application going on a production machine, that must remain
vanilla Red Hat Enterprise Linux 4, with as minimal modifications
(primarily installing the packages I need for my database & GUI
widgets) as I can get. I am using whatever theme engine that came
with the system, and I am using wxGTK, to my knowledge for wxWidgets
to work.

        It would also be interesting to know what causes these
        assertions
        exactly. Could you try debugging this, setting a breakpoint at
        g_log, as
        to see the stacktrace at that point, and see or report what's
        going on?
        You might want to set the breakpoint after one run in gdb or
        in the
        middle, as for gdb to actually know about the symbol from deep
        inside of
        glib.

Not entirely certain how to perform a debug like you request in
Python. I'm also not authorized to add development software to the
production machine. I have seen this problem both on that system, and
on my home system where I was testing it out -- my home system uses
ubuntu 6.06 (dapper) for its packages, and I just simply used what was
available in the distro.

<snap>

I'll provide whatever information/data is needed, including snippets
of code (which would be Python, not C++ code), that is, if I can
figure out what code is doing this.

Could you please start with the tests and instructions provided earlier?

You can run your python program in gdb easily, provided you have gdb,
which is a near necessity for development anyhow.
Just run gdb --arg python foo.py, launch it and at some point set the
breakpoint and get a stacktrace. It's just about launching python inside
gdb.

As for the theme engine switch, you can always switch it on your
development computer where the problem also occurs. No-one is forcing
you to do that while in production use - we want to simply know if this
sheds some light into the matter.
I work with wxGTK often and have never been able to reproduce what you
are seeing, so checking out things on your machine by you is good. Also,
if you can do a little sample that shows the problem at least on your
system(s), we can look at that if the above doesn't give any ideas.

To make my GUI initially, I used wxGlade which produced the starting
point for me, if that matters.

Regards,
Mart Raudsepp

···

On Mon, 2006-07-10 at 13:38 -0700, Cliff Hill wrote:

On 7/10/06, Mart Raudsepp <leio@dustbite.net> wrote:
        On Mon, 2006-07-10 at 13:05 -0700, Cliff Hill wrote:

6

Could you please start with the tests and instructions provided earlier?

Yea, working on it.

You can run your python program in gdb easily, provided you have gdb,
which is a near necessity for development anyhow.

Just run gdb --arg python foo.py, launch it and at some point set the
breakpoint and get a stacktrace. It’s just about launching python inside
gdb.

Ok, here’s the output from gdb (it is all of the stackframes):

(gdb) backtrace

#0 0x007c77a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

#1 0x0080b955 in raise () from /lib/tls/libc.so.6

#2 0x0080d319 in abort () from /lib/tls/libc.so.6

#3 0x00b8cebe in g_logv () from /usr/lib/libglib-2.0.so.0

#4 0x00b8cef0 in g_log () from /usr/lib/libglib-2.0.so.0

#5 0x04e80dc1 in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#6 0x04e80f5d in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#7 0x04ec7c3d in gtk_frame_new () from /usr/lib/libgtk-x11-2.0.so.0

#8 0x04e7ef26 in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0

#9 0x04e80bf7 in gtk_container_get_focus_hadjustment ()

from /usr/lib/libgtk-x11-2.0.so.0

#10 0x04ec883a in gtk_frame_get_shadow_type ()

from /usr/lib/libgtk-x11-2.0.so.0

#11 0x04efde67 in gtk_marshal_VOID__UINT_STRING ()

from /usr/lib/libgtk-x11-2.0.so.0

#12 0x003d36b2 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0

#13 0x003d3347 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0

#14 0x003e9576 in g_signal_has_handler_pending ()

from /usr/lib/libgobject-2.0.so.0

#15 0x003ea613 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0

#16 0x003eac5a in g_signal_emit () from /usr/lib/libgobject-2.0.so.0

—Type to continue, or q to quit—

#17 0x04ff1a75 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0

#18 0x04e80f2e in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#19 0x04e80f5d in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#20 0x00e3b917 in gtk_pizza_forall ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#21 0x04e7ef26 in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0

#22 0x04e80bf7 in gtk_container_get_focus_hadjustment ()

from /usr/lib/libgtk-x11-2.0.so.0

#23 0x00e435ed in gtk_window_expose_callback ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#24 0x04efde67 in gtk_marshal_VOID__UINT_STRING ()

from /usr/lib/libgtk-x11-2.0.so.0

#25 0x003d3347 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0

#26 0x003e894e in g_signal_has_handler_pending ()

from /usr/lib/libgobject-2.0.so.0

#27 0x003ea613 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0

#28 0x003eac5a in g_signal_emit () from /usr/lib/libgobject-2.0.so.0

#29 0x04ff1a75 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0

#30 0x04efc741 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0

#31 0x0038978f in gdk_window_clear_area_e () from /usr/lib/libgdk-x11-2.0.so.0

#32 0x00389828 in gdk_window_process_all_updates ()

—Type to continue, or q to quit—

from /usr/lib/libgdk-x11-2.0.so.0

#33 0x04e7ea6c in gtk_container_check_resize ()

from /usr/lib/libgtk-x11-2.0.so.0

#34 0x00b87a98 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0

#35 0x00b8474b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0

#36 0x00b861d2 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0

#37 0x00b8647f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0

#38 0x04efb78e in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0

#39 0x00e2d59c in wxEventLoop::Run ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#40 0x00eb44fe in wxAppBase::MainLoop ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#41 0x0012e55f in wxPyApp::MainLoop ()

from /usr/lib/python2.3/site-packages/wx-2.6-gtk2-unicode/wx/core.so

#42 0x0018400c in wxPySizer::wxCreateObject ()

from /usr/lib/python2.3/site-packages/wx-2.6-gtk2-unicode/wx/core.so

#43 0x00a6c895 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0

#44 0x00a49607 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0

#45 0x00a9e998 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0

#46 0x00aa109e in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0

#47 0x00a5ce2e in PyFunction_SetClosure () from /usr/lib/libpython2.3.so.1.0

#48 0x00a49607 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0

#49 0x00a50d98 in PyMethod_New () from /usr/lib/libpython2.3.so.1.0

—Type to continue, or q to quit—

#50 0x00a49607 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0

#51 0x00a9eb7f in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0

#52 0x00aa097b in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0

#53 0x00aa109e in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0

#54 0x00aa1362 in PyEval_EvalCode () from /usr/lib/libpython2.3.so.1.0

#55 0x00aba817 in PyErr_Display () from /usr/lib/libpython2.3.so.1.0

#56 0x00abb942 in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.3.so.1.0

#57 0x00abc994 in PyRun_AnyFileExFlags () from /usr/lib/libpython2.3.so.1.0

#58 0x00ac168e in Py_Main () from /usr/lib/libpython2.3.so.1.0

#59 0x080485b2 in main ()

As for the theme engine switch, you can always switch it on your
development computer where the problem also occurs. No-one is forcing

you to do that while in production use - we want to simply know if this
sheds some light into the matter.

My problem is… my development computer is Win2K, and I am not
entirely certain how to get wxWidgets to pay attention to the GTK+ I
have installed on that system. I can send the files home to look
at there, but the problem with that is… I won’t be able to check that
out until I get home, which will be quite a bit later.

I work with wxGTK often and have never been able to reproduce what you
are seeing, so checking out things on your machine by you is good. Also,

if you can do a little sample that shows the problem at least on your
system(s), we can look at that if the above doesn’t give any ideas.

I’ve been checking… Right now, I am trying to get a secondary linux
system up and running, which I can then use to test the system out on,
and attempt to duplicate the problem. The linux computer will be
a “vanilla” install of Fedora Core 3, which is closest to what the
production server is (Red Hat Enterprise Linux 4).

Regards,
Mart Raudsepp

I do appreciate your help, and when I can get the rest of your requests completed, I will provide the information here.

···

On 7/10/06, Mart Raudsepp leio@dustbite.net wrote:

–
“I’m not responcabel fer my computer’s spleling errnors” - Xlorep DarkHelm
Website: http://darkhelm.org

7

Ok, I just put everything on a system that is a vanilla Fedora Core 3 box – the closest distro to what we have on the production box (Red Hat Enterprise Linux 4, provided by the customer in question – has basically the same versions of the system components as FC3). I installed wxPython 2.6.3.2 (using the same RPMs I did for the production server) onto the system, which has Python 2.3 on it already. I fired up my program and… no bug. Try as I might, I got absolutely no duplication of the problem. On Ubuntu Dapper 6.06, and on Red Hat Enterprise Linux 4, it exists. On Fedora Core 3, it doesn’t. However, I’ve been getting a wierd segfault issue from wxPython… and I think the RPMs I built might be faulty, so I’m making a new clean batch of them, to try this again.

···

On 7/10/06, Cliff Hill xlorepdarkhelm@gmail.com wrote:

On 7/10/06, Mart Raudsepp < > leio@dustbite.net> wrote:

Could you please start with the tests and instructions provided earlier?

Yea, working on it.

You can run your python program in gdb easily, provided you have gdb,

which is a near necessity for development anyhow.

Just run gdb --arg python foo.py, launch it and at some point set the
breakpoint and get a stacktrace. It’s just about launching python inside
gdb.

Ok, here’s the output from gdb (it is all of the stackframes):

(gdb) backtrace

#0 0x007c77a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

#1 0x0080b955 in raise () from /lib/tls/libc.so.6

#2 0x0080d319 in abort () from /lib/tls/libc.so.6

#3 0x00b8cebe in g_logv () from /usr/lib/libglib-2.0.so.0

#4 0x00b8cef0 in g_log () from /usr/lib/libglib-2.0.so.0

#5 0x04e80dc1 in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#6 0x04e80f5d in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#7 0x04ec7c3d in gtk_frame_new () from /usr/lib/libgtk-x11-2.0.so.0

#8 0x04e7ef26 in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0

#9 0x04e80bf7 in gtk_container_get_focus_hadjustment ()

from /usr/lib/libgtk-x11-2.0.so.0

#10 0x04ec883a in gtk_frame_get_shadow_type ()

from /usr/lib/libgtk-x11-2.0.so.0

#11 0x04efde67 in gtk_marshal_VOID__UINT_STRING ()

from /usr/lib/libgtk-x11-2.0.so.0

#12 0x003d36b2 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0

#13 0x003d3347 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0

#14 0x003e9576 in g_signal_has_handler_pending ()

from /usr/lib/libgobject-2.0.so.0

#15 0x003ea613 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0

#16 0x003eac5a in g_signal_emit () from /usr/lib/libgobject-2.0.so.0

—Type to continue, or q to quit—

#17 0x04ff1a75 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0

#18 0x04e80f2e in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#19 0x04e80f5d in gtk_container_propagate_expose ()

from /usr/lib/libgtk-x11-2.0.so.0

#20 0x00e3b917 in gtk_pizza_forall ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#21 0x04e7ef26 in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0

#22 0x04e80bf7 in gtk_container_get_focus_hadjustment ()

from /usr/lib/libgtk-x11-2.0.so.0

#23 0x00e435ed in gtk_window_expose_callback ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#24 0x04efde67 in gtk_marshal_VOID__UINT_STRING ()

from /usr/lib/libgtk-x11-2.0.so.0

#25 0x003d3347 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0

#26 0x003e894e in g_signal_has_handler_pending ()

from /usr/lib/libgobject-2.0.so.0

#27 0x003ea613 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0

#28 0x003eac5a in g_signal_emit () from /usr/lib/libgobject-2.0.so.0

#29 0x04ff1a75 in gtk_widget_activate () from /usr/lib/libgtk-x11-2.0.so.0

#30 0x04efc741 in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0

#31 0x0038978f in gdk_window_clear_area_e () from /usr/lib/libgdk-x11-2.0.so.0

#32 0x00389828 in gdk_window_process_all_updates ()

—Type to continue, or q to quit—

from /usr/lib/libgdk-x11-2.0.so.0

#33 0x04e7ea6c in gtk_container_check_resize ()

from /usr/lib/libgtk-x11-2.0.so.0

#34 0x00b87a98 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0

#35 0x00b8474b in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0

#36 0x00b861d2 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0

#37 0x00b8647f in g_main_loop_run () from /usr/lib/libglib-2.0.so.0

#38 0x04efb78e in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0

#39 0x00e2d59c in wxEventLoop::Run ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#40 0x00eb44fe in wxAppBase::MainLoop ()

from /usr/lib/wxPython-2.6.3.2-gtk2-unicode/lib/libwx_gtk2ud-2.6.so.0

#41 0x0012e55f in wxPyApp::MainLoop ()

from /usr/lib/python2.3/site-packages/wx-2.6-gtk2-unicode/wx/core.so

#42 0x0018400c in wxPySizer::wxCreateObject ()

from /usr/lib/python2.3/site-packages/wx-2.6-gtk2-unicode/wx/core.so

#43 0x00a6c895 in PyCFunction_Call () from /usr/lib/libpython2.3.so.1.0

#44 0x00a49607 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0

#45 0x00a9e998 in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0

#46 0x00aa109e in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0

#47 0x00a5ce2e in PyFunction_SetClosure () from /usr/lib/libpython2.3.so.1.0

#48 0x00a49607 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0

#49 0x00a50d98 in PyMethod_New () from /usr/lib/libpython2.3.so.1.0

—Type to continue, or q to quit—

#50 0x00a49607 in PyObject_Call () from /usr/lib/libpython2.3.so.1.0

#51 0x00a9eb7f in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0

#52 0x00aa097b in _PyEval_SliceIndex () from /usr/lib/libpython2.3.so.1.0

#53 0x00aa109e in PyEval_EvalCodeEx () from /usr/lib/libpython2.3.so.1.0

#54 0x00aa1362 in PyEval_EvalCode () from /usr/lib/libpython2.3.so.1.0

#55 0x00aba817 in PyErr_Display () from /usr/lib/libpython2.3.so.1.0

#56 0x00abb942 in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.3.so.1.0

#57 0x00abc994 in PyRun_AnyFileExFlags () from /usr/lib/libpython2.3.so.1.0

#58 0x00ac168e in Py_Main () from /usr/lib/libpython2.3.so.1.0

#59 0x080485b2 in main ()

As for the theme engine switch, you can always switch it on your

development computer where the problem also occurs. No-one is forcing

you to do that while in production use - we want to simply know if this
sheds some light into the matter.

My problem is… my development computer is Win2K, and I am not
entirely certain how to get wxWidgets to pay attention to the GTK+ I
have installed on that system. I can send the files home to look
at there, but the problem with that is… I won’t be able to check that
out until I get home, which will be quite a bit later.

I work with wxGTK often and have never been able to reproduce what you

are seeing, so checking out things on your machine by you is good. Also,

if you can do a little sample that shows the problem at least on your
system(s), we can look at that if the above doesn’t give any ideas.

I’ve been checking… Right now, I am trying to get a secondary linux
system up and running, which I can then use to test the system out on,
and attempt to duplicate the problem. The linux computer will be
a “vanilla” install of Fedora Core 3, which is closest to what the
production server is (Red Hat Enterprise Linux 4).

Regards,
Mart Raudsepp

I do appreciate your help, and when I can get the rest of your requests completed, I will provide the information here.

–
“I’m not responcabel fer my computer’s spleling errnors” - Xlorep DarkHelm
Website: http://darkhelm.org

–
“I’m not responcabel fer my computer’s spleling errnors” - Xlorep DarkHelm
Website: http://darkhelm.org

8

Have you looked at CentOS 4? It's a lot more like RHEL4 than FC3, since it's
built from the exact same source.

···

On Mon, Jul 10, 2006 at 03:15:53PM -0700, Cliff Hill wrote:

Ok, I just put everything on a system that is a vanilla Fedora Core 3 box --
the closest distro to what we have on the production box (Red Hat Enterprise
Linux 4, provided by the customer in question -- has basically the same

--
Matthew Miller mattdm@mattdm.org <http://mattdm.org/&gt;
Boston University Linux ------> <http://linux.bu.edu/&gt;