Malone connection generates an "Internal Server Error" on large file attachments

I can confirm this one too... on apport 0.95

Malone hackers, is there a particular limit on the file size? Should I clip this in apport?

Is this still happening? I haven't see any OOPSes related to this lately.

Bjorn yes it is.

Bjorn, this seems to be the bug that kiko and niemeyer have been investigating lately. The one that about app server dying. I'm subscribing both kiko and niemeyer so they can give us more info about the debugging done last week where they sucessfully reproduced this bug.

This issue was also discussed during out LP production meeting: http://pastebin.ubuntu.com/55691/. Tom Berger will discuss with the Bugs team if it's possible to find a quick workaround.

Hi all,
 I have been effected by this as well, hence have had an aversion to file crasher bugs, and no not 150 MB or MiB file sized, even 5-10 MB/MiB file sizes sometimes doesn't go through.

And as a user neither do I have the technical skills involved nor the tenacity to go the extra mile to know how much and where it got sent and how much is remaining to be sent. It should just work :(

Bjorn is fixing this by using a new parser for apport blobs. It's currently under review by Gavin.

Today (2008-10-18 ~ 9:00 GTM+2) I got an:
HTTP Error 502: Bad Gateway
when uploading a large crash (15 mb.. or was it 151 mb? see #92653).
I am not behind proxy or anything strange.
It is possible that package (xorg) was already out of date (see #122818)

What I would suggest is if this could be accomplished by having some library abstracted which could be perhaps re-used by other applications where lot of data needs to be sent to the server (say to some file-sharing site or something) .

Another cool thing if there is a possibility of upload-resuming, I don't know if its possible or not but it would be cool if something like this could be accomplished.

Looking forward for comments and suggestions on the same.

Reproduced this one today by trying to upload a 100M file to staging. Here are my live http headers capture of the POST issued: http://pastebin.ubuntu.com/261145/

Bjorn, what else can I do to help debug this problem?

I'm also seeing this with both manual and automatic uploads of kernel crash dumps.

For someone who can reproduce the problem and is comfortable mucking with the reporting script, it might be useful to add the following to the top of the apport reporting script.

import httplib2
httplib2.debuglevel=1

After this, the next run will print a lot of debugging information that might give us more information on what is timing out. That might help analysis of the problem.

I have this problem with Apport (I don't know what is malone), on Lucid 64bits.
Half of the crashes I want to report end with this message :
"Cannot connect to crash database, please check your Internet connection.

HTTP Error 500: Internal Server Error"

Here is a crash report I can't report with apport : http://scenari.utc.fr/~loa/temp/_usr_bin_evolution.1001.crash

@Loïc Alejandro:
You should be able to retrace the crash dump yourself using apport-retrace. You can then upload the retrace output to a bug report.

Bitten by same bug consistently yesterday - it was impossible to upload a tiny bug report (9KB).

A workaround seems to be by dumping the output to a local file with

$ apport-cli -f -p <package name>

...and then sending the report file with

$ ubuntu-bug report.apport

Using fully up to date.Lucid.

-A

This is a dupe with the issue uploading large relase files I think. I don't have the bug number handy for that.