CPP Persistant Class Store crashes KDevelop 3 -- even more info

Rene Schallner rene.schallner at kabsi.at
Mon Dec 8 05:00:12 UTC 2003


Last message before I go to bed (promised!):

Now this leaves me completely puzzled: The .pcs stuff works for "C++ -->
Simple KDE Application", "C --> Simple Hello world program" projects.

But it doesn't work for "C++ --> Application framework" projects.

It also doesn't work for my custom project that I have created with
KDevelop 2 and opened/converted to KDevelop3. That one is not a KDE app.

As mentioned, it works for the kdevelop project from the source
snapshot.

This behaviour goes completely beyond the scope of my imagination.

	-Rene



On Mon, 2003-12-08 at 04:15, Rene Schallner wrote:
> And I have found out a bit more:
> 
> As I have mentioned, the SIG32 seems  not to be the real problem.
> 
> Now when I gdb kdevelop and load a project that has a .pcs file then I
> get SIG32 as usual but that one doesn't harm. After "continue" the
> source files are loaded, etc, and:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x40c4d41e in ?? () from /usr/lib/libkdecore.so.4
> (gdb) bt
> #0  0x40c4d41e in ?? () from /usr/lib/libkdecore.so.4
> (gdb) quit
> 
> So above we see the difference to the successful run from my previous
> email. 
> 
> 	-Rene
> 
> On Mon, 2003-12-08 at 03:33, Rene Schallner wrote:
> > Hi,
> > 
> > Thanks for your reply. That will keep me busy for a while ... 
> > 
> > I will enumerate the infos for easy future referencing if you don't
> > mind.
> > 
> > 1.
> > Your assumption is correct. Everytime I create a project I can work with
> > it up to the point where I load it (or another one previously created) 
> > again. However, on the other hand I can successfully load the kdevelop
> > project for kdevelop itself (which came with the snapshot) without
> > errors. Any other projects (my self created ones) I can only open after
> > removal of the .pcs file.
> > 
> > 2. 
> > I do NOT have an SMP machine but my kernel is SMP enabled.
> > I guess because of my vast amount of 1GB RAM the Mandrake installer
> > chose to install the so called "Enterprise" kernel which supports SMP
> > and lots of memory. 
> > 
> > uname -a
> > Linux megavaio.local.net 2.4.22-21mdkenterprise #1 SMP Fri Oct 24
> > 19:48:37 MDT 2003 i686 unknown unknown GNU/Linux
> > 
> > 
> > 3. 
> > Re Backtrace: I haven't compiled a debug version yet since I didn't know
> > I'd be writing this now :-) and I didn't know the performance impact.
> > Compiling took about an hour so please tell me if my info would be more
> > useful if I ran a debug compile. It could well be that the info below is
> > "enough" for spotting what's going on and debug would only show more
> > details...
> > 
> > For the moment, this is my backtrace of an unsuccessful attempt to load
> > a project (with a .pcs file present):
> > 
> > 0x41569686 in waitpid () from /lib/i686/libpthread.so.0
> > #0  0x41569686 in waitpid () from /lib/i686/libpthread.so.0
> > #1  0x40c4cfda in KCrash::defaultCrashHandler(int) ()
> >    from /usr/lib/libkdecore.so.4
> > #2  0x416d4ca8 in __libc_sigaction () from /lib/i686/libc.so.6
> > 
> > 
> > 4.
> > KDevelop appears to finish well after a successful start. That is: no
> > core is dumped and the Crash Handler doesn't pop up.
> > I followed your advice and ran kdevelop in gdb to see whether kdevelop
> > would finish well after a successful start.
> > This is what I got when loading the project:
> > 
> > Program received signal SIG32, Real-time event 32.
> > 0x41565714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0
> > (gdb) bt
> > 0x41569686 in waitpid () from /lib/i686/libpthread.so.0
> > #0  0x41569686 in waitpid () from /lib/i686/libpthread.so.0
> > #1  0x40c4cfda in KCrash::defaultCrashHandler(int) ()
> >    from /usr/lib/libkdecore.so.4
> > #2  0x416d4ca8 in __libc_sigaction () from /lib/i686/libc.so.6
> > 
> > Please note: I have repeated and verified this 3 times: When not running
> > in gdb, the project (with .pcs file deleted) loads successfully. When
> > running in gdb it doesn't do so anymore. 
> > The time the signal gets received is immediately after all documents
> > have been loaded, where I would normally see "Updating..." when the
> > persistant class store gets recreated.
> > 
> > My personal opinion when I see this and because you asked about SMP:
> > There might be some synchronization problem (in the persistant class
> > store stuff?) and running under gdb modifies the timing (things go more
> > slowly) and that's why the crash shows up in gdb when it wouldn't
> > otherwise...?
> > 
> > One more thing. I have now booted into the "standard" linux kernel, not
> > the enterprise kernel:
> > 
> > [rene at megavaio rene]$ uname -a
> > Linux megavaio.local.net 2.4.22-10mdk #1 Thu Sep 18 12:30:58 CEST 2003
> > i686 unknown unknown GNU/Linux
> > 
> > And that did not help. Even with the non-SMP-enabled kernel I get the
> > same error when trying to load a project w/o removing the .pcs file.
> > 
> > best regards,
> > 	Rene
> > 
> > On Sun, 2003-12-07 at 19:10, Alexander Dymo wrote: 
> > > I understand that you have .pcs loading problems each time you create a
> > > project. Is it correct?
> > > Some additional questions to clarify situation:
> > > do you have smp machine?
> > > can you send us the backtrace?
> > > does kdevelop finish well (are there crashes at exit after a 
> > > _successfull_ start)?
> > > 
> > > Please check third situation. Run kdevelop in gdb (when all .pcs files
> > > are deleted):
> > > gdb kdevelop
> > > run
> > > bt
> > 
> > 
> > _______________________________________________
> > Kdevelop-devel mailing list
> > Kdevelop-devel at barney.cs.uni-potsdam.de
> > http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> > 
> 
> 
> _______________________________________________
> Kdevelop-devel mailing list
> Kdevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
> 





More information about the KDevelop-devel mailing list