[wingide-users] non python mainloopStephan R.A. Deibel email@example.com
Mon, 30 Jul 2001 13:05:52 -0400 (EDT)
Hi, 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 firstname.lastname@example.org. 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 _wingshooks.py 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.