After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 236778 - ibex files get really large
ibex files get really large
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.0.x (obsolete)
Other All
: Normal critical
: ---
Assigned To: Not Zed
Evolution QA team
evolution[folders]
: 240755 243755 269179 270822 318035 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-01-15 21:53 UTC by Tom Anderson
Modified: 2006-01-09 15:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fixed fd issues which may, or may not, be related (2.11 KB, patch)
2005-03-18 06:02 UTC, Not Zed
none Details | Review

Description Tom Anderson 2003-01-15 21:53:00 UTC
Please fill in this template when reporting a bug, unless you know what you
are doing.
Description of Problem:

I run Evolution continuously 24/7, and this morning when I turned on the
monitor, the mail component had failed overnight with 7 new messages in my
inbox, and now it won't load any of the folders again.  The Evolution GUI
starts up, but it just says, "Opening folder file://...," and never
actually opens any of the folders.  In the terminal, I get the following
error: "evolution-shell-WARNING **: Error changing interactive status of
component OAFIID:GNOME_Evolution_Mail_ShellComponent to TRUE --
IDL:omg.org/CORBA/COMM_FAILURE:1.0".  

I tried shutting down the program, running "killev" and "oaf-slay", but it
gives me the same problems after starting it up again.  I even downloaded
all of the newest updates using Red Carpet, and still the same problem.  I
rebooted the system, still same problem.  When I run it as root or any
other user, it opens the respective user's folders fine, and I am able to
download new mail, but I cannot access any of my existing mail folders
under my default user.

Steps to reproduce the problem:
1. Unknown... I've been running Evolution for months without problems, and
it just failed unexpectedly.  I've had component failures in the past, but
running "killev" and loading it again always fixed it.  I do have a large
amount of email in my folders... could there be a limit?  I also use many
filters for sorting my mail into different folders.  I just set up a new
one last night to send anything from recipients containing "clickz" or
"internet.com" to the subfolder "tech news" under "inbox".  But I don't
know if that is related to the bug.

Actual Results: Folders do not load.

Expected Results: Folders should load.

How often does this happen? Every time.

Additional Information:

The summary, calendar, and contacts all load correctly.
Comment 1 Tom Anderson 2003-01-15 22:07:35 UTC
Sorry, that should have read:

I just set up a new one [filter] last night to send anything from
SENDERS containing "clickz" or "internet.com" to the subfolder "tech
news" under "inbox".  

But, like I said, I have no idea if that has anything to do with the
bug.  I'm just reporting that because of their temporal proximity, not
because of any known causal relationship.
Comment 2 Tom Anderson 2003-01-15 22:19:25 UTC
BTW, I thought about it being a disk space issue, and I have 13GB free
with no quotas.
Comment 3 Gerardo Marin 2003-01-15 22:24:39 UTC
try
killev; oaf-slay; rm -rf /tmp/orbit-$USER 
Please REOPEN if that doesn't work
Comment 4 Tom Anderson 2003-01-15 23:13:10 UTC
Suggestion: killev; oaf-slay; rm -rf /tmp/orbit-$USER

Did NOT resolve the problem.  Same error message appears on the
terminal.  Folders still do not open.  Also, summary does not open now.
Comment 5 Tom Anderson 2003-01-16 06:53:03 UTC
I've discovered the source of the problem.  The file
.#mbox.ibex.index.data exceeded 2GB, and apparently linux is limited
to 32-bit integers, thus the largest possible file size is 2^31-1
bytes.  Deleting the offending file returned Evolution to full
functionality.

While this is technically a linux issue, I would also consider it an
Evolution bug that this file could grow to this size considering the
mbox file is only 84MB.  Now, I'm no expert on the way Evolution
functions, but I believe that this has to do with some sort of
undelete functionality built into Evolution?  There should exist a
checking mechanism which warns users to expunge their deleted files (I
think this would kill the file size, right?) before it ever gets to
this extreme.  With the amount of spam people receive, especially with
large images and virus attachments, this is only likely to get worse.

Please consider it a bug that this file is able to exceed 20 times the
size of the mbox file without being checked.  Additionally, this
should be added to the FAQ.  I can imagine some people just give up on
Evolution if this happens otherwise.
Comment 6 Jeffrey Stedfast 2003-01-16 17:34:40 UTC
this is a duplicate of another bug about really large ibex files
Comment 7 Gerardo Marin 2003-01-16 18:02:21 UTC
Found no duplicates.  Leaving this open meanwhile
Comment 8 Luis Villa 2003-05-03 23:53:09 UTC
I think I intended to file a bug (which is probably why jeff
considered this a dup) but never did. It's certainly still happening
here; just found one of 1/4G in CVS HEAD. 
Comment 9 Luis Villa 2003-05-03 23:57:00 UTC
That said, note bug 240755.
Comment 10 Gerardo Marin 2003-05-06 16:16:18 UTC
*** bug 240755 has been marked as a duplicate of this bug. ***
Comment 11 Not Zed 2003-08-05 18:20:20 UTC
fwiw i have no idea on this bug
Comment 12 Not Zed 2003-08-05 18:22:56 UTC
*** bug 243755 has been marked as a duplicate of this bug. ***
Comment 13 Not Zed 2005-01-17 07:32:53 UTC
*** bug 270822 has been marked as a duplicate of this bug. ***
Comment 14 Not Zed 2005-01-19 08:05:56 UTC
*** bug 269179 has been marked as a duplicate of this bug. ***
Comment 15 Not Zed 2005-03-18 06:02:03 UTC
Created attachment 44997 [details] [review]
fixed fd issues which may, or may not, be related
Comment 16 Not Zed 2005-03-31 02:24:47 UTC
closing in the perhaps wildly optimistic hope that the above patch
will fix it
Comment 17 André Klapper 2006-01-09 15:06:25 UTC
*** Bug 318035 has been marked as a duplicate of this bug. ***