wxlua-users Mailing List for wxLua

On Tue, Nov 25, 2008 at 12:19 PM, arpin <ar...@ki...> wrote:
> arpin <arpin@...> writes:
>
>>
>> If one code the following function
>>
>>     --wxString BugsGridTable::GetRowLabelValue( int col )
>>     gridtable.GetRowLabelValue = function( self, row )
>>         error("unexpected row");
>>         return "x"..row;
>>     end
>>
> This occurs when you are in the debugger it does not happen if just run the
> program. I got so used to have the debugger behave that I ignore this
> important aspect of the problem.

It is interesting that it only happens in the debugger. In the past
I've only had problems that for some reason won't occur in the
debugger and those are particularly difficult to diagnose.

Lets just chalk it up to a bad interaction of the long jump with the
debugger. However, I do appreciate the reports of things not working
as expected.

Regards,
    John

arpin <arpin@...> writes:

> 
> If one code the following function
> 
>     --wxString BugsGridTable::GetRowLabelValue( int col )
>     gridtable.GetRowLabelValue = function( self, row )
>         error("unexpected row");
>         return "x"..row;
>     end
> 
This occurs when you are in the debugger it does not happen if just run the 
program. I got so used to have the debugger behave that I ignore this 
important aspect of the problem.

Sorry 

Andre

On Tue, Nov 25, 2008 at 8:36 AM, arpin <ar...@ki...> wrote:
> If one code the following function
>
>    --wxString BugsGridTable::GetRowLabelValue( int col )
>    gridtable.GetRowLabelValue = function( self, row )
>        error("unexpected row");
>        return "x"..row;
>    end
>
> then the program crash instead of reporting the error

This is the same problem as your last report. You're in a virtual C++
function handing the call to your Lua function and apparently the long
jump out of the C++ function corrupts the stack (I assume).

I will try to debug this, but I don't have very high hopes since I
imagine that I would have to override the error() function, save the
values, set a flag, and then call it later when it is safe, but I'd
still have to return "something" from the C++ function just to get out
of it...

I'd use a print statement and handle the error as gracefully as
possible so the program can continue.

Regards,
    John

On Tue, Nov 25, 2008 at 8:04 AM, arpin <ar...@ki...> wrote:
> How to reproduce:
>
> change
>    gridtable.GetTypeName = function( self, row, col )
>        if col == Col_Id or col == Col_Priority then
>            return wx.wxGRID_VALUE_NUMBER
>
> to
>    gridtable.GetTypeName = function( self, row, col )
>        if col == Col_Id or col == Col_Priority then
>            return wx.wxEmptyString
>
> I realize that this is not a type but this is purely to demonstrate the
> problem I found it in a more complex situation.
>
> Returning '' will properly report the error it seems to be related to
> wx.wxEmptyString.
>
> Hope someone can figure out how to fix the problem

This is always going to be a problem I imagine. wxLua merely wraps
wxWidgets and doesn't rewrite it. Therefore, when you return nil, but
a string is expected, a lua_error is thrown (actually a long jump) and
the C++ stack is corrupted since we're in a virtual C++ function
handling your Lua function. A good fix for this would take a lot of
work and make updating to new versions of wxWidgets very painful since
they would have to be done by hand. You do get an error stating that a
string was expected right? The best I can say is take heed of the
error message and return a string!

Regards,
    John

On Tue, Nov 25, 2008 at 3:36 AM, Éjjeli Őrjárat <ejj...@gm...> wrote:
> Thanks for the fast reply, I have already checked wxTaskbarIcon, but there
> is just a PopupMenu(), which shown a menu, not a warning message. I couldn't
> find the wxPopupWindow in the reference manual, is that really implemented
> and exists, or just I was blind? (I am using 2.8.7.0 version)

You're right, I forgot to add wxPopupWindow. Try wxMiniFrame, which
might even be better since you'll get a close button too. I'd use a
wxTimer for the delay, but be sure to connect to the EVT_CLOSE_WINDOW
event so that if the user closes it you can ignore the timer event.

Regards,
    John

If one code the following function

    --wxString BugsGridTable::GetRowLabelValue( int col )
    gridtable.GetRowLabelValue = function( self, row )
        error("unexpected row");
        return "x"..row;
    end

then the program crash instead of reporting the error

Andre

How to reproduce:

change
    gridtable.GetTypeName = function( self, row, col )
        if col == Col_Id or col == Col_Priority then
            return wx.wxGRID_VALUE_NUMBER

to 
    gridtable.GetTypeName = function( self, row, col )
        if col == Col_Id or col == Col_Priority then
            return wx.wxEmptyString

I realize that this is not a type but this is purely to demonstrate the 
problem I found it in a more complex situation.

Returning '' will properly report the error it seems to be related to 
wx.wxEmptyString.

Hope someone can figure out how to fix the problem

Andre

Thanks for the fast reply, I have already checked wxTaskbarIcon, but there
is just a PopupMenu(), which shown a menu, not a warning message. I couldn't
find the wxPopupWindow in the reference manual, is that really implemented
and exists, or just I was blind? (I am using 2.8.7.0 version)
Greets: Attila

On Mon, Nov 24, 2008 at 11:23 AM, Raúl Huertas <rax...@ho...> wrote:
> Here is more info with lua builded for debug:
>
> (idb) file dist/Release/IntelSDK-Linux-x86/luaexample
...
> Program received signal SIGSEGV
> free () in /lib/tls/i686/cmov/libc-2.7.so
> (idb) bt
> #0  0xb7cdc4ac in free () in /lib/tls/i686/cmov/libc-2.7.so
> #1  0x08060ab2 in l_alloc (ud=0x8054d7f, ptr=0x0, osize=3077778016,
> nsize=28) at lauxlib.c:631
> #2  0x08054d7f in luaM_realloc_ (L=0x8243d38, block=0x80aa008,
> osize=134914056, nsize=134593111) at lmem.c:79
> #3  0x0805ba57 in luaH_free (L=0x0, t=0x8243d38) at ltable.c:376
> #4  0x080549be in luaC_freeall (L=0x0) at lgc.c:487
> #5  0x0805a6d4 in lua_close (L=0xb7db7ff4) at lstate.c:212
> #6  0x08049d5a in main () in
> /home/raulhuertas/Documentos/Proyectos/LuaExample/dist/Release/IntelSDK-Linux-x86/luaexample
>
> I will now compile wxlua for debug

Let me know the result of that. The above doesn't seem to show that
wxLua is misbehaving, but on the other hand Lua itself shouldn't have
problems like this nor should libc as you mention in your last post.

You can also try running $ldd luaexample and $ldd wx.so to make sure
that both your program and the wxLua lib are linked to the same Lua
lib.

By the way, on Linux you might as well always compile in debug mode,
unless you're going to distribute your program or actually  require
speed.

Regards,
    John