[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