lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Em sex., 26 de fev. de 2021 às 22:25, Sean Conner <sean@conman.org> escreveu:
It was thus said that the Great Ranier Vilela once stated:
> Em qua., 24 de fev. de 2021 às 23:17, Ranier Vilela <ranier.vf@gmail.com>
> escreveu:
>
> > Em qua., 24 de fev. de 2021 às 22:54, Sean Conner <sean@conman.org>
> > escreveu:
> >
> >> > I have a bug reading an invalid pointer, in an adjacent library, which
> >> I'm
> >> > not sure is caused by Lua gc.
> >>
> >>   It may be an issue over who owns the memory for the userdata, but
> >> without
> >> knowing the exact error, it's hard to say.
> >>
> > Lua owns the pointer.
> > The code is run many times, then magically the "feeefeeefeeefeee" pointer
> > appears.
> > I need to make sure that there are no mistakes part of Lua C api.
> >
> Regarding the problem, I can already say with certainty that it is the case
> of:
> user-after-free
> https://stackoverflow.com/questions/2436020/detecting-use-after-free-on-windows-dangling-pointers

  I don't use Windows so I can't check this, but it sounds like the
following might be happening:

        * There is a userdata on the stack (either as a parameter to the C
          based function, or via calling a Lua function from C).
Yes correct.


        * You grab the pointer to the user data.
Again, that's right.


        * You cleanup the stack, thus removing the stack entry with the
          userdata.
I'm not sure. It has occurred and corrects this type of problem before. Now it looks different.
No Lua code releases the "userdata" variable.
No C code releases the variable, at least intentionally.
Only a few lua_pop remain, carefully placed, following your recommendations.


        * A GC is triggered and the userdata has no hard reference in the
          Lua state, so the __gc() method is called.
I'm not sure.
Put "breakpoints" and printfs on all relevant __gc, none were triggered.
 

        * The pointer is then used, thus triggering the issue.
This case looks different, the affected pointer is part of a structure (the userdata), which looks intact.
It seems that the adjacent library itself is releasing it.
But I still haven't managed to debug it correctly.

When I go to the DrMemory tool, which could help,
it stops and complains about the Lua C code, even before executing the main routines.
DrMemory already pointed out some real problems on other occasions.
 
regards,
Ranier Vilela