ABRT not connecting to Bugzilla nor the remote servers to analyse Core Dumps

[Thetargos]

Hi all, has anyone noticed ABRT not being able to connect to Bugzilla or the remote Core Dump analysis server? Since my upgrade during the beta phase of F15 I have been unable to file bug reports from ABRT's traces, nor has it offered me the option to file bugs to bugzilla. What it does, however, is offer me to analyse the Core Dump and backtrace of the crash using either the remote server or locally with GDB. Needless to say I'm clueless in GDB, and it requires a LOT of debug symbols found in the corresponding debug packages. But trying to use the remote analysis server always results in a message of the server being busy and to try again later. IIRC the last time I was able to file a bug through ABRT was in 13, has anyone been able to do so in 15?

Originally Posted by Thetargos

Hi all, has anyone noticed ABRT not being able to connect to Bugzilla or the remote Core Dump analysis server? Since my upgrade during the beta phase of F15 I have been unable to file bug reports from ABRT's traces, nor has it offered me the option to file bugs to bugzilla. What it does, however, is offer me to analyse the Core Dump and backtrace of the crash using either the remote server or locally with GDB. Needless to say I'm clueless in GDB, and it requires a LOT of debug symbols found in the corresponding debug packages. But trying to use the remote analysis server always results in a message of the server being busy and to try again later. IIRC the last time I was able to file a bug through ABRT was in 13, has anyone been able to do so in 15?

yeah i have, i think AdamW did explain why it wasnt working a month ago i think. i just cant remember the threads name he mentioned it in. i think its something to do with the ABRT servers or something like that. but best way to file a Bug is to file it via the redhat bugzilla page itself

[sidebrnz]

Better yet, you can add the comments to the bug I opened for this: https://bugzilla.redhat.com/show_bug.cgi?id=712644

[Thetargos]

Done, thanks.

[AdamW]

the 'local via gdb' option doesn't require any knowledge, abrt does the analysis itself - the drawback is the installation of lots of debuginfo packages. But it should work after you allow it to install all those packages, and then allow you to report the bug to Bugzilla. Can you check that?

The retrace server often fails because it's full; it's running on a very low resourced machine right now, it needs to be moved into the Fedora infrastructure proper to resolve the load issues.

[sidebrnz]

The first time this happened, it downloaded and installed all of the debuginfo packages before trying to connect to the server. Why did you think I skipped that step, or that abrt would have even tried to connect if I hadn't? And, it failed again later, even though all of those packages were installed before the crash.

[AdamW]

I'm having trouble parsing the above, but note there's at least two 'servers' involved here: the bug report goes to a server, bugzilla.redhat.com, the Fedora Bugzilla. The 'abrt retrace server' is a *separate* server which can optionally carry out the bit of the process which involves getting a complete backtrace of the crash; getting the backtrace can also be done locally via gdb. That's the choice abrt offers you.

[sidebrnz]

OK. The first time the archive mounter crashed and abrt came up, it told me that it needed to download and install the debuginfo packages, so I told it to go ahead. After that was done, it offered me a choice between bugzilla and tracker. As I had no idea what "tracker" refers to (and still don't) I told it to use bugzilla, as I have an account there. It failed, with the error message I quoted above. Later, I tried archive mounter again with Firefox showing a bugzilla page with me logged in and it failed again with the exact same error message, although naturally it didn't need to install the debuginfo packages again.

[Thetargos]

So basically you have to perform the local analysis (GDB dump) with all the debuginfo packages involved before you can send the core dump to the servers? What's with the error message, then? About the severs being busy and unavailable, I think a more inofrmative message would be in order in such cases. I remember once openin the help for ABRT, but it wasn't too informative, may be I should give it another try and see if some of this is documented there

[sidebrnz]

Yes, abrt does the local analysis before sending the core dump. No, the error message (as quoted in my bug report at bugzilla) has nothing to do with the servers being busy:

Cannot login. Check Edit->Plugins->Bugzilla and /etc/abrt/plugins/Bugzilla.conf. Server said: RPC failed at server. The username or password you entered is not valid.

The server may or may not be busy, but if so, the error message I've received says nothing about it. (Looking back, I see that I'd never specified just what error message I'm receiving; sorry about that.)

[AdamW]

okay, so definitely sounds like a problem communicating with Bugzilla. Looks like there's a bug filed for this already:

https://bugzilla.redhat.com/show_bug.cgi?id=712644

I'll make sure the ABRT team is on it. thanks!

[Thetargos]

Originally Posted by sidebrnz

Yes, abrt does the local analysis before sending the core dump.

I thought the remote dump servers were just to avoid you having to download all the debuginfo packages... I may have misunderstood something or it simply is not clear enough.

[RahulSundaram]

Originally Posted by Thetargos

I thought the remote dump servers were just to avoid you having to download all the debuginfo packages... I may have misunderstood something or it simply is not clear enough.

ABRT has two choices. One to do the analysis on the server side and the other to download the debuginfo locally. If the retrace server is busy, try the other choice.

[Thetargos]

My point being that every time I tried to use ABRT's remote dump service, it is busy, regardless of hour of the day or day of the week.

[RahulSundaram]

Hi

Adamw has already addressed that point