Thank you for report bug. Run please under root:

service abrtd stop
abrtd -dvvv

try to reproduce bug again and if you success send me whole output from abrtd -dvvv

I can't reply directly with gmail in bugzilla?

This is what I sent, I don't know where that reply went, but it appears to be not here:



>try to reproduce bug again


How would I do that? Make something crash?

(In reply to comment #2)
> I can't reply directly with gmail in bugzilla?
> 
> This is what I sent, I don't know where that reply went, but it appears to be
> not here:
> 
> 
> 
> >try to reproduce bug again
> 
> 
> How would I do that? Make something crash?    

No, this bug in abrt shows up when you tried to report bug. So just do what I said in comment 1 and try to again report bug through abrt.

abrt -dvvv show a lot of debuging information.

Created attachment 414545 [details]
what I see in terminal

Is this what you want?

Or did you need to add the comment that it added to already existing bug report?

Yes that's it. Unfortunately this will be tough to reproduce :-/. What I see right now is that you filled a bug correctly, but with unknown reason bugzilla server responses with bad code. 

Here is your bug
https://bugzilla.redhat.com/show_bug.cgi?id=592927

I could give it another try. Then this bug first appeared I did not know that you had to enter your email and password.

I ran it one more time, but I can't find the option to "forget" my account details. Any suggestions?

Login and password are stored in gnome-keyring, so install *seahorse* and look into folder called password in seahorse and there you will see abrt:Bugzilla. Erase it and abrt should you ask for a new login and passwd.

I deleted the password and run everything one more time. I could not reproduce the crash without giving it my account details like I did the first time.

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

Apparently "XML-RPC Fault(-504): HTTP response code is 502, not 200" thing happens here:

void throw_xml_fault(xmlrpc_env *env)
{
    std::string errmsg = ssprintf("XML-RPC Fault(%d): %s", env->fault_code, env->fault_string);
    xmlrpc_env_clean(env); // this is needed ONLY if fault_occurred
    xmlrpc_env_init(env); // just in case user catches ex and _continues_ to use env
    error_msg("%s", errmsg.c_str()); // show error in daemon log
    throw CABRTException(EXCEP_PLUGIN, errmsg.c_str());
}

One thing we can do here is to look at HTTP code and if it's 502 Bad Gateway, 503 Service Unavailable, or 504 Gateway Timeout, then instead of rude message like:

Reporting via 'Bugzilla' was not successful: XML-RPC Fault(-504): HTTP response
code is 502, not 200

we can say something like:

Reporting via 'Bugzilla' was not successful: server is down or overloaded (HTTP response code: 502)

which is much more clear.

Adding to the last comment: apart from 502,503,504 codes, "500 Internal Server Error" also looks likely to indicate purely server-side problem.
"501 Not Implemented" and "505 HTTP Version Not Supported" indicate not a server problem, but a bug in server/client interaction, and should not be treated as "server down".

This sounds like a fine solution.

I think it would be fine even if it just told clearly what was wrong:
Reporting via 'Bugzilla' was not successful: Server responded 502 Bad Gateway

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

reopening - there is no indication this has been fixed

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

The part: "HTTP response code is 502, not 200" comes from xmlrpc-c, ABRT just shows whatever error msg it gets from it. It seems like this is the only error path where xmlrpc-c doesn't use the pre-formatted error messages, maybe it should be fixed to use the same approach even in this case?

from xmlrpc-c - /lib/curl_transport/curltransaction.c: 840

if (res != CURLE_OK)
            xmlrpc_env_set_fault_formatted(
                envP, XMLRPC_INTERNAL_ERROR,.
                "Curl performed the HTTP POST request, but was "
                "unable to say what the HTTP result code was.  "
                "curl_easy_getinfo(CURLINFO_HTTP_CODE) says: %s",.
                curlTransactionP->curlError);
        else {
            if (http_result != 200)
                xmlrpc_env_set_fault_formatted(
                    envP, XMLRPC_NETWORK_ERROR,
                    "HTTP response code is %ld, not 200",
                    http_result);
        }


-> reassigning to xmlrpc-c

any ideas how this information can be retrieved from curl? xmlrpc-c uses curl_easy_getinfo() to get status information but I do not see a CURLINFO_* option which returns the textual status message.

There is no such information stored in the curl easy handle.  You need to use CURLOPT_HEADERFUNCTION to catch the status line sent by server.  Alternatively, you can translate the integral status codes to human-readable messages.

Created attachment 574522 [details]
an example reading the status line (tested on HTTP only)

libcurl now puts the reason phrase from HTTP status line directly into the error buffer in most of the cases:

http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTERRORBUFFER

See bug 676596 for details.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Please report this to upstream.