tags 711924 moreinfo thanks Hi js,
On Mon, Jun 10, 2013 at 11:00:44PM -0400, js wrote: > Package: claws-mail > Version: 3.9.1-1 > Severity: normal > > Dear Maintainer, > > * What led up to the situation? > > When one clicks on any email in the Inbox just after claws-mail starts > up and there are new emails being read in, claws-mail gets a segmentation > fault (stack trace below) that looks like: > fancy_viewer.c:856:fancy_viewer_create > Can work around this by waiting several minutes after claws-mail starts > up before selecting any mail in the Inbox. > Note that this problem only happens for mails in the Inbox; one can > select an email in Trash, Drafts, Sent, etc. immediately after startup > without any problem. Only emails in the Inbox cause the segmentation fault. > > Claws-mail should continue to run without crashing after selecting an > email in Inbox right after startup, just as it does when selecting an email > in the other mail folders just after startup. That's very strange, unless all the messages in your inbox are HTML. Even more weird that waiting fixes the crash below, unless there's some process in the background playing. > > Full stack trace: > 0xb7fe8329 in dl_new_hash (s=0xd5d003f7 <Address 0xd5d003f7 out of > bounds>) at dl-lookup.c:477 > 477 dl-lookup.c: No such file or directory. > (gdb) bt > #0 0xb7fe8329 in dl_new_hash (s=0xd5d003f7 <Address 0xd5d003f7 out of > bounds>) at dl-lookup.c:477 > #1 _dl_lookup_symbol_x (undef_name=0xd5d003f7 <Address 0xd5d003f7 out of > bounds>, undef_map=undef_map@entry=0x89d33a0, ref=ref@entry=0xbfffd5e4, > symbol_scope=symbol_scope@entry=0x89d3558, version=0x0, type_class=0, > flags=flags@entry=1, skip_map=skip_map@entry=0x0) at dl-lookup.c:717 > #2 0xb7fe9fd1 in elf_machine_rel (sym=0xb0ae7738, skip_ifunc=0, > reloc_addr_arg=0xab78e000, version=<optimized out>, map=0x89d33a0, > reloc=<optimized out>) > at ../sysdeps/i386/dl-machine.h:339 > #3 elf_dynamic_do_Rel (skip_ifunc=0, lazy=<optimized out>, > nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, > map=0x89d33a0) at do-rel.h:137 > #4 _dl_relocate_object (scope=0x89d3558, reloc_mode=reloc_mode@entry=0, > consider_profiling=0, consider_profiling@entry=5) at dl-reloc.c:265 > #5 0xb7ff1de7 in dl_open_worker (a=a@entry=0xbfffd7ec) at dl-open.c:420 > #6 0xb7fedb2e in _dl_catch_error (objname=objname@entry=0xbfffd7e4, > errstring=errstring@entry=0xbfffd7e8, mallocedp=mallocedp@entry=0xbfffd7e3, > operate=operate@entry=0xb7ff1a00 <dl_open_worker>, > args=args@entry=0xbfffd7ec) at dl-error.c:177 > #7 0xb7ff15d4 in _dl_open (file=0x89d2390 > "/usr/lib/libproxy/0.3.1/modules/pacrunner_mozjs.so", mode=-2147483646, > caller_dlopen=caller_dlopen@entry=0xaed941ac > <px_module_manager_load+348>, nsid=-2, argc=argc@entry=2, > argv=argv@entry=0xbffff484, env=0x83f4690) at dl-open.c:656 > #8 0xb6cc4cce in dlopen_doit (a=a@entry=0xbfffd9a0) at dlopen.c:66 > #9 0xb7fedb2e in _dl_catch_error (objname=0x83fbbf4, > errstring=0x83fbbf8, mallocedp=0x83fbbf0, operate=0xb6cc4c30 <dlopen_doit>, > args=0xbfffd9a0) at dl-error.c:177 > #10 0xb6cc5422 in _dlerror_run (operate=operate@entry=0xb6cc4c30 > <dlopen_doit>, args=args@entry=0xbfffd9a0) at dlerror.c:163 > #11 0xb6cc4d87 in __dlopen (file=0x89d2390 > "/usr/lib/libproxy/0.3.1/modules/pacrunner_mozjs.so", mode=2) at dlopen.c:87 Seems the error is generated by libproxy trying to open an unexisting so file; libproxy has been multi-arch-ified recently and pacruner_mozjs.so is in a different (architecture-dependent) location: http://packages.debian.org/search?mode=filename&suite=sid§ion=all&arch=any&searchon=contents&keywords=pacrunner_mozjs.so My first suggestion is to try to upgrade libroxy package and see if this fixes the problem. Are you using a pac file in your proxy settings? See also this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=644373 > #12 0xaed941ac in px_module_manager_load () from /usr/lib/libproxy.so.0 > #13 0xaed94299 in px_module_manager_load_dir () from > /usr/lib/libproxy.so.0 > #14 0xaed95837 in px_proxy_factory_new () from /usr/lib/libproxy.so.0 > #15 0xb5151f24 in ?? () from > /usr/lib/i386-linux-gnu/gio/modules/libgiolibproxy.so > #16 0xb74701b4 in g_type_create_instance () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #17 0xb7452af1 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #18 0xb7454819 in g_object_newv () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #19 0xb7454db8 in g_object_new () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #20 0xb790b4ab in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0 > #21 0xb790b665 in ?? () from /usr/lib/i386-linux-gnu/libgio-2.0.so.0 > #22 0xb791c881 in g_proxy_resolver_get_default () from > /usr/lib/i386-linux-gnu/libgio-2.0.so.0 > #23 0xb3a8826d in ?? () from /usr/lib/i386-linux-gnu/libsoup-2.4.so.1 > #24 0xb74547a2 in g_object_newv () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #25 0xb7454db8 in g_object_new () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #26 0xb3a91018 in soup_session_add_feature_by_type () from > /usr/lib/i386-linux-gnu/libsoup-2.4.so.1 > #27 0xb3a919eb in ?? () from /usr/lib/i386-linux-gnu/libsoup-2.4.so.1 > #28 0xb74550d1 in g_object_set_valist () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #29 0xb7455858 in g_object_set () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #30 0xb433cc10 in ?? () from /usr/lib/libwebkitgtk-1.0.so.0 > #31 0xb3c485a9 in webkit_get_default_session () from > /usr/lib/libwebkitgtk-1.0.so.0 > #32 0xb3c480c8 in webkitInit () from /usr/lib/libwebkitgtk-1.0.so.0 > #33 0xb3c64d8c in ?? () from /usr/lib/libwebkitgtk-1.0.so.0 > #34 0xb746d4d2 in g_type_class_ref () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #35 0xb74548ee in g_object_newv () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #36 0xb7454db8 in g_object_new () from > /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 > #37 0xb3c678f2 in webkit_web_view_new () from > /usr/lib/libwebkitgtk-1.0.so.0 > #38 0xb5188f5b in fancy_viewer_create () at fancy_viewer.c:869 regards, -- Ricardo Mones ~ 00:45 < hammar> cool.. have you used rssyl? 00:46 <@Ticho> um, yes Seen on #sylpheed
signature.asc
Description: Digital signature
