Michael Schmitt wrote: >> valgrind --tool=memcheck --workaround-gcc296-bugs=yes --leak-check=yes >> -v ./lyx 2>e.log > > Question: Are you really using gcc 296?
No. I use SuSE gcc version 3.3.4 (pre 3.3.5 20040809). But I read somewhere that this switch (despite the name) is also helpful on some 3.x versions. > Pretty old, isn't it? Yes. And it was never offficially released by the FSF. gcc 2.96 was a partly broken mixture of gcc 2.95 and patches from the gcc 3.0 development tree that was included in Red Hat. > Ha! There's hope! Yesterday, LyX crashed with access to an invalid > address. Since I cannot debug on Windows I cannot provide any further > information :-( But note that LyX works without crash if I run it without valgrind! (and no, I am not going to build LyX on windows: not enough time) >> Do we have any valgrind expert here who can make sense of this or tell me >> how I can find out where the segmentation fault happens? > > There is an option (I don't remember which) that produces longer > backtraces. Set the chain length to 10+ so that we can see some familiar > LyX function. I overlooked that, too. It is --num-callers=20. It is obviously too hot here. > Eagerly awaiting your results, ==30129== Process terminating with default action of signal 11 (SIGSEGV) ==30129== at 0x1B8E967E: _dl_map_object_from_fd (in /lib/ld-2.3.3.so) ==30129== by 0x1B8EACC9: _dl_map_object (in /lib/ld-2.3.3.so) ==30129== by 0x1B8F09CD: openaux (in /lib/ld-2.3.3.so) ==30129== by 0x1B8F0D55: _dl_catch_error (in /lib/ld-2.3.3.so) ==30129== by 0x1B8EFEA3: _dl_map_object_deps (in /lib/ld-2.3.3.so) ==30129== by 0x1B8E65A5: dl_main (in /lib/ld-2.3.3.so) ==30129== by 0x1B8F4600: _dl_sysdep_start (in /lib/ld-2.3.3.so) ==30129== by 0x1B8E534F: _dl_start (in /lib/ld-2.3.3.so) ==30129== by 0x1B8E47A6: (within /lib/ld-2.3.3.so) So it seems that this has nothing to do with LyX but with valgrind and/or the linker. (Downloading and compiling valgrind 2.4.0, the previous version was 2.2.0) It does not look better: ==4047== Process terminating with default action of signal 11 (SIGSEGV) ==4047== at 0x1B8FD7FC: _vgw(float, long double,...)(...)(long double,...)(short) (vg_intercept.c:51) ==4047== by 0x1B8F4D94: malloc (in /lib/ld-2.3.3.so) ==4047== by 0x1B8F4E02: calloc (in /lib/ld-2.3.3.so) ==4047== by 0x1B8EC783: _dl_new_object (in /lib/ld-2.3.3.so) ==4047== by 0x1B8E917A: _dl_map_object_from_fd (in /lib/ld-2.3.3.so) ==4047== by 0x1B8EACC9: _dl_map_object (in /lib/ld-2.3.3.so) ==4047== by 0x1B8F09CD: openaux (in /lib/ld-2.3.3.so) ==4047== by 0x1B8F0D55: _dl_catch_error (in /lib/ld-2.3.3.so) ==4047== by 0x1B8EFEA3: _dl_map_object_deps (in /lib/ld-2.3.3.so) ==4047== by 0x1B8E65A5: dl_main (in /lib/ld-2.3.3.so) ==4047== by 0x1B8F4600: _dl_sysdep_start (in /lib/ld-2.3.3.so) ==4047== by 0x1B8E534F: _dl_start (in /lib/ld-2.3.3.so) ==4047== by 0x1B8E47A6: (within /lib/ld-2.3.3.so) I don't know how to proceed. Unfortunately I get sometimes similar effects with my own programs :-( Georg
