Hi
Thanks for the reply. >> First, what do you mean by Debug Mode? Are you debugging the Visual C++ >> application or the Lua script? By ‘Debug Mode’ I mean that I am running my Visual C++ application under the Visual C++ debugger. My application has its own editor/debugger for running Lua scripts. If I run the iup dialog script from my previous post, and I run the script in (Visual C++) debug mode, either using my app’s Lua debugger or running it normally, it will close the application. However, if I create a Release build of my application, the same script will not close my application, whether I run it under the Lua debugger or not. >> Second, you have a very peculiar configuration as we speak previously I don’t know what the normal setup is. Our setup has worked well for us up to now. When a user runs a script (either under the Lua debugger or not), we call luaL_newstate() to create a new Lua state for that script. To run the script, we call lua_load to load it, and lua_pcallk to execute it. When lua_pcallk returns, we call lua_close to close the Lua state. That’s pretty much what we’ve done for some considerable time now (albeit with an older version of Lua and IUP) and it’s worked well with no significant problems. We like this way of working. It means that different scripts can’t accidentally or deliberately interfere with one another. It means that every script executes in a clear, well-known environment. And there are other benefits. What else is different about the way we do things? The most obvious is that we use dynamic linking to load the Lua DLLs. We did that because it seemed to keep lines of dependencies cleaner and more explicit. It has worked fine for us up to now (some years now) with no problems – running scripts of all types using multiple Lua modules apart from, or as well as, IUP. One change was discussed in an earlier email on the Lua forum. Previously we used to auto-open IUP within the C++ code, and then manually close IUP at the end. On advice from you, we no longer do that. The user now has to call “require( "iuplua" )” at the start of the script. The problem we then had was that if an error occurred, and the script returned without closing IUP, IUP windows would be left and the application would crash when you closed lua. So we now we execute this string just before closing the Lua state: “if iup and iup.Close then iup.Close() end”. That seems to work well and solves most of our problems. I don’t think the way we close IUP and close a Lua state has anything to do with the problem, because if I skip both (don’t close either of them) the application still shuts down. I don’t know if it’s a clue, but if I modify the script to add something (a message box) say, after the call to “dlg:destroy()”, the message box code never gets called if I call dlg:destroy. What happens is that my call to lua_pcallk returns at that point – and with a 0 return code which seems surprising. Given that it hadn’t finished executing all of the code, I would have expected a non-zero return code. >> Can you send us the call stack at the crash I think I may have misled you by saying that the application crashes. What actually happens is that the application closes. It actually closes in a fairly orderly way. Mine is an MFC application, and the CWinApp’s ExitInstance function is called which is what happens in a normal orderly closedown. This suggests that the main message loop has received a WM_QUIT message or something like that (does IUP ever call PostQuitMessage?). I get some errors at this point – but they are my own program errors which are produced because the code didn’t expect to have the application die so suddenly like that. So there’s no useful information to be gleaned from the call stack. It’s usually sitting just below the main message loop at this point. Does any of that suggest anything? Simon From: Antonio Scuri [mailto:[email protected]] Sent: 19 June 2019 11:52 AM To: IUP discussion list. Subject: Re: [Iup-users] IUP crash in Debug Mode Hi Simon, I can't see anything wrong with your script. First, what do you mean by Debug Mode? Are you debugging the Visual C++ application or the Lua script? When not in debug mode it works? Second, you have a very peculiar configuration as we speak previously. Maybe you will have to build IUP with debug information so we can see where it is crashing. Can you send us the call stack at the crash (even using IUP without debug info)? Best, Scuri Em ter, 18 de jun de 2019 às 13:53, Simon Orde <[email protected]> escreveu: Hi – I’m using Lua 5.3 and IUP 3.26 to run embedded Lua scripts in my Visual C++ 2017 application, and I’m having problems with IUP dialogs which cause my application to crash – but only in debug mode. For example, the following script will cause my application to crash if (and only if) you click the OK button: require( "iuplua" ) btn = iup.button { name="ok", title="OK", action = function() return iup.CLOSE end } dlg = iup.dialog{btn; title="Test dialog"} dlg:show() iup.MainLoop() dlg:destroy() The crash actually occurs in the dlg:destroy() call. If I comment out “return iup.CLOSE” it does not crash (and pressing OK doesn’t close the dialog either ). If I close the dialog by clicking on the cross in the top-right corner it does not crash. If I don’t comment out “return iup.CLOSE” but instead comment out dlg:destroy() it will crash my application when the script ends (but only if I’ve clicked the OK button). I know that iup.GetParams is implemented using an iup dialog, but that seems to work fine for me. For example, this code does not crash even if I click the OK button to close the dialog: require("iuplua") iTest = 1 iup.GetParam("Options", nil, "Test %i\n", iTest) Presumably iup.GetParam must be doing something very similar to what I’m trying to do. But it is doing it in a way that does not crash my app. Anyone got any thoughts on what’s going wrong? All help much appreciated. Simon _______________________________________________ Iup-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iup-users
_______________________________________________ Iup-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iup-users
