Bug 438757 - Evolution unable to send message for unknown reasons
Evolution unable to send message for unknown reasons
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-24 17:37 EDT by Jesse Keating
Modified: 2013-01-09 22:19 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-25 07:10:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jesse Keating 2008-03-24 17:37:13 EDT
Trying to send a couple messages evolution will get stuck at Sending (0%). 
Short messages get right through, even medium messages, and this one isn't all
that long.  Here is a backtrace when Evo is stuck:

Thread 2 (Thread 0x403b3950 (LWP 3112)):
#0  0x00007f9bb8f6f346 in __poll (fds=0x2552460, nfds=8, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f9bb923eaf8 in g_main_context_iterate (context=0x251a4f0, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2945
#2  0x00007f9bb923f18d in IA__g_main_loop_run (loop=0x2518800) at gmain.c:2844
#3  0x00007f9bbbc1edf0 in link_io_thread_fn (data=<value optimized out>)
    at linc.c:396
#4  0x00007f9bb9264404 in g_thread_create_proxy (data=0x24eade0)
    at gthread.c:635
#5  0x0000000002bc740a in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#6  0x00007f9bb8f78d1d in clone () from /lib64/libc.so.6

Thread 1 (Thread 0x7f9bb22657b0 (LWP 3111)):
#0  0x00007f9bb8f6f346 in __poll (fds=0x2551140, nfds=5, timeout=1195629)
    at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x00007f9bb923eaf8 in g_main_context_iterate (context=0x24dd3c0, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2945
#2  0x00007f9bb923f18d in IA__g_main_loop_run (loop=0x24b8950) at gmain.c:2844
#3  0x00007f9bbc08e276 in bonobo_main () at bonobo-main.c:311
#4  0x0000000000415542 in main (argc=3, argv=<value optimized out>)
    at notify-main.c:164
0x00007f9bb8f6f346	87	  int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds,
nfds), nfds, timeout);

or a more full bt:

Thread 2 (Thread 0x403b3950 (LWP 3112)):
#0  0x00007f9bb8f6f346 in __poll (fds=0x2552460, nfds=8, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:87
	oldtype = 0
	result = <value optimized out>
#1  0x00007f9bb923eaf8 in g_main_context_iterate (context=0x251a4f0, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2945
	max_priority = 2147483647
	timeout = -1
	some_ready = <value optimized out>
	nfds = 8
	allocated_nfds = <value optimized out>
	fds = (GPollFD *) 0x2552460
	__PRETTY_FUNCTION__ = "g_main_context_iterate"
#2  0x00007f9bb923f18d in IA__g_main_loop_run (loop=0x2518800) at gmain.c:2844
	self = (GThread *) 0x24eade0
	__PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#3  0x00007f9bbbc1edf0 in link_io_thread_fn (data=<value optimized out>)
    at linc.c:396
No locals.
#4  0x00007f9bb9264404 in g_thread_create_proxy (data=0x24eade0)
    at gthread.c:635
	__PRETTY_FUNCTION__ = "g_thread_create_proxy"
#5  0x0000000002bc740a in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
	__res = <value optimized out>
	pd = (struct pthread *) 0x403b3950
	unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 39983758213120708, 0, 
        3338240, 0, 140736509208800, 40124968697332420, 39978778829914820}, 
      mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {
      prev = 0x0, cleanup = 0x0, canceltype = 0}}}
	not_first_call = <value optimized out>
	robust = <value optimized out>
#6  0x00007f9bb8f78d1d in clone () from /lib64/libc.so.6
	__elf_set___libc_subfreeres_element_fstab_free__ = (
    const void *) 0x7f9bb8fb5dc0
	fstab_state = {fs_fp = 0x0, fs_buffer = 0x0, fs_mntres = {
    mnt_fsname = 0x0, mnt_dir = 0x0, mnt_type = 0x0, mnt_opts = 0x0, 
    mnt_freq = 0, mnt_passno = 0}, fs_ret = {fs_spec = 0x0, fs_file = 0x0, 
    fs_vfstype = 0x0, fs_mntops = 0x0, fs_type = 0x0, fs_freq = 0, 
    fs_passno = 0}}

Thread 1 (Thread 0x7f9bb22657b0 (LWP 3111)):
#0  0x00007f9bb8f6f346 in __poll (fds=0x2551140, nfds=5, timeout=1195629)
    at ../sysdeps/unix/sysv/linux/poll.c:87
	oldtype = 0
	result = <value optimized out>
#1  0x00007f9bb923eaf8 in g_main_context_iterate (context=0x24dd3c0, block=1, 
    dispatch=1, self=<value optimized out>) at gmain.c:2945
	max_priority = 2147483647
	timeout = 1195629
	some_ready = <value optimized out>
	nfds = 5
	allocated_nfds = <value optimized out>
	fds = (GPollFD *) 0x2551140
	__PRETTY_FUNCTION__ = "g_main_context_iterate"
#2  0x00007f9bb923f18d in IA__g_main_loop_run (loop=0x24b8950) at gmain.c:2844
	self = (GThread *) 0x24a7630
	__PRETTY_FUNCTION__ = "IA__g_main_loop_run"
#3  0x00007f9bbc08e276 in bonobo_main () at bonobo-main.c:311
	loop = (GMainLoop *) 0x5
#4  0x0000000000415542 in main (argc=3, argv=<value optimized out>)
    at notify-main.c:164
No locals.
0x00007f9bb8f6f346	87	  int result = INLINE_SYSCALL (poll, 3, CHECK_N (fds,
nfds), nfds, timeout);

The text of the message is:

Per the Fedora 9 Development schedule, we will begin allowing early CVS
branching of packages for F-9.  This will allow maintainers to have an
F-9/ branch for continued Fedora 9 stable work and allow experimental
work to happen in the devel/ branch.  For packages that choose to
branch, builds from devel/ will be held in the 'dist-f10' collection
within koji.  Builds from F-9/ will go to the dist-f9 collection and
show up in rawhide (at least until the final freeze).

Maintainers that wish to have their packages branched early will need to
use the standard CVS Request method
( http://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedure ).
We will begin processing these requests on Tuesday, March 25th.

New packages brought into Fedora will not automatically get an F-9 tag
until after the mass branch date, which coincides with the final freeze
date.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?
Comment 1 Milan Crha 2008-03-25 04:39:31 EDT
The backtrace comes from evolution-alarm-notify, which does nothing at the
moment (based on the trace), can you attach "thread apply all bt" of evolution
process, and maybe evolution-data-server too? Thanks.
Comment 2 Jesse Keating 2008-03-25 07:10:23 EDT
Turns out that it wasn't an evolution issue at all.  My MTU was set too high
(1500) and freaking out the mail server.

Note You need to log in before you can comment on or make changes to this bug.