CPP Persistant Class Store crashes KDevelop 3

[Rene Schallner]

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