Some wxpython questions about gtk wxPython Unicode 2.8.1.1

wxPython Users
1

Hello NG,

Two questions:

  1) If a "Segmentation fault (core dumped)" happend, it is a crash, isn't it?
  
      So after that assertions, a segmentation fault follows.
        
        ** (python:5936): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          dann kommt segmentation fault

        wie segmentatoin fault, genauere info, was verursacth dies? (wxwidgets forum, wxpython mailing list, wxwidgets newsgroup)

          ** (python:12488): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

          ** (python:12542): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

      a) How can I trace back, what a segmentation fault caused?
      
      b) What does that mean (gail_menu_item_ref_child: assertion `(i >= 0)' failed)?
      
      c) What do the numbers 12542 and 12488? Could this numbers be useful?
      
      d) What is the best way to debug or isolate this to a certatin piece of code this?

  2) GTK Accessibility Module initialized:
      Is this message necessary?

Many thanks in advance!

···

--
Franz Steinhaeusler

2

Additional Annotation:
I have forgotten to say that the same program runt
without any of such error messages perfectly
on Windows XP, wxPython 2.8.1.1 Unicode.

···

On Sun, 04 Feb 2007 11:47:08 +0100, Franz Steinhäusler <franz.steinhaeusler@gmx.at> wrote:

Hello NG,

Two questions:
[Linux ubuntu issues]

--

Franz Steinhaeusler

3

Franz Steinhäusler wrote:

Hello NG,

I just answered most of this on wx-dev, will do so again here for the archive's sake.

Two questions:

  1) If a "Segmentation fault (core dumped)" happend, it is a crash, isn't it?

Yes, more or less. It is the program double-checking certain things itself and aborting itself if the condition fails.

        So after that assertions, a segmentation fault follows.
                ** (python:5936): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          dann kommt segmentation fault

        wie segmentatoin fault, genauere info, was verursacth dies? (wxwidgets forum, wxpython mailing list, wxwidgets newsgroup)

          ** (python:12488): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

          ** (python:12542): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

            a) How can I trace back, what a segmentation fault caused?

If there is enough debug info present then loading the core file into gdb and running backtrace may give some clues.

            b) What does that mean (gail_menu_item_ref_child: assertion `(i >= 0)' failed)?

In the gail_menu_item_ref_child function there is an assert statement checking that the variable i is >=0, but it is failing. I assume from the function name that it is a reference counting error, and that something is getting decref'd too many times.

            c) What do the numbers 12542 and 12488? Could this numbers be useful?

No, they are just the process ID.

            d) What is the best way to debug or isolate this to a certatin piece of code this?

Go through a few iterations of disabling portions of your code and retesting until you are able to narrow down the thing that is causing the problem.

  2) GTK Accessibility Module initialized: Is this message necessary?

Not sure. Is it being printed to the console? It is probably coming from gail itself, so it would be up to gail to suppress it.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

Franz Steinhäusler wrote:

Hello NG,

I just answered most of this on wx-dev, will do so again here for the
archive's sake.

Hello Robin,

thank you for your reply.

Two questions:

  1) If a "Segmentation fault (core dumped)" happend, it is a crash, isn't it?

Yes, more or less. It is the program double-checking certain things
itself and aborting itself if the condition fails.

      So after that assertions, a segmentation fault follows.
        
        ** (python:5936): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          dann kommt segmentation fault

        wie segmentatoin fault, genauere info, was verursacth dies? (wxwidgets forum, wxpython mailing list, wxwidgets newsgroup)

          ** (python:12488): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

          ** (python:12542): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

      a) How can I trace back, what a segmentation fault caused?

If there is enough debug info present then loading the core file into
gdb and running backtrace may give some clues.

Hm, quite difficult? :slight_smile:
How do I know, that there is enoug debug info?
How do I load the core file (what is this, how can I get/produce this?)

Backtrace: is this an internal command in gdb?

      b) What does that mean (gail_menu_item_ref_child: assertion `(i >= 0)' failed)?

In the gail_menu_item_ref_child function there is an assert statement
checking that the variable i is >=0, but it is failing. I assume from
the function name that it is a reference counting error, and that
something is getting decref'd too many times.

Aha, so there is something unclean in the menu procedure in my program.

      c) What do the numbers 12542 and 12488? Could this numbers be useful?

No, they are just the process ID.

      d) What is the best way to debug or isolate this to a certatin piece of code this?

Go through a few iterations of disabling portions of your code and
retesting until you are able to narrow down the thing that is causing
the problem.

Ah, I see, I most of the time try to isoltat in that way the problem.

  2) GTK Accessibility Module initialized:
      Is this message necessary?

Not sure. Is it being printed to the console? It is probably coming
from gail itself, so it would be up to gail to suppress it.

Ah, yes it is in the console, and it is printed always directly after the
startup of a wx program.

···

On Mon, 05 Feb 2007 12:58:20 -0800, Robin Dunn <robin@alldunn.com> wrote:

--

Franz Steinhaeusler

5

Franz Steinhaeusler wrote:

Franz Steinhäusler wrote:

Hello NG,

I just answered most of this on wx-dev, will do so again here for the archive's sake.

Hello Robin,

thank you for your reply.

Two questions:

  1) If a "Segmentation fault (core dumped)" happend, it is a crash, isn't it?

Yes, more or less. It is the program double-checking certain things itself and aborting itself if the condition fails.

        So after that assertions, a segmentation fault follows.
                ** (python:5936): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          dann kommt segmentation fault

        wie segmentatoin fault, genauere info, was verursacth dies? (wxwidgets forum, wxpython mailing list, wxwidgets newsgroup)

          ** (python:12488): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

          ** (python:12542): CRITICAL **: gail_menu_item_ref_child: assertion `(i >= 0)' failed
          Segmentation fault (core dumped)

            a) How can I trace back, what a segmentation fault caused?

If there is enough debug info present then loading the core file into gdb and running backtrace may give some clues.

Hm, quite difficult? :slight_smile:
How do I know, that there is enoug debug info?

When you do the backtrace there will either be lots of function name info from the gtk layers on the stack, or there won't be. On Ubuntu there are libgtk*-dbg packages available that contain the debug info. I don't know if the other distros have similar packages or not. You may also want to have a debug version of Python available too so the stack dump can give meaningful info in those layers of the stack too. I have a custom build of Python installed in /opt/python that I use when I want to use the debugger.

How do I load the core file (what is this, how can I get/produce this?)

The core file is a snapshot of the program's memory when the crash happened. The debugger can load it and you end up with the debugger in nearly the same state as if you had started the program in the debugger to begin with and run to the point of the crash. If you look in the current working dir of the program there is probably a file named core, or core.[process id]. You just need to run "gdb /path/to/python -c /path/to/corefile"

Backtrace: is this an internal command in gdb?

Yes. It can be abbreviated "bt"

            b) What does that mean (gail_menu_item_ref_child: assertion `(i >= 0)' failed)?

In the gail_menu_item_ref_child function there is an assert statement checking that the variable i is >=0, but it is failing. I assume from the function name that it is a reference counting error, and that something is getting decref'd too many times.

Aha, so there is something unclean in the menu procedure in my program.

That would be my guess.

···

On Mon, 05 Feb 2007 12:58:20 -0800, Robin Dunn <robin@alldunn.com> wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

6

Hello Robin,

thank you again for your detaild answer.

I first try the "old" way eliminating code, comment out, print, ...
Maybe I have luck already before, before I have to go the hard
way and step deep inside of this (still new area on linux). :slight_smile:

···

On Tue, 06 Feb 2007 16:36:48 -0800, Robin Dunn <robin@alldunn.com> wrote:

Franz Steinhaeusler wrote:
[...]

      
      a) How can I trace back, what a segmentation fault caused?

If there is enough debug info present then loading the core file into
gdb and running backtrace may give some clues.

Hm, quite difficult? :slight_smile:
How do I know, that there is enoug debug info?

[...]

How do I load the core file (what is this, how can I get/produce this?)

The core file is a snapshot of the program's memory when the crash
happened. The debugger can load it and you end up with the debugger in
nearly the same state as if you had started the program in the debugger
to begin with and run to the point of the crash. If you look in the
current working dir of the program there is probably a file named core,
or core.[process id]. You just need to run "gdb /path/to/python -c
/path/to/corefile"
[...]

--

Franz Steinhaeusler