Valgrind warning on LLVM 3.6 and 3.7

[garrison]

I put the following in Make.user

LLVM_VER = 3.6.1
CFLAGS = -DMEMDEBUG

then build and run under valgrind

make cleanall && make && valgrind --smc-check=all-non-file --suppressions=contrib/valgrind-julia.supp ./julia -e ""

It reports the following memory error:

==28214== Conditional jump or move depends on uninitialised value(s)
==28214==    at 0x532E973: llvm::DwarfCompileUnit::addRange(llvm::RangeSpan) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x5302D51: llvm::DwarfDebug::endFunction(llvm::MachineFunction const*) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x52EDF16: llvm::AsmPrinter::EmitFunctionBody() (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x5078CA2: llvm::X86AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x5986A1E: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x5988E12: llvm::legacy::PassManagerImpl::run(llvm::Module&) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x5354B6C: llvm::MCJIT::emitObject(llvm::Module*) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x53550C5: llvm::MCJIT::generateCodeForModule(llvm::Module*) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x53530B0: llvm::MCJIT::getSymbolAddress(std::string const&, bool) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x53531A8: llvm::MCJIT::getFunctionAddress(std::string const&) (in /home/garrison/julia/usr/lib/libjulia.so)
==28214==    by 0x4F7A282: jl_generate_fptr (codegen.cpp:734)
==28214==    by 0x4F4D24C: jl_trampoline_compile_function (builtins.c:998)
==28214==    by 0x4F4D24C: jl_trampoline (builtins.c:1009)

I have only been able to reproduce this with LLVM 3.6 and svn/3.7 (not 3.3 or 3.5). I have not tested with LLVM-svn.

[Keno]

Can you try with llvm svn? I have been doing a bunch of runs with memory sanitizer lately and this seems like the kind of thing it should have flagged, so I'd be interested to see if it's present in llvm-svn.

[garrison]

Valgrind (version 3.10.0) itself keeps crashing for me on llvm-svn, with the error

valgrind: m_debuginfo/storage.c:535 (vgModuleLocal_addLineInfo): Assertion 'lineno >= 0' failed.

[garrison]

Even nulgrind is failing. Here's a longer error report.

$ valgrind --tool=none --smc-check=all-non-file ./julia -e ""
==16466== Nulgrind, the minimal Valgrind tool
==16466== Copyright (C) 2002-2013, and GNU GPL'd, by Nicholas Nethercote.
==16466== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==16466== Command: ./julia -e 
==16466== 

valgrind: m_debuginfo/storage.c:535 (vgModuleLocal_addLineInfo): Assertion 'lineno >= 0' failed.

host stacktrace:
==16466==    at 0x38100BBF: show_sched_status_wrk (m_libcassert.c:319)
==16466==    by 0x38100CB4: report_and_quit (m_libcassert.c:390)
==16466==    by 0x38100E36: vgPlain_assert_fail (m_libcassert.c:455)
==16466==    by 0x380A32BE: vgModuleLocal_addLineInfo (storage.c:535)
==16466==    by 0x3810E8EE: vgModuleLocal_read_debuginfo_dwarf3 (readdwarf.c:279)
==16466==    by 0x3809E08A: vgModuleLocal_read_elf_debug_info (readelf.c:2921)
==16466==    by 0x38095910: vgPlain_di_notify_mmap (debuginfo.c:641)
==16466==    by 0x380BF6D5: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2228)
==16466==    by 0x380F2F68: vgSysWrap_amd64_linux_sys_mmap_before (syswrap-amd64-linux.c:630)
==16466==    by 0x380BBF75: vgPlain_client_syscall (syswrap-main.c:1586)
==16466==    by 0x380B87FA: handle_syscall (scheduler.c:1103)
==16466==    by 0x380B9EC6: vgPlain_scheduler (scheduler.c:1416)
==16466==    by 0x380C9800: run_a_thread_NORETURN (syswrap-linux.c:103)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==16466==    at 0x401731A: mmap (syscall-template.S:81)
==16466==    by 0x4006371: _dl_map_object_from_fd (dl-load.c:1344)
==16466==    by 0x400809E: _dl_map_object (dl-load.c:2605)
==16466==    by 0x4012A24: dl_open_worker (dl-open.c:235)
==16466==    by 0x400E8B3: _dl_catch_error (dl-error.c:187)
==16466==    by 0x401243A: _dl_open (dl-open.c:661)
==16466==    by 0x614702A: dlopen_doit (dlopen.c:66)
==16466==    by 0x400E8B3: _dl_catch_error (dl-error.c:187)
==16466==    by 0x61475DC: _dlerror_run (dlerror.c:163)
==16466==    by 0x61470C0: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==16466==    by 0x4D8DBAF: jl_uv_dlopen (dlload.c:49)
==16466==    by 0x4D8DDEA: jl_load_dynamic_library_ (dlload.c:135)
==16466==    by 0x4D963C8: jl_preload_sysimg_so (dump.c:1443)
==16466==    by 0x4D8FF40: _julia_init (init.c:948)
==16466==    by 0x4D90B6C: julia_init (task.c:252)
==16466==    by 0x401372: main (repl.c:491)


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.

[garrison]

Same thing on the latest Valgrind, version 3.10.1. I may file this as a bug against valgrind if others can reproduce.

[garrison]

I modified the assertion in valgrind to issue a warning instead (in valgrind/coregrind/m_debuginfo/storage.c), and re-ran julia built against LLVM-svn. Every time the lineno is negative (and it happens hundreds of times during a run of julia -e ""), it is precisely equal to -1. Could it be that julia is reporting the line number incorrectly?

[Keno]

Yes, that's possible, though I seem to remember LLVM crashing when passed a line number < 0. Worth checking though.

[garrison]

In any event, I am able to reproduce the warning with LLVM-svn under a modified valgrind, so I updated the issue accordingly.

[garrison]

I am able to reproduce with LLVM 3.6.1.

[jakebolewski]

@garrison is this still a problem? Please comment and I'll reopen.

[garrison]

Still an issue on LLVM 3.6.2. (Did you have a reason to believe it had been fixed?)