Bug 7858 - Cannot run $PREFIX/sbin/samba under valgrind suddenly
Cannot run $PREFIX/sbin/samba under valgrind suddenly
Status: RESOLVED FIXED
Product: Samba 4.0
Classification: Unclassified
Component: Other
unspecified
All Linux
: P3 major
: ---
Assigned To: Andrew Tridgell
samba4-qa@samba.org
:
Depends on: 7969
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-09 09:43 UTC by Milan Crha
Modified: 2011-02-25 05:47 UTC (History)
2 users (show)

See Also:


Attachments
samba.patch (the real one) (35.98 KB, patch)
2011-02-25 04:22 UTC, Milan Crha
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Milan Crha 2010-12-09 09:43:06 UTC
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.
Comment 1 Milan Crha 2010-12-09 09:59:15 UTC
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.
Comment 2 Matthias Dieter Wallnöfer 2011-01-21 07:01:39 UTC
Jelmer, do you have a clue?
Comment 3 Matthias Dieter Wallnöfer 2011-02-18 07:11:17 UTC
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.
Comment 4 Matthias Dieter Wallnöfer 2011-02-19 05:04:12 UTC
I will close this with reason "LATER" - as agreed with Jelmer.
Comment 5 Matthias Dieter Wallnöfer 2011-02-19 05:04:34 UTC
I will close this with reason "LATER" - as agreed with Jelmer.
Comment 6 Milan Crha 2011-02-21 00:42:14 UTC
(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).
Comment 7 Matthias Dieter Wallnöfer 2011-02-22 07:36:59 UTC
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?
Comment 8 Milan Crha 2011-02-23 02:14:12 UTC
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.
Comment 9 Matthias Dieter Wallnöfer 2011-02-23 02:34:27 UTC
Okay, then let us reopen this if it is very important for you.
Comment 10 Milan Crha 2011-02-23 05:04:19 UTC
==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
Comment 11 Milan Crha 2011-02-24 12:25:11 UTC
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
Comment 12 Matthias Dieter Wallnöfer 2011-02-25 02:36:56 UTC
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
> 

Comment 13 Andrew Bartlett 2011-02-25 03:54:20 UTC
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. 
Comment 14 Milan Crha 2011-02-25 04:22:35 UTC
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).
Comment 15 Milan Crha 2011-02-25 04:23:21 UTC
reopening because of the attachment with the real fix for the issue.
Comment 16 Matthias Dieter Wallnöfer 2011-02-25 05:47:21 UTC
Comment on attachment 6270 [details]
samba.patch (the real one)

Patch has been applied.
Comment 17 Matthias Dieter Wallnöfer 2011-02-25 05:47:33 UTC
Fixed.