[Ur] Almost 100% bug in request() algorithm
Sergey Mironov
grrwlf at gmail.com
Sun Jun 15 17:15:27 EDT 2014
That is how I fixed the problem. I didn't check all the consequences
of this fix.
2014-06-16 1:10 GMT+04:00 Sergey Mironov <grrwlf at gmail.com>:
> Hi! I've found a bug while debugging my FFI code!
>
> Look at the request() from request.c. It contains the following pattern:
>
> ...
> }
> else if (fk == FATAL) {
> log_error(logger_data, "Fatal error: %s\n", uw_error_message(ctx));
>
> if (uw_get_app(ctx)->on_error && !had_error) {
> had_error = 1;
> strcpy(errmsg, uw_error_message(ctx));
> } else {
> uw_reset_keep_error_message(ctx);
> on_failure(ctx);
> uw_write_header(ctx, "Content-type: text/html\r\n");
> uw_write(ctx, "<html><head><title>Fatal Error</title></head><body>");
> uw_write(ctx, "Fatal error: ");
> uw_write(ctx, uw_error_message(ctx));
> uw_write(ctx, "\n</body></html>");
>
> try_rollback(ctx, 0, logger_data, log_error);
>
> return FAILED;
> }
> } else {
> ...
>
> Note, that try_rollback() is executed _after_
> uw_reset_keep_error_message(). It is an error because reset will
> assign ctx->used_transactionals to 0 and prevent FFI cleanup handlers
> from working! Let me suggest calling try_rollback() before reset.
> Please, check!
>
> Regards,
> Sergey
>
> PS
> I didn't update the compiler up to the latest version yet.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1_of_1_Call_try_rollback_before_resetting_the_context.patch
Type: text/x-patch
Size: 2851 bytes
Desc: not available
URL: <http://www.impredicative.com/pipermail/ur/attachments/20140616/2263491f/attachment.bin>
More information about the Ur
mailing list