wierd QT warnings and ksycoca errors

[Ralf Habacker]

On Tuesday 10 May 2005 03:56, Sunil wrote:
> > There are some places in the kde sources where
> > something like this happens.
> > Usually there is only a file close required. See the
> > appended patch, which fixes several problems
>
> your patch doesn't fix the problem because the problem
> with updating ksycoca database is coming from
> database.close() line in kbuildsycoca.cpp :
>
>     if (!database.close())
>     {
>       fprintf(stderr, "kbuildsycoca: ERROR writing
> database '%s'!\n",
> database.name().local8Bit().data());
>       fprintf(stderr, "kbuildsycoca: Disk full?\n");
> #ifdef KBUILDSYCOCA_GUI
>       if (!silent)
>         KMessageBox::error(0, i18n("Error writing
> database '%1'.\nCheck that the permissions are correct
> on the directory and the disk is not
> full.\n").arg(path.local8Bit().data()),
> i18n("KBuildSycoca"));
> #endif
>       return false;
>     }
>
> kdecore/ksavefile.cpp has the following piece of code
> where close() renames the temporary file to the
> ksycoca in /var/tmp/kdecache-<username>/. This fails
> because some process has opened that file READ_ONLY.
> It looks like it is kded daemon as one of processes
> which has it opened. 
And one kdeinit process too 
> But I am not sure how to ask these processes to close this file.

all access to the ksycoca database is encapsulated  by the class KSycoca, 
which contains a signal handler notifyDatabaseChanged(), wich closes the 
database. from kdecore/ksycoca.cpp

void KSycoca::notifyDatabaseChanged(const QStringList &changeList)
{
    d->changeList = changeList;
    //kdDebug(7011) << "got a notifyDatabaseChanged signal !" << endl;
    // kded tells us the database file changed
    // Close the database and forget all about what we knew
    // The next call to any public method will recreate
    // everything that's needed.
    closeDatabase();

    // Now notify applications
    emit databaseChanged();
}

The relating signal is send after updating the database in 
kbuildsycoca:kdemain():

   if (args->isSet("signal"))
   {
     // Notify ALL applications that have a ksycoca object, using a broadcast
     QByteArray data;
     QDataStream stream(data, IO_WriteOnly);
     stream << *g_changeList;
     dcopClient->send( "*", "ksycoca", "notifyDatabaseChanged(QStringList)", 
data );
   }

The problem is that this signal is send to late. A workaround could be to send 
this signal immediatly before the call to KBuildSycoca::recreate() in 
kbuildsycoca:kdemain()

      KBuildSycoca *sycoca= new KBuildSycoca; // Build data base
      if (args->isSet("track"))
         sycoca->setTrackId(QString::fromLocal8Bit(args->getOption("track")));
>>>>>>>>>>>>>>>>>>>> 
   if (args->isSet("signal"))
   {
     // Notify ALL applications that have a ksycoca object, using a broadcast
     QByteArray data;
     QDataStream stream(data, IO_WriteOnly);
     stream << *g_changeList;
     dcopClient->send( "*", "ksycoca", "notifyDatabaseChanged(QStringList)", 
data );
   }
<<<<<<<<<<<<<<<<<<<
      if (!sycoca->recreate()) {

but I don't do if this works in any cases. 

A generic approach is to introduce a new signal for example 
notifyDatabaseUpdatePending or so, which could close and lock any unwanted 
access to the database until the notifyDatabaseChanged is send. If the 
workaround doesn't work we can implemented this. If you need any assistance, 
let me know. 

>
>    if (mTempFile.close())
>    {
>       if
> (0==KDE_rename(QFile::encodeName(mTempFile.name()),
> QFile::encodeName(mFileName)))
>          return true; // Success!
>       mTempFile.setError(errno);
>    }
>
> this is where processes open the ksycoca database in
> kdecore/ksycoca.cpp:
>
>    kdDebug(7011) << "Trying to open ksycoca from " <<
> path << endl;
>    QFile *database = new QFile(path);
>    bool bOpen = database->open( IO_ReadOnly );
>
> I am not sure how to tackle this. In Unix its so easy
> to assume that readers won't stop writers from
> writing. Do you think cygwin can demand different
> semantics from kde folks, wherein its the kded which
> does the update to the database always (currently eny
> process can call kbuildsycoca to update the database)
> and everybody, who has the database opened, is asked
> to close the database before rename() is issued by
> kded? 
see above 
> Should I file a bug report with kde? 
It may be good to ask them what kind of solution they prefer for this problem 
and what they are thinking about the generic solution. 

> > > 2. I get these in my kde session log all the time:
> > >
> > > QObject::disconnect: Unexpected null parameter
> > > QObject::connect: Cannot connect (null)::hide() to
> > > Baghira::DeMaximizer::hide()
> > >
> > > I am not sure if they are errors or warnings.
> >
> > Anyone
> >
> > > any idea?
> >
> > Which application causes this warnings ?  It seems
> > that a qt signal/slot
> > connection couldn't be established. The slot is
> > named in DeMaximizer::hide()
> > in namespace Baghira.
>
> I am not sure which process it is. I just see these
> repeated very often in the log file.

try 
find <source path> -name '*.cpp' -exec grep -H "Baghira::DeMaximizer" {} \;
 to find the relating code. 


regards 
Ralf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kbuildsycoca.patch
Type: text/x-diff
Size: 3128 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-cygwin/attachments/20050510/570564d9/kbuildsycoca.bin