https://bugs.kde.org/show_bug.cgi?id=405295
--- Comment #4 from zephyrus00jp <ishik...@yk.rim.or.jp> --- Dear Julian, I am still trying analyze the segmentation failure which I observe when I try to run thunderbird under valgrind. System is Debian GNU/Linux. Linux ip030 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux I am now using 3.15.0 GIT version and still get segmentation error somewhere. In order to debug a little further, I added --vgdb=yes --vgdb-error=0 valgrind optons. I could talk to the vgdb from remote gdb session. Attached is the verbose log that leads to segmentation error from the run, and a short log from remote gdb. As far as the remote gdb session goes, it sees the remote end disappear after segmentation error. A couple of points I noticed from the valgrind log. 1. There are a few cases of extending stack base in the verbose log. Can it be that I am running out of stack space??? e.g.: --15408-- sync signal handler: signal=11, si_code=1, EIP=0x40088b1, eip=0x10049ff393, from kernel --15408-- SIGSEGV: si_code=1 faultaddr=0x1ffeffddf4 tid=1 ESP=0x1ffeffddf0 seg=0x1ffe672000-0x1ffeffdfff --15408-- -> extended stack base to 0x1ffeffd000 --15408-- sync signal handler: signal=11, si_code=1, EIP=0x4009722, eip=0x1004a3ee8c, from kernel --15408-- SIGSEGV: si_code=1 faultaddr=0x1ffeffcff8 tid=1 ESP=0x1ffeffcff8 seg=0x1ffe672000-0x1ffeffcfff --15408-- -> extended stack base to 0x1ffeffc000 --15408-- sync signal handler: signal=11, si_code=1, EIP=0x400a334, eip=0x1004a3eb28, from kernel --15408-- SIGSEGV: si_code=1 faultaddr=0x1ffeffbff8 tid=1 ESP=0x1ffeffbff8 seg=0x1ffe672000-0x1ffeffbfff --15408-- -> extended stack base to 0x1ffeffb000 2. There is a warning about conflicting redirection(?) ==15408== WARNING: new redirection conflicts with existing -- ignoring it --15408-- old: 0x0401e280 (strlen ) R-> (0000.0) 0x580c9e32 vgPlain_amd64_linux_REDIR_FOR_strlen --15408-- new: 0x0401e280 (strlen ) R-> (2007.0) 0x04836170 strlen 3. The last signal dumped is 13. This is SIGPIPE suggesting that a pipe was broken: I am not sure what caused the signal (meaning the other end died?, but then which end of what pipe? ) |make mozmill| test suite definitely uses interprocess communication and so the message from the python interpreter or something that is used to create mozmill test framework. Anyway attached is the log. Any pointer will be appreciated. However, I have a feeling this could be the result of strange kernel configuration which fails valgrind for mysterious reasons. In that case, there is not much we can do. The last time, I checked the strange failure under linux 3.x series kernel a kernel revision failed while another one ran valgrind fine. So I have tried to create a few different kernel versions of 4.x series, but the recent kernel bloat has make it difficult for me to install different versions of the kernel, mostly due to the size of dynamically loaded driver modules. The subdirectories under /usr/lib/modules for the dynamically loaded driver modules for different revisions of the kernel have become too large and basically my root partition filled up. Either I have to manually cull unused modules from the default configuration files. I checked what Debian does and found it distributes a kernel module with many built-in modules for driver. So that we use /boot pretty much (and /boot is a separate partition on my PC), but there is not much space pressure under /usr/lib/modules (which is usually part of root (/) partition.) Oh well. Best Regards, Chiaki -- You are receiving this mail because: You are watching all bug changes.
