I wanted to try bug #7654 fix and it seems to work, though I cannot run evolution, or even openchangeclient under valgrind, because valgrind aborts. I realized that also samba itself cannot be run under valgrind, thus here is what it writes for it: ---------------------------------------------------------------------------- $ valgrind $PREFIX/sbin/samba ==2700== Memcheck, a memory error detector ==2700== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==2700== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==2700== Command: $PREFIX/sbin/samba ==2700== ==2700== Warning: DWARF2 reader: Badly formed extended line op encountered valgrind: m_debuginfo/storage.c:361 (vgModuleLocal_addLineInfo): Assertion 'lineno >= 0' failed. ==2700== at 0x3802B8D9: report_and_quit (m_libcassert.c:145) ==2700== by 0x3802BAA8: vgPlain_assert_fail (m_libcassert.c:217) ==2700== by 0x3805C3F4: vgModuleLocal_addLineInfo (storage.c:361) ==2700== by 0x3809DFF1: vgModuleLocal_read_debuginfo_dwarf3 (readdwarf.c:775) ==2700== by 0x38058BA8: vgModuleLocal_read_elf_debug_info (readelf.c:2098) ==2700== by 0x38051959: vgPlain_di_notify_mmap (debuginfo.c:817) ==2700== by 0x3806A099: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2037) ==2700== by 0x380913C9: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:984) ==2700== by 0x3806690B: vgPlain_client_syscall (syswrap-main.c:1392) ==2700== by 0x3806379D: handle_syscall (scheduler.c:873) ==2700== by 0x38064919: vgPlain_scheduler (scheduler.c:1069) ==2700== by 0x38074694: run_a_thread_NORETURN (syswrap-linux.c:91) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==2700== at 0x355E61753A: mmap (in /lib64/ld-2.12.90.so) ==2700== by 0x355E6068C8: _dl_map_object_from_fd (in /lib64/ld-2.12.90.so) ==2700== by 0x355E608276: _dl_map_object (in /lib64/ld-2.12.90.so) ==2700== by 0x355E60C79C: openaux (in /lib64/ld-2.12.90.so) ==2700== by 0x355E60E895: _dl_catch_error (in /lib64/ld-2.12.90.so) ==2700== by 0x355E60CEA9: _dl_map_object_deps (in /lib64/ld-2.12.90.so) ==2700== by 0x355E602F8C: dl_main (in /lib64/ld-2.12.90.so) ==2700== by 0x355E6153BA: _dl_sysdep_start (in /lib64/ld-2.12.90.so) ==2700== by 0x355E604B27: _dl_start (in /lib64/ld-2.12.90.so) ==2700== by 0x355E600B17: ??? (in /lib64/ld-2.12.90.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. ---------------------------------------------------------------------------- I'm using git master of samba4, currently at commit 377b399 and valgrind-3.5.0-19.fc14.x86_64. Would it be possible that those generated libraries with waf are in too new format, and thus valgrind doesn't know how to decode it? I'm asking first here, because it seems quite strange to have it as valgrind issue.
Just to add to this, when I build samba4 from samba-4.0.0alpha13.tar.gz then valgrind has no issue. The only thing I ddi was changing samba4 source, nothing else in the system.
Jelmer, do you have a clue?
I've asked Jelmer which has some experience in our WAF-based build system but he has no clue. Probably it is an internal valgrind issue - so we cannot help any further. If you are able to recover additional information we can reopen this and retry to do a diagnostic - but otherwise I don't see any other possibility.
I will close this with reason "LATER" - as agreed with Jelmer.
(In reply to comment #3) > If you are able to recover additional information we can reopen this and retry > to do a diagnostic - but otherwise I don't see any other possibility. What kind of more information do you expect, except of the clear reproducer from comment #0? I agree that this can be valgrind issue too, not able to work with newly built executables of the DWARF2 format, but it seems strange because this didn't happen with older version (with tarball release of samba4).
I for example am working with the valgrind package valgrind-3.5.0-17.fc13.x86_64 on Fedora 13 and have no problems at all. It seems to be a little older than the version you use. I don't know if my idea works: couldn't you try to remove your valgrind package temporarily for testing and use the one from Fedora 13?
OK, I'll try it, even the changelog in fedora repo doesn't seem to suggest any DWARF related change between your and mine version in valgrind, bug one never knows. Anyway, I'm blocked by bug #7969, because I want to check this out on actual git master of samba.
Okay, then let us reopen this if it is very important for you.
==10558== Warning: DWARF2 reader: Badly formed extended line op encountered valgrind: m_debuginfo/storage.c:361 (vgModuleLocal_addLineInfo): Assertion 'lineno >= 0' failed. It crashes the same way with your version same as with the latest 3.5.0-20 on Fedora 14 system for me. I just tried to build valgrind 3.6.0 here too, and it crashes the same way. I filled this to Fedora bugzilla, as [1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=679726
I'm reopening this, as this is samba issue, as stated in [1]. Please fix this as is described there. Thanks in advance. https://bugzilla.redhat.com/show_bug.cgi?id=679726#c7
Okay, I hope that I'm not fully wrong: isn't the problem located in the heimdal source code? Since this is an upstream project we need to distinguish if the problem lies in our side or the other side. abartlet, could you tell this? (In reply to comment #11) > I'm reopening this, as this is samba issue, as stated in [1]. Please fix this > as is described there. Thanks in advance. > > https://bugzilla.redhat.com/show_bug.cgi?id=679726#c7 >
I think this is a bug in Fedora 14 lex/yacc, but either way, I've worked around it by simply omitting the #line directives when we generate the files using the heimdal_build/lexyacc.sh script The fix is in autobuild.
Created attachment 6270 [details] samba.patch (the real one) (In reply to comment #13) > I think this is a bug in Fedora 14 lex/yacc Come on, it isn't. I spent few hours chasing this and the heimdal_build/lexyacc.sh is the cause, it's written incorrectly, there is no SRC and DEST variable, thus it generates these empty lines. The attached patch is fixing it, and because you have those generated files in git repo too, then it's slightly larger than really needed. Please do fix this properly, thanks in advance (and note comment #1, same system, same libraries and tools, only samba4 version change, and it makes the difference).
reopening because of the attachment with the real fix for the issue.
Comment on attachment 6270 [details] samba.patch (the real one) Patch has been applied.
Fixed.