[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Question regarding the XML parser binding in PIL
- From: "Sam Roberts" <vieuxtech@...>
- Date: Sat, 6 Dec 2008 13:49:39 -0800
On Sat, Dec 6, 2008 at 10:33 AM, Florian Weimer <firstname.lastname@example.org> wrote:
> * Sam Roberts:
>> Maybe you should just try to do whatever it is you are trying to do,
>> and see if it works?
> Here's an example, to be used with the lua-sqlite3 binding you
> What happens is that the call to exec in the my_sum user defined
> function overwrites the stored L pointer in the db object, which
> becomes dangling after the coroutine has been garbage-collected.
> Running this example should result in a crash (segmentation fault)
> and funny output using valgrind.
OK. A concrete example, and I think I understand your question better.
This is a bug in the sqlite3 binding, of course :-)
I'm no sqlite3 API expert, and only looked at the code briefly, but
the coroutine's L is being passed to sqlite3 as the cbdata, so the
correct L is actually used by exec_callback_wrapper, but the call to
init_callback_usage at line 862 trashes the context.
But, that *every* DB API doesn't set the L pointer to the state valid
"at this time" is probably the larger bug.
If you look at:
You'll see that xpu->L is set when the UD is created, but ALSO, that
it is reset in lxp_parse at every call just before XML_Parse is
called. This guarantees that when XML_Parse calls back, that the L it
finds in xpu will be valid, and if parse is called from multiple
coroutines/different L values (like you cleverly arranged in your
sqlite3 example ;-), it will be OK because L will always point to the
currently executing lua state.
At least, thats my reading of it, and I think that the fact that
luasqlite3 doesn't do this is wrong. Before making a sqlite3 call that
may result in a callback, and thus use of the sqlite3's context's
lua_state, it should set the L pointer to the current context.
YMMV, but this could probably be done in the checkdb() macro.
>> Btw, if you think this is an issue for something like user-defined
>> functions in sqlite, maybe try reading the sqlite bindings, the docs
>> indicate they do user-defined functions:
> Thanks for the pointer, but I was writing the binding as an exercise,
> to become familiar with Lua's C API.
Understood. I thought sqlite3 would be a real-world example. Turns out
to be an anti-example. :-)