Archaeopteryx Software, Inc.
Take Flight!Search

Wing IDE
About Us
Open Source

 Advanced Search

[wingide-users] non python mainloop

Stephan R.A. Deibel
Mon, 30 Jul 2001 13:05:52 -0400 (EDT)


I'm just going to summarize here; we can work through this in more detail
outside of the mailing list.  Note that in general, longer or very
specific bug reports with attachments might be more appropriate to send to

On Fri, 27 Jul 2001, Markus Oberrauter wrote:
> One change we had to made to our scriptsystem was to set __file__ and
> __name__. Without this information the 1st Stackframe was not shown in
> the debugger.

Yes, without this the debugger doesn't know where to find the code and
thinks the first frame is in the top-level invocation string.  I would
have thought your PyImport() call would set these in the module name space
but if not then it makes sense it's needed.

> 1st question: Is it possible to keep the connection to the debugger
> after loading and execution of the script, or do we have to change the
> way we are using python? I thought that if we were using python in a
> non C++ mainloop it would be ok to execute a python function and then
> jump back to C++.

It would normally keep the connection, just isn't managing to do so for
very long in your case because it fails to establish the connection
initially and eventually crashes, which drops the connection.  In the log
you sent it looks like Run() is called a number of times after you attach
to the process and before it crashes, so retention of the connection seems
to be working across calls, as far as it gets.

> To debug our functions we have to attach again to our application
> (Attach to process).  When we "Pause" the application we will stop at
> the 2nd or 3rd StackFrame. We can set breakpoints in the 1st Frame,
> but the program crashes in "__SetupStackPosition" (see log for
> details) if we set the breakpoint to the Line with "def run():" or if
> we try to StepOut to StackFrame 1 (We can open the sourcefile and set
> breakpoints using the debugger).
> 2nd question: Some ideas why it crashes ? Is it possible that this
> problem is gone when we could keep the connection to the debugger?

The crash is due to the way you're invoking Python.  Looks like the
debugger is getting confused about how many stack frames there are. I'm
fairly sure the same bug or variant thereof is the cause of the failure to
attach initially and the cause of the eventual crash you have in your log.

But no, you shouldn't have to change how you invoke Python. That might
work around the problem but we want to support all possible styles of
invocation so this is a bug we definately will fix.

I'll try to replicate this here and hopefully will have a fix by the time
you are back.


Incidentally, I can't tell for sure from what you sent but you need to
make sure that after Socket and CallbackFunction are being set in your that your mainloop is checking for activity on the socket
with select() and calling the callback function as appropriate.  I'm going
to assume that you are, but if not then this needs fixing before the
process will respond to Pause and placing breakpoints while it's
free-running.  But outside of that kind of responsiveness, the hook is a
non-critical piece of the problem; particularly if you regularly call into
Python code, because the debug socket is always serviced while Python code
is being executed.

- Stephan

Run by Mailman v 2.0.8

Copyright (c) 2000-2002, Archaeopteryx Software, Inc.
Legal Statements