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

  local co = coroutine.create(function()
    notify { title = 'Alert!', text = 'hello' }

> 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:

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.

"In the beginning the Universe was created. This has made a lot of
 people very angry and has been widely regarded as a bad move."

To unsubscribe, send mail to

Reply via email to