Bug 668875

can you please check if there is a sosreport.tar.xz where this crash is saved? should be somewhere in /var/spool/abrt/. If you find it please check the size. Thank you.

*** Bug 672206 has been marked as a duplicate of this bug. ***

The reporting is done two HTTP transactions: first, we create the case per se, and then we upload the attachment.

I would hazard to guess that this bug happens when the first operation succeeds, but second one fails. Here is the relevant abrt code:


    abrt_post_string(case_state, case_url.c_str(), "application/xml", case_data);
^^^^^^^^^^^^^^^^^^^^ case creation transaction
    char *case_location = find_header_in_abrt_post_state(case_state, "Location:");
    switch (case_state->http_resp_code)
    {
    ...error handling cases...
    case 200:
    case 201:
        if (!case_location) {
            ...error handling...
            break;
        }
            
        string atch_url = concat_path_file(case_location, "/attachments");
        abrt_post_state *atch_state;
 redirect_attach:
        atch_state = new_abrt_post_state(...);
        atch_state->username = username;
        atch_state->password = password;
        abrt_post_file_as_form(atch_state, atch_url.c_str(), "application/binary", report_file_name);
^^^^^^^^^^^^^^^^^^^^ attachment transaction
        char *atch_location = find_header_in_abrt_post_state(atch_state, "Location:");
        switch (atch_state->http_resp_code)
        {
        ...error handling cases...
        case 200:
        case 201:
            retval = xasprintf("Case created: %s", /*body,*/ case_location);
        } /* switch (attach HTTP code) */
        free_abrt_post_state(atch_state);
    } /* switch (case HTTP code) */

    free_abrt_post_state(case_state);
    free(allocated);
    return retval;
}


Unfortunately, in this case all useful debugging information remains on client side. If possible, in such cases we need to ask the user the following questions:

"how big is the attachment?",

"what error message abrt showed?", "can you retry upload?"

"please show output of ls -l /var/spool/abrt/RELEVANT_CRASH_DUMP_DIR, or better, tar up and email /var/spool/abrt/RELEVANT_CRASH_DUMP_DIR to us if it is not too big"

BTW, how often does this happen? 1% of cases? 10%? 50%?

I don't have a number yet, hopefully Yogesh can comment on that and the user interaction.

I think there are two limits to consider here: the attachment limit on the server, and the crash size limit. On my RHEL 6 box, the ABRT crash size limit is 1 GB, while the server's limit is 50 MB. If 1 GB is indeed the client side limit, then I think this is entirely on the server to fix... (which we can handle).

abrt crash size limit is indeed 1 GB by default, but it should not be in play here: abrt will simply delete old dump directories until it brings total size down to specified size.

IOW: the limit does not affect individual files. If coredump inside dump dir is bigger than 1 GB, the whole dump dir will be deleted, therefore it cannot be reported, therefore in this case it can't result in "case without attachment" effect.

IOW2: if you see a case without attachment, then client which submitted it definitely had some dump dir, and attempted to send it. The information why sending attachment failed is, unfortunately, on the client side.

One possible improvement which springs to mind is to add information about attachment and/or its components in the "description" field. Something like this:

 abrt version: 1.1.13
 architecture: i686
 cmdline: sleep 5m
 comment: test c/c++
 component: coreutils
 ...
 time: 1290026594
 uid: 500
+sosreport.tar.xz: 241560 bytes
+coredump: 290816 bytes

backtrace
-----
...


This way, if you see, say, huge coredumps in most of such attachment-less cases, it will be possible to at least guess that the problem is likely caused by huge uploads being not reliable or aborted by user.

I think that's a good improvement.

Another suggestion (or maybe just something to test), is to confirm that whenever the attachment is rejected by the server, the message is returned, and is useful.

Created attachment 476800 [details]
Proposed patch

in bz/rhts description, list attachments and their sizes

Applied to git and tested.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0619.html