Bill Pringlemeir wrote: > On 13 Nov 2006, [EMAIL PROTECTED] wrote: > > > Were you close to any memory limit? > > No, it is a CPU load. The memory system might be using swap.
Well, Gtk-Gnutella can easily reach a memory limit without hitting swap if your processes a limited to something to 100 MB for example, at least in Ultrapeer mode. Your backtrace seemed to show a SIGSEGV though. > However, I am definitely not running out of swap. It is possible that > GUI code within gtkg had been paged out as it would not be active. Yes, I think the stalling caused when making some search visible again after a long time is caused by paging the relevant data in again. > > If those crashes are reproducible you could try > > > export G_SLICE=always-malloc > > I guess that this will result in a slow down? No, not necessarily. I think for me it even had better performance. That is if you keep halloc enabled because that wraps malloc() over mmap(). However, there are slight differences between Linux and others even when it comes to malloc(), so it might differ between platforms. Also, using mmap() seemed to have far more impact (positively) on AMD64 than on x86. Linux also seems to run of memory-mappings quite easily in contrast to NetBSD. I'm not sure about the status of GLib's slice allocator. They had some very obvious alignment issues before which were not obvious to the people who implemented it. So who knows what nasty surprises are still in there. > It is not reproducible. > As a matter of fact, it is far less common for the last few months. > However, who knows how many different variables have changed in that > time [I have new kernels, glib, gtk, gcc, and of course gtkg]. > > It was sensible in that it traced back to the main() routine. Many of > the previous cores seemed to have incomplete stack traces. Maybe you had fast_assertions enabled? They don't mess with debugging anymore. That might explain the difference. > Will dmalloc check glib's slice allocator? It can't check it completely at least not on any CISC architecture. With RISC you could trivially instrument load and store operations. For x86 you need Purify, full emulation or a patched compiler that allows such instrumentation. I've read something about mudflap in the GCC documentation but apparently haven't installed it and couldn't quite figure out what it really is but at first I thought that would allow exactly this kind of instrumentation. > Is there a slice debug mode for detecting over-writes, use of free memory, > etc. has occurred? There's only this G_SLICE variable AFAIK. There might be something to enable at GLib compile-time. However if there's some dangling pointer you'll have a hard time to catch the moment it's overwriting something. Your only chance is when it writes to non-mapped or read-only mapped memory. Otherwise, you can at best detect that it happens but not figure out the cause. I'm pretty sure that if there's such a nasty bug it must be in the GUI because Topless it's running flawlessly. -- Christian ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Gtk-gnutella-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
