KDE: ja tego nie rozumiem... :( (zwalony gcc?)
Michal Kochanowicz
mkochano w ee.pw.edu.pl
Pon, 25 Gru 2000, 14:51:00 CET
Cześć
Po ponad tygodniu grzebania w KDE poprostu nie mam pojęcia co tam się
dzieje. Opiszę co zaobserwowałem, może ktoś z was coś z tego zrozumie.
Jak już wcześniej pisałem po upgrade gcc z release 13 do 16 przestał się
uruchamiać kdesktop oraz konqueror. knotify wywalał się i przedtem.
Ponieważ nie potrafię śledzić kde pod debuggerem (skompilowane z -g,
udaje mi się normalnie stawiać breakpointy, ale zachowuje się inaczej
uruchomione z terminala a inaczej z gdb/ddd) dodwałem w różnych
miejscach "cerr <<" i patrzyłem co się dzieje.
Na początek backtrace jaki dostaję po uruchomieniu kdesktop:
0x40f9f369 in wait4 () from /lib/libc.so.6
#0 0x40f9f369 in wait4 () from /lib/libc.so.6
#1 0x41005b34 in __check_rhosts_file () from /lib/libc.so.6
#2 0x4054f3f0 in KCrash::defaultCrashHandler (signal=11) at kcrash.cpp:191
#3 0x40f24de8 in sigaction () from /lib/libc.so.6
#4 0x407d1758 in QGDict::look_string (this=0x0, key=@0xbfffefd8, d=0x0, op=0)
at tools/qgdict.cpp:356
#5 0x40228eb9 in KIO::Scheduler::ProtocolInfoDict::get (this=0x0,
^^^^^^^^
_key=@0xbffff008) at /home/misiek/SRC/kde/qt-2.2.3/include/qdict.h:66
#6 0x40229b83 in KIO::Scheduler::_doJob (this=0x80a8e00, job=0x80a8da0)
at scheduler.cpp:181
#7 0x40234d47 in KIO::SimpleJob::SimpleJob (this=0x80a8da0, url=@0x80a756c,
command=71, packedArgs=@0xbffff164, showProgressInfo=false) at job.cpp:255
#8 0x4023d263 in KIO::ListJob::ListJob (this=0x80a8da0, u=@0x80a756c,
showProgressInfo=false, _recursive=false, _prefix=0xbffff1b8)
at job.cpp:1196
#9 0x4023e347 in KIO::listDir (url=@0x80a756c, showProgressInfo=false)
at job.cpp:1322
#10 0x401e09e9 in KDirLister::openURL (this=0x80a7538, _url=@0xbffff814,
_showDotFiles=true, _keep=false) at kdirlister.cpp:137
#11 0x4003a62e in KDesktop::slotStart (this=0xbffff760) at desktop.cc:237
#12 0x4089593f in QObject::activate_signal (this=0x80a4aa4,
signal=0x40c015e0 "x(int)", param=0) at kernel/qobject.cpp:2058
#13 0x408cfac4 in QSignal::activate (this=0x80a4aa4) at kernel/qsignal.cpp:255
#14 0x408d8509 in QSingleShotTimer::event (this=0x80a4a80)
at kernel/qtimer.cpp:257
#15 0x4084b1b8 in QApplication::notify (this=0xbffffb08, receiver=0x80a4a80,
event=0xbffff59c) at kernel/qapplication.cpp:1675
#16 0x404fdc4b in KApplication::notify (this=0xbffffb08, receiver=0x80a4a80,
event=0xbffff59c) at kapp.cpp:506
#17 0x40b3a78c in QApplication::sendEvent (receiver=0x80a4a80,
event=0xbffff59c) at kernel/qapplication.h:395
#18 0x4080bcc5 in qt_activate_timers () at kernel/qapplication_x11.cpp:3531
#19 0x40809430 in QApplication::processNextEvent (this=0xbffffb08,
canWait=true) at kernel/qapplication_x11.cpp:2573
#20 0x4084d8bf in QApplication::enter_loop (this=0xbffffb08)
at kernel/qapplication.cpp:2562
#21 0x40808f0e in QApplication::exec (this=0xbffffb08)
at kernel/qapplication_x11.cpp:2415
#22 0x40042501 in main (argc=1, argv=0xbffffc84) at main.cc:100
#23 0x40f14f8e in __libc_start_main () from /lib/libc.so.6
Jak widać w punkcie #5 następuje wywołanie metody dla nieistniejącego
obiektu. Dzieje się to w pliku kio/scheduler.cpp (z kdelibs) w tym
miejscu:
void Scheduler::_doJob(SimpleJob *job) {
QString protocol = job->url().protocol();
//kdDebug(7006) << "Scheduler::_doJob protocol=" << protocol << endl;
cerr <<
getpid() << " protInfoDict(" <<
__SchedulerID << ", " << this << ") = " <<
protInfoDict << endl;
ProtocolInfo *protInfo = protInfoDict->get(protocol);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
protInfo->joblist.append(job);
mytimer.start(0, true);
}
Żeby się temu lepiej przyjrzeć dodałem do tego modułu zmienną globalną
_SchedulerID która miała przechowywać ilość utworzonych obiektów klasy
Scheduler, a do samej klasy dodałem pole __SchedulerID inicjalizowane w
konstruktorze:
int _SchedulerID = 0;
Scheduler::Scheduler()
: QObject(0, "scheduler"),
DCOPObject( "KIO::Scheduler" ),
mytimer(this, "Scheduler::mytimer"),
cleanupTimer(this, "Scheduler::cleanupTimer")
{
__SchedulerID = ++_SchedulerID; // MY CODE
slaveOnHold = 0;
protInfoDict = new ProtocolInfoDict;
cerr << // MY CODE
getpid() << " new protInfoDict(" <<
__SchedulerID << ", " << this << ") = " <<
protInfoDict << endl;
slaveList = new SlaveList;
idleSlaves = new SlaveList;
connect(&mytimer, SIGNAL(timeout()),
SLOT(startStep()));
connect(&cleanupTimer, SIGNAL(timeout()),
SLOT(slotCleanIdleSlaves()));
busy = false;
}
Oto co otrzymałem:
6774 new protInfoDict(1, 0x80a4ce8) = 0x80a4f18
6774 protInfoDict(0, 0x80a4c00) = (nil)
KCrash: crashing.... crashRecursionCounter = 2
KCrash: Application Name = kdesktop path = <unknown>
To wszystko co wyprodukował mój kod, czyli wynika z tego, że utworzony
został tylko jeden obiekt klasy Scheduler.
Problem w tym, że nie rozumiem tego co otrzymałem. Pierwsza linia jest
OK, jest tworzony obiekt klasy Scheduler, on następnie tworzy sobie
obiekt klasy ProtocolInfoDict, przy czym zwiększana jest wartość
_SchedulerID do 1. Jak więc w takim razie możliwe jest to, co pojawia
się w drugiej linii??? Bo wynika z niej po pierwsze że obiekt nigdy nie
został utworzony (druga liczba w nawiasach to wartość "this"), a po
drugie (co jest jakby konsekwencją pierwszego) __SchedulerID zawiera
niezainicjalizowaną wartość.
Ponieważ problem pojawił się po zmianie kompilatora, wydaje mi się, że
jest to jego wina. Pytanie brzmi jak to naprawić, albo inaczej: skąd
wziąść działający kompilator? Próbowałem skompilować ze źródeł
gcc-2.95.2 oraz aktualny snapshot i oba wywalają się przy budowaniu
kompilatora stage1. Czy to normalne, że kompilator nie daje się
tak porostu, bez żadnych patchy, zbudować?
Ja w tym momencie się poddaję. Nie mam pojęcia co można dalej z tym
zrobić. Wysłałem to jako bugreport KDE, ale wątpię aby oni byli w stanie
rozwiązać problem, myślę że poprostu mamy zwalony kompilator :(
--
--= Michal Kochanowicz==--==--==BOFH==--==--==mkochano w ee.pw.edu.pl =--
--= PGP key: www.ee(...)/~mkochano/PGP/ or finger me @ miriam.ee... =--
--==--==--==--= Happines is good health and bad memory =--==--==--==--
Więcej informacji o liście dyskusyjnej pld-devel-pl