wxPython: help(wx) causes segfaulting?

[Tim Chase]

Trying to get my feet wet with wxPython (moving from just
command-line apps), I tried the obvious (or, at least to me
was obvious):

Start python, "import wx" and then do a "help(wx)" to see
what it can tell me.

Unfortunately, it spewed back a handful of errors, gasped,
wheezed and died semi-hideously.

It's a stock install of Python 2.3.5 on Debian (testing).
The session has been pasted below if it's of any help. I
can successfully "dir(wx)" and get back all the goods.
However, the call to help() bombs out.

I'm having trouble figuring out what went wrong in the
matter: it looks like "g_object_new" is failing some
assertion test, but not knowing the internal workings of
CPython, I'm afraid this doesn't mean much to me. Any help
or suggestions would be appreciated.

If it makes a difference, other wxPython apps seem to run
just fine (particularly pyalacarte has no trouble).

Thanks,

-tkc


Python 2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
(process:11000): GLib-GObject-CRITICAL **: gtype.c:2254:
initialization assertion failed, use IA__g_type_init() prior
to this function

(process:11000): GLib-GObject-CRITICAL **: gtype.c:2254:
initialization assertion failed, use IA__g_type_init() prior
to this function

(process:11000): GLib-GObject-CRITICAL **: gtype.c:2254:
initialization assertion failed, use IA__g_type_init() prior
to this function

(process:11000): GLib-GObject-CRITICAL **:
g_type_add_interface_static: assertion
`G_TYPE_IS_INSTANTIATABLE (instance_type)' failed

(process:11000): GLib-GObject-CRITICAL **: gtype.c:2254:
initialization assertion failed, use IA__g_type_init() prior
to this function

(process:11000): GLib-GObject-CRITICAL **: gtype.c:2254:
initialization assertion failed, use IA__g_type_init() prior
to this function

(process:11000): GLib-GObject-CRITICAL **: gtype.c:2254:
initialization assertion failed, use IA__g_type_init() prior
to this function

(process:11000): GLib-GObject-CRITICAL **: g_object_new:
assertion `G_TYPE_IS_OBJECT (object_type)' failed
Segmentation fault

 

[Franz Steinhaeusler]

Trying to get my feet wet with wxPython (moving from just
command-line apps), I tried the obvious (or, at least to me
was obvious):

Start python, "import wx" and then do a "help(wx)" to see
what it can tell me.

I tried it on Windows Xp, and I got also a traceback:
Traceback (most recent call last):
File "<input>", line 1, in ?
File "C:\Python24\lib\site.py", line 328, in __call__
return pydoc.help(*args, **kwds)
File "C:\Python24\lib\pydoc.py", line 1640, in __call__
self.help(request)
File "C:\Python24\lib\pydoc.py", line 1684, in help
else: doc(request, 'Help on %s:')
File "C:\Python24\lib\pydoc.py", line 1468, in doc
pager(title % desc + '\n\n' + text.document(object, name))
File "C:\Python24\lib\pydoc.py", line 296, in document
if inspect.ismodule(object): return self.docmodule(*args)
File "C:\Python24\lib\pydoc.py", line 1070, in docmodule
contents.append(self.document(value, key, name))
File "C:\Python24\lib\pydoc.py", line 297, in document
if inspect.isclass(object): return self.docclass(*args)
File "C:\Python24\lib\pydoc.py", line 1194, in docclass
lambda t: t[1] == 'method')
File "C:\Python24\lib\pydoc.py", line 1144, in spill
name, mod, object))
File "C:\Python24\lib\pydoc.py", line 298, in document
if inspect.isroutine(object): return self.docroutine(*args)
File "C:\Python24\lib\pydoc.py", line 1255, in docroutine
doc = getdoc(object) or ''
File "C:\Python24\lib\pydoc.py", line 76, in getdoc
result = inspect.getdoc(object) or inspect.getcomments(object)
File "C:\Python24\lib\inspect.py", line 448, in getcomments
lines, lnum = findsource(object)
File "C:\Python24\lib\inspect.py", line 437, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range

 

[=?iso-8859-1?B?QW5kcuk=?=]

I tried it on Windows Xp, and I got also a traceback:

Traceback (most recent call last):

[snip]

I don't seem to have any problem (except that it takes a while to load)

C:\Documents and Settings\André>python
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.Help on package wx:

NAME
wx

FILE
c:\python24\lib\site-packages\wx-2.6-msw-unicode\wx\__init__.py

DESCRIPTION

#---------------------------------------------------------------------------
-
# Name: __init__.py
# Purpose: The presence of this file turns this directory into
a
# Python package.
#
# Author: Robin Dunn
#
# Created: 8-Aug-1998
# RCS-ID: $Id: __init__.py,v 1.11 2005/06/02 03:31:17 RD Exp
$
# Copyright: (c) 1998 by Total Control Software
# Licence: wxWindows license

#---------------------------------------------------------------------------
-

PACKAGE CONTENTS
__version__
_activex
_animate
_calendar
-- More --

However, please note that your (Original Poster) time would probably be
better invested by looking at the very comprehensive wxPython demo (it
may require a separate download).

André

 

[Franz Steinhaeusler]

I tried it on Windows Xp, and I got also a traceback:

Traceback (most recent call last):

[snip]

I don't seem to have any problem (except that it takes a while to load)

C:\Documents and Settings\André>python
ActivePython 2.4.2 Build 248 (ActiveState Corp.) based on
Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 32 bit (Intel)]
on win32

C:\Python24\Lib\site-packages\wx-2.621-msw-ansi>python
ActivePython 2.4 Build 244 (ActiveState Corp.) based on
Python 2.4 (#60, Feb 9 2005, 19:03:27) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

maybe you have 2.4.2 and I 2.4.

 

[Magnus Lycka]

maybe you have 2.4.2 and I 2.4.

This looks like a wxPython problem, not a Python problem.
It might well be a version issue for you guys, but it's
more likely that a certain wxPython version is the culprit,
not a certain Python version.

Note however that the OP is using Linux, where the wxWidgets
uses completely different libraries, and that's where the
problem occurs. Besides, it's not a Python exception in the
Debian testing case, it's a segmentation fault in the
underlying GLib code that causes Python to crash.

BTW, Is the current Debian testing really equipped with
Python 2.3.5? It's a very sorry state of affairs if the
testing version of a major Linux release isn't using
Python 2.4, which was released in November 2004.

I can understand why people a leaving stock Debian for
Ubuntu...