Re: [Evolution] Evolution not starting (SanthanaKrishnan)
On Sat, 2015-01-10 at 14:01 +, Tom, Yahoo wrote: > It would be MUCH better to simply upgrade to Fedora 20 or to their > "Rawhide" (which will probably become 21 eventually). As Pete says, Fedora 21 is already released. However I would absolutely NOT recommend anyone other than an expert interested in testing and prepared to update their system on a daily basis to install Rawhide. See http://fedoraproject.org/wiki/Releases/Rawhide Furthermore, anyone using Fedora should know that they must be willing to update their system to the newest supported version at least once a year (most people do it every 6 months). Patches, especially for security problems, will simply not be available for systems more than 2 versions behind the current one. For example support for F19 ended a few days ago, so even if a gaping hole is discovered allowing any remote user to gain root, F19 will not be fixed. If that's not something you are prepared to deal with, use something else, e.g. Centos, Ubuntu LTS etc. poc ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Evolution not starting (SanthanaKrishnan)
>
> It would be MUCH better to simply upgrade to Fedora 20 or to their
> "Rawhide" (which will probably become 21 eventually).
No, Fedora 21 was released a month ago.
As I said before, in a production environment like an office you should
really, really be using a distro that has a long life. This does not
include Fedora since you need to upgrade that at least once a year - not
does it include most Ubuntu releases.
Go for something like CentOS or if you really must use Ubuntu, get an
LTS ("long term support") version.
But this is now way, way off topic for an Evolution mailing list and
apologise for prolonging it.
P.
___
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] Evolution not starting (SanthanaKrishnan)
Hi :) Ubuntu is a very popular system and widely known outside in the wider world so it might be easier for your software providers to support. So it might well be a good choice. However Ubuntu does have a very different Desktop Environment (=DE) so it looks very different from what you are used to. It is fairly easy to give it an extremely similar DE to the one you use in Fedora but it still works quite a bit differently "under the bonnet". Not as big as the difference between any 2 versions of Windows but still fairly different. It would be MUCH better to simply upgrade to Fedora 20 or to their "Rawhide" (which will probably become 21 eventually). The difference between Ubuntu and Fedora mentioned in my 2nd paragraph should not be a huge problem for your software providers. Most of the programs are the same in both. The main difference for them might be that on a command-line they have to use; sudo yum install libreoffice instead of sudo apt-get install libreoffice Ok, so LibreOffice is a bad example because it's used in both Fedora and Ubuntu. Also i am not sure if it's "yum" in Fedora but it gives an idea of how slight the difference is. You can test-drive Fedora 20 using a "LiveCd" or "LiveUsb" or by installing on 1 system as a dual-boot alongside the existing Fedora 14. I usually have a dual-boot system with one partition being the older system jic i can't work out how to do something on the newer system. https://getfedora.org/ https://getfedora.org/en_GB/workstation/download/ Many regards from Tom :) On 10 January 2015 at 04:32, SanthanaKrishnan wrote: > Dear Sir, > > Thanks for the feedback. My software provider tells that I update to > Ubuntu. We need to update close to 15 systems from fedora 14. > > Is ubuntu the right choice as we might need to export evolution data > which is very vital to us. > > Santhanakrishnan > ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] [sqlite] Segfault with Evolution and patched SQLite 3.8.7.4 (was: Bus error with Evolution 3.12.9 and SQLite 3.8.7.4)
On 1/9/15, Paul Menzel wrote:
> Am Dienstag, den 30.12.2014, 16:15 +0100 schrieb Paul Menzel:
>
> With still around 1.3 GB free on the partition mounted to `/var/`,
> Evolution crashed with the f received the following segmentation fault
> today.
Which build of SQLite are you using. What is SQLITE_SOURCE_ID?
Also, we have some new "sqlite3.c" and "sqlite3.h" files for the
upcoming 3.8.8 release. Can I encourage you to try them out.
>
> 0xb3f9af51 in sqlite3Strlen30 (z=0x18 at address 0x18>) at sqlite3.c:22902
>
>
> Thread 53 (Thread 0xa7e04b40 (LWP 3576)):
> #0 0xb3f9af51 in sqlite3Strlen30 (z=0x18 memory at address 0x18>) at sqlite3.c:22902
sqlite3Strlen30() is called with an invalid string pointer,
apparently. The sqlite3Strlen30() function is just a strlen()
implementation that returns int instead of size_t. Stack frames 0
through 5 look fine, except for the invalid string pointer, of coruse.
> #5 0xb3f9ce21 in unixSync (id=0xacbe7898, flags=2) at
> sqlite3.c:28396
> dirfd = 668585276
> rc =
> pFile = 0xacbe7898
> isDataOnly = 0
> isFullsync = 0
The unixSync routine above calls frame 4 from
(https://www.sqlite.org/src/artifact/949cdedc74dbf3c1?ln=3589).
Apparently, pFile->zPath is an invalid pointer.
> #6 0xb7ad33d6 in call_old_file_Sync (flags=,
> cFile=) at camel-db.c:66
The pFile object with the invalid zPath field is a parameter to
unixSync(), and hence comes from call_old_file_Sync(), which is not a
part of the SQLite source tree. I don't have the sources to
camel-db.c so I cannot trace this any further. My guess (based on the
name of the function) is that camel-db.c is trying to "sync" an
sqlite3_file object that has been previously destroyed.
This appears to be completely unrelated to the previous issue. The
previous issue was that a file was not being extended correctly
because of a lack of disk space, so that a memcpy() into a mmap() of
that file segfaulted. That does not appear to be what is happening
here, unless I'm missing something.
> No locals.
> #7 sync_request_thread_cb (task_data=0x860d9d88, null_data=0x0) at
> camel-db.c:92
> sync_data = 0x860d9d88
> done =
> #8 0xb52d7e64 in g_thread_pool_thread_proxy (data=0x81a73958) at
> /build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gthreadpool.c:307
> task = 0x860d9d88
> #9 0xb52d73da in g_thread_proxy (data=0x89118e90) at
> /build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gthread.c:764
> No locals.
> #10 0xb7caeefb in start_thread (arg=0xa7e04b40) at
> pthread_create.c:309
> __res =
> pd = 0xa7e04b40
> now =
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211363328,
> -1478472896, 4001536, -1478475224, -2031767865, -742727961},
> mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0,
> 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call =
> pagesize_m1 =
> sp =
> freesize =
> __PRETTY_FUNCTION__ = "start_thread"
> #11 0xb51a6dfe in clone () at
> ../sysdeps/unix/sysv/linux/i386/clone.S:129
> No locals.
>
> Thread 51 (Thread 0x972ffb40 (LWP 3574)):
> #0 0xb7fdcd3c in __kernel_vsyscall ()
> No symbol table info available.
> #1 0xb7cb59fb in read () at ../sysdeps/unix/syscall-template.S:81
> No locals.
> #2 0xb3f8d76c in seekAndRead (id=0x81e43980, id=0x81e43980,
> cnt=1024, pBuf=0x8e6d9ac0, offset=23846912) at sqlite3.c:27963
> got =
> prior = 0
> newOffset =
> #3 unixRead (id=0x81e43980, pBuf=0x8e6d9ac0, amt=1024,
> offset=) at sqlite3.c:28027
> pFile = 0x81e43980
> #4 0xb7ad31c2 in camel_sqlite3_file_xRead (pFile=0x81e46b50,
> pBuf=0x8e6d9ac0, iAmt=1024, iOfst=23846912) at camel-db.c:211
> cFile = 0x81e46b50
> #5 0xb3f86517 in sqlite3OsRead (offset=23846912, amt=1024,
> pBuf=, id=) at sqlite3.c:15971
> No locals.
> #6 readDbPage (pPg=pPg@entry=0x8e6d9ee0, iFrame=) at
> sqlite3.c:43754
> iOffset = 23846912
> pPager = 0x81e46a48
> pgno = 23289
> rc = 0
> pgsz = 1024
> #7 0xb3fa15ab in sqlite3PagerAcquire (pPager=0x81e46a48,
> pgno=pgno@entry=23289, ppPage=0x972fe8b8, flags=2) at sqlite3.c:46275
> rc =
> pPg =
> iFrame = 0
> noContent = 0
> bMmapOk =
> #8 0xb3fa199f in btreeGetPage (pBt=0x81e43920, pgno=23289,
> ppPage=0x972fe908, flags=2) at sqlite3.c:53852
> rc =
> pDbPage = 0x8e6d9ee0
> #9 0xb3fa6f9c in getAndInitP
Re: [Evolution] Evolution not starting (SanthanaKrishnan)
On Sat, 2015-01-10 at 10:02 +0530, SanthanaKrishnan wrote: > Is ubuntu the right choice Criteria entirely depends on your needs. Comparing and discussing (dis)advantages of distributions is out of scope for this mailing list which is about Evolution only. Refer to https://en.wikipedia.org/wiki/Comparison_of_Linux_distributions and many many internet websites out there. Thank you, andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-list
Re: [Evolution] [sqlite] Segfault with Evolution and patched SQLite 3.8.7.4
Am Freitag, den 09.01.2015, 21:04 -0500 schrieb Richard Hipp:
> On 1/9/15, Paul Menzel wrote:
> > Am Dienstag, den 30.12.2014, 16:15 +0100 schrieb Paul Menzel:
> >
> > With still around 1.3 GB free on the partition mounted to `/var/`,
> > Evolution crashed with the f received the following segmentation fault
> > today.
>
> Which build of SQLite are you using. What is SQLITE_SOURCE_ID?
I downloaded the source of Debian package for SQLite 3.8.7.4-1 and
applied the patch from [2] (also attached).
$ /usr/bin/sqlite3 --version
3.8.7.4 2014-12-09 01:34:36
f66f7a17b78ba617acde90fc810107f34f1a1f2e
> Also, we have some new "sqlite3.c" and "sqlite3.h" files for the
> upcoming 3.8.8 release. Can I encourage you to try them out.
I’ll try to test the 3.8.8 files. Unfortunately, I have not found a way
to reproduce the issue.
> > 0xb3f9af51 in sqlite3Strlen30 (z=0x18 > at address 0x18>) at sqlite3.c:22902
> >
> >
> > Thread 53 (Thread 0xa7e04b40 (LWP 3576)):
> > #0 0xb3f9af51 in sqlite3Strlen30 (z=0x18 > memory at address 0x18>) at sqlite3.c:22902
>
> sqlite3Strlen30() is called with an invalid string pointer,
> apparently. The sqlite3Strlen30() function is just a strlen()
> implementation that returns int instead of size_t. Stack frames 0
> through 5 look fine, except for the invalid string pointer, of coruse.
>
> > #5 0xb3f9ce21 in unixSync (id=0xacbe7898, flags=2) at
> > sqlite3.c:28396
> > dirfd = 668585276
> > rc =
> > pFile = 0xacbe7898
> > isDataOnly = 0
> > isFullsync = 0
>
> The unixSync routine above calls frame 4 from
> (https://www.sqlite.org/src/artifact/949cdedc74dbf3c1?ln=3589).
> Apparently, pFile->zPath is an invalid pointer.
>
>
> > #6 0xb7ad33d6 in call_old_file_Sync (flags=,
> > cFile=) at camel-db.c:66
>
> The pFile object with the invalid zPath field is a parameter to
> unixSync(), and hence comes from call_old_file_Sync(), which is not a
> part of the SQLite source tree. I don't have the sources to
> camel-db.c so I cannot trace this any further.
You can view the source at [3].
static gint
call_old_file_Sync (CamelSqlite3File *cFile,
gint flags)
{
g_return_val_if_fail (old_vfs != NULL, SQLITE_ERROR);
g_return_val_if_fail (cFile != NULL, SQLITE_ERROR);
g_return_val_if_fail (cFile->old_vfs_file->pMethods != NULL,
SQLITE_ERROR);
return cFile->old_vfs_file->pMethods->xSync
(cFile->old_vfs_file, flags);
}
> My guess (based on the name of the function) is that camel-db.c is
> trying to "sync" an sqlite3_file object that has been previously
> destroyed.
That sounds reasonable. I created a ticket in GNOME’s bug tracker
Bugzilla and it was assigned the ID #742688 [4]. I added you to the CC
list. Hopefully, you do not mind.
> This appears to be completely unrelated to the previous issue. The
> previous issue was that a file was not being extended correctly
> because of a lack of disk space, so that a memcpy() into a mmap() of
> that file segfaulted. That does not appear to be what is happening
> here, unless I'm missing something.
[…]
As always thank you very much for the quick and detailed reply!
Thanks,
Paul
> >> [1] https://packages.debian.org/corekeeper
> >> [2]
> >> https://www.sqlite.org/src/info/776648412c30dce206f1024ff849c2cb025bb006
[3]
http://sources.debian.net/src/evolution-data-server/3.12.9~git20141128.5242b0-2/camel/camel-db.c/#L66
[4] https://bugzilla.gnome.org/show_bug.cgi?id=742688
Index: src/os_unix.c
==
--- src/os_unix.c
+++ src/os_unix.c
@@ -3716,20 +3716,20 @@
** on systems that do not have a real fallocate() system call.
*/
int nBlk = buf.st_blksize; /* File-system block size */
i64 iWrite; /* Next offset to write to */
- if( robust_ftruncate(pFile->h, nSize) ){
-pFile->lastErrno = errno;
-return unixLogError(SQLITE_IOERR_TRUNCATE, "ftruncate", pFile->zPath);
- }
iWrite = ((buf.st_size + 2*nBlk - 1)/nBlk)*nBlk-1;
while( iWriteh, nSize) ){
+pFile->lastErrno = errno;
+return unixLogError(SQLITE_IOERR_TRUNCATE, "ftruncate", pFile->zPath);
+ }
#endif
}
}
#if SQLITE_MAX_MMAP_SIZE>0
Index: src/vdbesort.c
==
--- src/vdbesort.c
+++ src/vdbesort.c
@@ -1130,16 +1130,16 @@
** Whether or not the file does end up memory mapped of course depends on
** the specific VFS implementation.
*/
static void vdbeSorterExtendFile(sqlite3 *db, sqlite3_file *pFd, i64 nByte){
if( nByte<=(i64)(db->nMaxSorterMmap) && pFd->pMethods->iVersion>=3 ){
-int rc = sqlite3OsTruncate(pFd, nByte);
-if( rc==SQLITE_OK ){
- void *p = 0;
- sqlite3O
