On Sat, 06 Dec 2014 11:22:02 +0100
Uli Schlachter <psyc...@znc.in> wrote:
> Am 01.10.2014 um 14:40 schrieb Rob Hoelz:
> > Hello Awesome developers,
>
> Hi Rob,
>
> > I've encountered an interesting behavior in Awesome while playing
> > with coroutines and timers (in an effort to develop a framework
> > where one can write synchronous-looking code that runs in an
> > asynchronous fashion). In short, I am able to make Awesome
> > segfault when using certain Awesome API functions from within a
> > coroutine.
>
> At least here it doesn't segfault, but die from an unprotected Lua
> error. That may not make much of a difference to you, but to me it's
> quite a big one.
>
> > Here's some example code:
> >
> > local sd = require 'sleep-dealer'
> > local notify = require('naughty').notify
> >
> > sd.tuck_in(function()
> > for i = 1, 5 do
> > sd.sleep(1)
> > notify {
> > title = 'Alert!',
> > text = tostring(i),
> > }
> > end
> > end)
>
> Urgh, complicated. Thanks for your simpler example from the other
> mail in this thread:
>
> local co = coroutine.create(function()
> notify { title = 'Alert!', text = 'hello' }
> end)
> coroutine.resume(co)
>
> [...]
> > When naughty.notify is called, a segfault occurs. I've determined
> > that this is because globalconf.L is used in a lot of Lua API calls.
> > Sometimes the Lua state passed into a function is really the state
> > corresponding to a coroutine, so the states don't match and Lua
> > panics.
>
> Yeah, but nothing crashes! :P
>
> > I bring this up here on the mailing list rather than fixing it
> > myself or filing a bug because I wanted to take the pulse of the
> > developer community on whether this is a true bug or if this is
> > doing something with Awesome that it wasn't intended for. If it's
> > the latter, I can let the matter rest; if it's the former, I would
> > be happy to contribute a patch that fixes the problem.
>
> Sorry for not replying sooner. I've been busy. Thanks to you I
> learned something about Lua and I already went ahead and fixed the
> problem. I went through all uses of globalconf.L in awesome and
> checked them:
>
> https://github.com/awesomeWM/awesome/commit/f957764e522253007dbb7ecf5abf869bd38b70e2
>
> https://github.com/awesomeWM/awesome/commit/4cfea189f04e3133c87b36ef26229abaa4ab7eb2
>
> https://github.com/awesomeWM/awesome/commit/d668268591c9854184583fffe58b945f8a9398d9
>
> https://github.com/awesomeWM/awesome/commit/da15317ac2e299f3c1b3833b2c5b198d2d7df5ab
>
> If anyone has a good idea on how to make it harder to introduce this
> kind of error in the future, please speak up. I guess it would at
> least be a good idea to never use globalconf.L directly and instead
> force the code to create a local variable lua_State *L and use that.
> That way, there are less places where globalconf.L is used plus the
> compiler warns if there are two variables with name "L" in scope... I
> guess I'll implement that.
>
> Cheers,
> Uli
Wow, thanks for doing this! As far as ideas for how to prevent this in
the future - would it be possible to remove the lua_State from
globalconf entirely? Or is it absolutely necessary to have in there?
Thanks again,
Rob
--
To unsubscribe, send mail to awesome-devel-unsubscr...@naquadah.org.
